[Cerowrt-devel] cerowrt 3.3.8-17 is released

Thu Aug 16 13:02:02 EDT 2012

You know I have been make the bufferbloat issue with my cable modem go away by

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):

tc qdisc add dev p5p1 root tbf rate 1.8mbit latency 10ms burst 9000

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.

The "cable modem uplink" should not be so hard to get right.

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.

But the first thing to do if you see 2800 msec. uplink buffers is to *fix* that.  Then tinker with other things.

And I have in the past

-----Original Message-----
From: "William Katsak" <wkatsak at gmail.com>
Sent: Thursday, August 16, 2012 7:08am
To: "Sebastian Moeller" <moeller0 at gmx.de>
Cc: "dpreed at reed.com" <dpreed at reed.com>, "cerowrt-devel at lists.bufferbloat.net" <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released

This was -6, so I was using simple_qos.sh.

Bill

Sent from my iPhone

On Aug 16, 2012, at 12:54 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:

> 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 at reed.com" <dpreed at 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" <moeller0 at gmx.de>
>>> Sent: Wednesday, August 15, 2012 1:23pm
>>> To: "Dave Taht" <dave.taht at gmail.com>
>>> Cc: cerowrt-devel at 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…). And it works quite well for normal usage…
>>> 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…).
>>> 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 at nacktmulle:~# /etc/rc.d/S47namedprep start
>>> root at 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=IETF84_TSVAREA&chapter=part_3
>>>>
>>>> Far more interesting than this email!
>>>>
>>>>
>>>> --
>>>> Dave Täht
>>>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
>>>> with fq_codel!"
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20120816/bd517a0b/attachment-0002.html>