<font face="arial" size="2"><p style="margin:0;padding:0;">You know I have been make the bufferbloat issue with my cable modem go away by</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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):</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">tc qdisc add dev p5p1 root tbf rate 1.8mbit latency 10ms burst 9000</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The "cable modem uplink" should not be so hard to get right.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">But the first thing to do if you see 2800 msec. uplink buffers is to *fix* that. Then tinker with other things.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">And I have in the past</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "William Katsak" <wkatsak@gmail.com><br />Sent: Thursday, August 16, 2012 7:08am<br />To: "Sebastian Moeller" <moeller0@gmx.de><br />Cc: "dpreed@reed.com" <dpreed@reed.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net><br />Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released<br /><br /></p>
<div id="SafeStyles1345136090">
<p style="margin:0;padding:0;">This was -6, so I was using simple_qos.sh.<br /><br />Bill<br /><br />Sent from my iPhone<br /><br />On Aug 16, 2012, at 12:54 AM, Sebastian Moeller <moeller0@gmx.de> wrote:<br /><br />> Hi William,<br />><br />><br />> On Aug 15, 2012, at 3:57 PM, William Katsak wrote:<br />><br />>> 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.<br />><br />> QOS or simple_qos.sh? I might switch to simple_qos next to see the effects there.<br />><br />> best<br />> Sebastian<br />><br />>><br />>> Bill<br />>><br />>> Sent from my iPhone<br />>><br />>> On Aug 15, 2012, at 6:53 PM, "dpreed@reed.com" <dpreed@reed.com> wrote:<br />>><br />>>> 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.<br />>>><br />>>> I don't think this is good news that you are reproting.<br />>>><br />>>> 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.<br />>>> I have no idea how that jibes with low ping times, unless you are getting the ICMP packets spoofed.<br />>>><br />>>><br />>>> -----Original Message-----<br />>>> From: "Sebastian Moeller" <moeller0@gmx.de><br />>>> Sent: Wednesday, August 15, 2012 1:23pm<br />>>> To: "Dave Taht" <dave.taht@gmail.com><br />>>> Cc: cerowrt-devel@lists.bufferbloat.net<br />>>> Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released<br />>>><br />>>> Hi Dave,<br />>>><br />>>> great work, as always I upgraded my production router to the latest and greatest (since I only have one router…). And it works quite well for normal usage…<br />>>> 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...<br />>>><br />>>> Some notes and a question:<br />>>> 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):<br />>>> Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.132812] ath: skbuff alloc of size 1926 failed<br />>>> (and plenty of those…).<br />>>> 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:<br />>>> root@nacktmulle:~# /etc/rc.d/S47namedprep start<br />>>> root@nacktmulle:~# /etc/rc.d/S48named restart<br />>>> Stopping isc-bind<br />>>> /etc/chroot/named//var/run/named/named.pid not found, trying brute force<br />>>> killall: named: no process killed<br />>>> Kicking isc-bind in xinetd<br />>>> rndc: connect failed: 127.0.0.1#953: connection refused<br />>>> 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<br />>>><br />>>><br />>>><br />>>> best regards<br />>>> sebastian<br />>>><br />>>> On Aug 12, 2012, at 11:08 PM, Dave Taht wrote:<br />>>><br />>>>> I'm too tired to write up a full set of release notes, but I've been<br />>>>> testing it all day,<br />>>>> and it looks better than -10 and certainly better than -11, but I won't know<br />>>>> until some more folk sit down and test it, so here it is.<br />>>>><br />>>>> http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/<br />>>>><br />>>>> fresh merge with openwrt, fix to a bind CVE, fixes for 6in4 and quagga<br />>>>> routing problems,<br />>>>> and a few tweaks to fq_codel setup that might make voip better.<br />>>>><br />>>>> Go forth and break things!<br />>>>><br />>>>> In other news:<br />>>>><br />>>>> Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel<br />>>>> at last week's ietf meeting. Well worth watching. At the end he outlines<br />>>>> the deployment problems in particular.<br />>>>><br />>>>> http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREA&chapter=part_3<br />>>>><br />>>>> Far more interesting than this email!<br />>>>><br />>>>><br />>>>> --<br />>>>> Dave Täht<br />>>>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out<br />>>>> with fq_codel!"<br />>>>> _______________________________________________<br />>>>> Cerowrt-devel mailing list<br />>>>> Cerowrt-devel@lists.bufferbloat.net<br />>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />>>><br />>>> _______________________________________________<br />>>> Cerowrt-devel mailing list<br />>>> Cerowrt-devel@lists.bufferbloat.net<br />>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />>>> _______________________________________________<br />>>> Cerowrt-devel mailing list<br />>>> Cerowrt-devel@lists.bufferbloat.net<br />>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />></p>
</div></font>