From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by huchra.bufferbloat.net (Postfix) with SMTP id 514CE200A76 for ; Mon, 20 Aug 2012 11:17:20 -0700 (PDT) Received: (qmail invoked by alias); 20 Aug 2012 18:17:18 -0000 Received: from tsaolab-fw.caltech.edu (EHLO [192.168.50.16]) [131.215.9.89] by mail.gmx.net (mp012) with SMTP; 20 Aug 2012 20:17:18 +0200 X-Authenticated: #24211782 X-Provags-ID: V01U2FsdGVkX1+TvUA9ZduTiWbvImpJByhqsL7qWdukjovzJpRCR1 ciNFZlESNuM6u+ Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <1345136522.47617637@apps.rackspace.com> Date: Mon, 20 Aug 2012 11:17:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8400DB69-3CDB-45C9-A87B-98B4E7713776@gmx.de> References: <36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de> <1345071222.04317697@apps.rackspace.com> <6403367419286815483@unknownmsgid> <73CD3D52-3C2A-4B91-96DA-8747FE97DEE6@gmx.de> <-8776350186991914212@unknownmsgid> <1345136522.47617637@apps.rackspace.com> To: dpreed@reed.com X-Mailer: Apple Mail (2.1278) X-Y-GMX-Trusted: 0 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:17:20 -0000 Hi, thanks for you input. On Aug 16, 2012, at 10:02 AM, dpreed@reed.com wrote: > You know I have been make the bufferbloat issue with my cable modem go = away by > =20 > a simple "token buffer" approach on the link into the cable modem = itself (p5p1 in this test setup with my my connection offering a = reasonably constant 2 Mb/sec rate): > =20 > tc qdisc add dev p5p1 root tbf rate 1.8mbit latency 10ms burst 9000 > =20 > And at one point in time, I "servoed" the rate setting to a "higher = level" script that polled the ping time to a server I control so if the = 1.8 mbit is "too big" it is shrunk down. > =20 > The "cable modem uplink" should not be so hard to get right. > =20 > Of course the WLAN queues internal to the home network or in the = "mesh" if you run that need codel and fixes to the driver-internal = packet queues. > =20 > But the first thing to do if you see 2800 msec. uplink buffers is to = *fix* that. Then tinker with other things. It looks like the UDP tests packet creation rate and fq_codel's = "slow" ramping up of the drop-rate just allows packets to accumulate in = the queue. This is supported by the observation that netalyzr's reported = buffering scales with fq_codels's limit parameter (up to a ceiling). = Since other flows stay relative responsive my interpretation is that = codel does it's thing correctly it is just that an inelastic UDP stream = is not well suited to codel's gentle drop strategy, which seems tailored = for TCP's behavior. Best & Thanks Sebastian > =20 > =20 > =20 > =20 > =20 > And I have in the past > =20 > -----Original Message----- > From: "William Katsak" > Sent: Thursday, August 16, 2012 7:08am > To: "Sebastian Moeller" > Cc: "dpreed@reed.com" , = "cerowrt-devel@lists.bufferbloat.net" = > Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released >=20 > This was -6, so I was using simple_qos.sh. >=20 > Bill >=20 > Sent from my iPhone >=20 > On Aug 16, 2012, at 12:54 AM, Sebastian Moeller = wrote: >=20 > > Hi William, > > > > > > On Aug 15, 2012, at 3:57 PM, William Katsak wrote: > > > >> I agree with this assessment as far as behavior goes. With my = recent experimentation on a Russian DSL line, I was seeing ~1200ms of = uplink buffer reported (Netalyzr) natively, but as soon as I got the AQM = running properly, that went away completely. > > > > QOS or simple_qos.sh? I might switch to simple_qos next to see the = effects there. > > > > best > > Sebastian > > > >> > >> Bill > >> > >> Sent from my iPhone > >> > >> On Aug 15, 2012, at 6:53 PM, "dpreed@reed.com" = wrote: > >> > >>> Just to clarify, the way Netalyzr attempts to measure "uplink = buffering" may not actually measure queue length. It just spews UDP = packets at the target, and measures sender-receiver packet delay at the = maximum load it can generate. So it's making certain assumptions about = the location and FIFO nature of the "bottleneck queue" when it = calculates that. > >>> > >>> I don't think this is good news that you are reproting. > >>> > >>> Assuming codel is measuring "sojourn time" and controlling it = properly, you should not see 2.8 *seconds* of UDP queueing delay on the = uplink - packets should be being dropped to keep that delay down to = under 10 milliseconds. > >>> I have no idea how that jibes with low ping times, unless you are = getting the ICMP packets spoofed. > >>> > >>> > >>> -----Original Message----- > >>> From: "Sebastian Moeller" > >>> Sent: Wednesday, August 15, 2012 1:23pm > >>> To: "Dave Taht" > >>> Cc: cerowrt-devel@lists.bufferbloat.net > >>> Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released > >>> > >>> Hi Dave, > >>> > >>> great work, as always I upgraded my production router to the = latest and greatest (since I only have one router=85). And it works = quite well for normal usage=85 > >>> Netalyzr reports around 2800ms seconds of uplink buffering, yet = saturating the uplink does not affect ping times to a remote target = noticeably, basically the same as for all codellized ceo versions I = tested so far... > >>> > >>> Some notes and a question: > >>> I noticed that even given plenty of swap space (1GB on a usb = stick), using http://broadband.mpi-sws.org/residential/ to exercise UDP = stress (on the uplink I assume) I can easily produce (I run the test = from a macosx via 5GHz wireless over 1.5 yards): > >>> Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.132812] ath: = skbuff alloc of size 1926 failed > >>> (and plenty of those=85). > >>> What then happens is that the OOM killer will aim for bind = (reasonable since it is the largest single process) and kill it. When I = try to restart bind by: > >>> root@nacktmulle:~# /etc/rc.d/S47namedprep start > >>> root@nacktmulle:~# /etc/rc.d/S48named restart > >>> Stopping isc-bind > >>> /etc/chroot/named//var/run/named/named.pid not found, trying brute = force > >>> killall: named: no process killed > >>> Kicking isc-bind in xinetd > >>> rndc: connect failed: 127.0.0.1#953: connection refused > >>> And bind does not start again and the router becomes less than = useful. Now I assume I am doing something wrong, but what, if you have = any idea how to solve this short of a reboot of the router (my current = method) I would be happy to learn > >>> > >>> > >>> > >>> best regards > >>> sebastian > >>> > >>> On Aug 12, 2012, at 11:08 PM, Dave Taht wrote: > >>> > >>>> I'm too tired to write up a full set of release notes, but I've = been > >>>> testing it all day, > >>>> and it looks better than -10 and certainly better than -11, but I = won't know > >>>> until some more folk sit down and test it, so here it is. > >>>> > >>>> http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/ > >>>> > >>>> fresh merge with openwrt, fix to a bind CVE, fixes for 6in4 and = quagga > >>>> routing problems, > >>>> and a few tweaks to fq_codel setup that might make voip better. > >>>> > >>>> Go forth and break things! > >>>> > >>>> In other news: > >>>> > >>>> Van Jacobson gave a great talk about bufferbloat, BQL, codel, and = fq_codel > >>>> at last week's ietf meeting. Well worth watching. At the end he = outlines > >>>> the deployment problems in particular. > >>>> > >>>> = http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=3DIETF8= 4_TSVAREA&chapter=3Dpart_3 > >>>> > >>>> Far more interesting than this email! > >>>> > >>>> > >>>> -- > >>>> Dave T=E4ht > >>>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is = out > >>>> with fq_codel!" > >>>> _______________________________________________ > >>>> Cerowrt-devel mailing list > >>>> Cerowrt-devel@lists.bufferbloat.net > >>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > >>> > >>> _______________________________________________ > >>> Cerowrt-devel mailing list > >>> Cerowrt-devel@lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > >>> _______________________________________________ > >>> Cerowrt-devel mailing list > >>> Cerowrt-devel@lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > >