From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id E1CA82002A9 for ; Thu, 16 Aug 2012 10:02:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id AEA54A84F0; Thu, 16 Aug 2012 13:02:02 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy31.wa-web.iad1a (legacy31.wa-web.iad1a.rsapps.net [192.168.2.153]) by smtp26.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8B5BCA8499; Thu, 16 Aug 2012 13:02:02 -0400 (EDT) Received: from reed.com (localhost [127.0.0.1]) by legacy31.wa-web.iad1a (Postfix) with ESMTP id 74F351D4A325; Thu, 16 Aug 2012 13:02:02 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 16 Aug 2012 13:02:02 -0400 (EDT) Date: Thu, 16 Aug 2012 13:02:02 -0400 (EDT) From: dpreed@reed.com To: "William Katsak" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20120816130202000000_71442" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <-8776350186991914212@unknownmsgid> References: <36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de> <1345071222.04317697@apps.rackspace.com> <6403367419286815483@unknownmsgid> <73CD3D52-3C2A-4B91-96DA-8747FE97DEE6@gmx.de> <-8776350186991914212@unknownmsgid> Message-ID: <1345136522.47617637@apps.rackspace.com> X-Mailer: webmail7.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: Thu, 16 Aug 2012 17:02:04 -0000 ------=_20120816130202000000_71442 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AYou know I have been make the bufferbloat issue with my cable modem go a= way by=0A =0Aa simple "token buffer" approach on the link into the cable mo= dem itself (p5p1 in this test setup with my my connection offering a reason= ably constant 2 Mb/sec rate):=0A =0Atc qdisc add dev p5p1 root tbf rate 1.8= mbit latency 10ms burst 9000=0A =0AAnd at one point in time, I "servoed" th= e rate setting to a "higher level" script that polled the ping time to a se= rver I control so if the 1.8 mbit is "too big" it is shrunk down.=0A =0AThe= "cable modem uplink" should not be so hard to get right.=0A =0AOf course t= he WLAN queues internal to the home network or in the "mesh" if you run tha= t need codel and fixes to the driver-internal packet queues.=0A =0ABut the = first thing to do if you see 2800 msec. uplink buffers is to *fix* that. T= hen tinker with other things.=0A =0A =0A =0A =0A =0AAnd I have in the past= =0A =0A-----Original Message-----=0AFrom: "William Katsak" =0ASent: Thursday, August 16, 2012 7:08am=0ATo: "Sebastian Moeller" =0ACc: "dpreed@reed.com" , "cerowrt-devel@lis= ts.bufferbloat.net" =0ASubject: Re: [C= erowrt-devel] cerowrt 3.3.8-17 is released=0A=0A=0A=0AThis was -6, so I was= using simple_qos.sh.=0A=0ABill=0A=0ASent from my iPhone=0A=0AOn Aug 16, 20= 12, at 12:54 AM, Sebastian Moeller wrote:=0A=0A> Hi Willi= am,=0A>=0A>=0A> On Aug 15, 2012, at 3:57 PM, William Katsak wrote:=0A>=0A>>= I agree with this assessment as far as behavior goes. With my recent expe= rimentation on a Russian DSL line, I was seeing ~1200ms of uplink buffer re= ported (Netalyzr) natively, but as soon as I got the AQM running properly, = that went away completely.=0A>=0A> QOS or simple_qos.sh? I might switch = to simple_qos next to see the effects there.=0A>=0A> best=0A> Sebastian= =0A>=0A>>=0A>> Bill=0A>>=0A>> Sent from my iPhone=0A>>=0A>> On Aug 15, 2012= , at 6:53 PM, "dpreed@reed.com" wrote:=0A>>=0A>>> Just to= clarify, the way Netalyzr attempts to measure "uplink buffering" may not a= ctually measure queue length. It just spews UDP packets at the target, an= d measures sender-receiver packet delay at the maximum load it can generate= . So it's making certain assumptions about the location and FIFO nature o= f the "bottleneck queue" when it calculates that.=0A>>>=0A>>> I don't think= this is good news that you are reproting.=0A>>>=0A>>> Assuming codel is me= asuring "sojourn time" and controlling it properly, you should not see 2.8 = *seconds* of UDP queueing delay on the uplink - packets should be being dro= pped to keep that delay down to under 10 milliseconds.=0A>>> I have no idea= how that jibes with low ping times, unless you are getting the ICMP packet= s spoofed.=0A>>>=0A>>>=0A>>> -----Original Message-----=0A>>> From: "Sebast= ian Moeller" =0A>>> Sent: Wednesday, August 15, 2012 1:23p= m=0A>>> To: "Dave Taht" =0A>>> Cc: cerowrt-devel@lists= .bufferbloat.net=0A>>> Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is rel= eased=0A>>>=0A>>> Hi Dave,=0A>>>=0A>>> great work, as always I upgraded my = production router to the latest and greatest (since I only have one router= =E2=80=A6). And it works quite well for normal usage=E2=80=A6=0A>>> Netalyz= r reports around 2800ms seconds of uplink buffering, yet saturating the upl= ink does not affect ping times to a remote target noticeably, basically the= same as for all codellized ceo versions I tested so far...=0A>>>=0A>>> Som= e notes and a question:=0A>>> I noticed that even given plenty of swap spac= e (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 th= e test from a macosx via 5GHz wireless over 1.5 yards):=0A>>> Aug 15 01:16:= 29 nacktmulle kern.err kernel: [175395.132812] ath: skbuff alloc of size 19= 26 failed=0A>>> (and plenty of those=E2=80=A6).=0A>>> What then happens is = that the OOM killer will aim for bind (reasonable since it is the largest s= ingle process) and kill it. When I try to restart bind by:=0A>>> root@nackt= mulle:~# /etc/rc.d/S47namedprep start=0A>>> root@nacktmulle:~# /etc/rc.d/S4= 8named restart=0A>>> Stopping isc-bind=0A>>> /etc/chroot/named//var/run/nam= ed/named.pid not found, trying brute force=0A>>> killall: named: no process= killed=0A>>> Kicking isc-bind in xinetd=0A>>> rndc: connect failed: 127.0.= 0.1#953: connection refused=0A>>> And bind does not start again and the rou= ter 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 route= r (my current method) I would be happy to learn=0A>>>=0A>>>=0A>>>=0A>>> bes= t regards=0A>>> sebastian=0A>>>=0A>>> On Aug 12, 2012, at 11:08 PM, Dave Ta= ht wrote:=0A>>>=0A>>>> I'm too tired to write up a full set of release note= s, but I've been=0A>>>> testing it all day,=0A>>>> and it looks better than= -10 and certainly better than -11, but I won't know=0A>>>> until some more= folk sit down and test it, so here it is.=0A>>>>=0A>>>> http://huchra.buff= erbloat.net/~cero1/3.3/3.3.8-17/=0A>>>>=0A>>>> fresh merge with openwrt, fi= x to a bind CVE, fixes for 6in4 and quagga=0A>>>> routing problems,=0A>>>> = and a few tweaks to fq_codel setup that might make voip better.=0A>>>>=0A>>= >> Go forth and break things!=0A>>>>=0A>>>> In other news:=0A>>>>=0A>>>> Va= n Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel=0A= >>>> at last week's ietf meeting. Well worth watching. At the end he outlin= es=0A>>>> the deployment problems in particular.=0A>>>>=0A>>>> http://recor= dings.conf.meetecho.com/Recordings/watch.jsp?recording=3DIETF84_TSVAREA&cha= pter=3Dpart_3=0A>>>>=0A>>>> Far more interesting than this email!=0A>>>>=0A= >>>>=0A>>>> --=0A>>>> Dave T=C3=A4ht=0A>>>> http://www.bufferbloat.net/proj= ects/cerowrt/wiki - "3.3.8-17 is out=0A>>>> with fq_codel!"=0A>>>> ________= _______________________________________=0A>>>> Cerowrt-devel mailing list= =0A>>>> Cerowrt-devel@lists.bufferbloat.net=0A>>>> https://lists.bufferbloa= t.net/listinfo/cerowrt-devel=0A>>>=0A>>> __________________________________= _____________=0A>>> Cerowrt-devel mailing list=0A>>> Cerowrt-devel@lists.bu= fferbloat.net=0A>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A= >>> _______________________________________________=0A>>> Cerowrt-devel mai= ling list=0A>>> Cerowrt-devel@lists.bufferbloat.net=0A>>> https://lists.buf= ferbloat.net/listinfo/cerowrt-devel=0A> ------=_20120816130202000000_71442 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

=0A=

 

=0A

a simple "token buffer" approach on the link into the cable modem itsel= f (p5p1 in this test setup with my my connection offering a reasonably cons= tant 2 Mb/sec rate):

=0A

 

=0Atc qdisc add dev p5p1 root tbf rate 1.8mbit = latency 10ms burst 9000

=0A

 

= =0A

And at one point in time, I "servoed" t= he rate setting to a "higher level" script that polled the ping time to a s= erver I control so if the 1.8 mbit is "too big" it is shrunk down.

=0A 

=0A

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

=0A

 

=0A

Of= course the WLAN queues internal to the home network or in the "mesh" if yo= u run that need codel and fixes to the driver-internal packet queues.

= =0A

 

=0A

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

=0A

 

=0A

 

=0A 

=0A

 

=0A

 

=0A

And I have in the past

=0A

 

=0A

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

=0A
=0A

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

Bill

Sent from my iPh= one

On Aug 16, 2012, at 12:54 AM, Sebastian Moeller <moeller0= @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 exp= erimentation on a Russian DSL line, I was seeing ~1200ms of uplink buffer r= eported (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.
>
&g= t; best
> Sebastian
>
>>
>> Bill>>
>> Sent from my iPhone
>>
>> = On Aug 15, 2012, at 6:53 PM, "dpreed@reed.com" <dpreed@reed.com> wrot= e:
>>
>>> Just to clarify, the way Netalyzr attemp= ts to measure "uplink buffering" may not actually measure queue length. I= t 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 assump= tions 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.
>>>
>>> Assum= ing codel is measuring "sojourn time" and controlling it properly, you shou= ld not see 2.8 *seconds* of UDP queueing delay on the uplink - packets shou= ld 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: "Sebast= ian Moeller" <moeller0@gmx.de>
>>> Sent: Wednesday, Aug= ust 15, 2012 1:23pm
>>> To: "Dave Taht" <dave.taht@gmail.c= om>
>>> Cc: cerowrt-devel@lists.bufferbloat.net
>&= gt;> Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released
>= >>
>>> Hi Dave,
>>>
>>> gre= at work, as always I upgraded my production router to the latest and greate= st (since I only have one router=E2=80=A6). And it works quite well for nor= mal usage=E2=80=A6
>>> 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 r= un the test from a macosx via 5GHz wireless over 1.5 yards):
>>&= gt; Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.132812] ath: skbuff= alloc of size 1926 failed
>>> (and plenty of those=E2=80=A6)= .
>>> What then happens is that the OOM killer will aim for b= ind (reasonable since it is the largest single process) and kill it. When I= try to restart bind by:
>>> root@nacktmulle:~# /etc/rc.d/S47= namedprep start
>>> root@nacktmulle:~# /etc/rc.d/S48named res= tart
>>> Stopping isc-bind
>>> /etc/chroot/name= d//var/run/named/named.pid not found, trying brute force
>>> = killall: named: no process killed
>>> Kicking isc-bind in xin= etd
>>> rndc: connect failed: 127.0.0.1#953: connection refus= ed
>>> And bind does not start again and the router becomes l= ess 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 w= rote:
>>>
>>>> I'm too tired to write up a f= ull set of release notes, but I've been
>>>> testing it al= l day,
>>>> and it looks better than -10 and certainly bet= ter than -11, but I won't know
>>>> until some more folk s= it down and test it, so here it is.
>>>>
>>>= > http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/
>>>&g= t;
>>>> fresh merge with openwrt, fix to a bind CVE, fixes= for 6in4 and quagga
>>>> routing problems,
>>&= gt;> and a few tweaks to fq_codel setup that might make voip better.
>>>>
>>>> Go forth and break things!
&g= t;>>>
>>>> In other news:
>>>>>>>> Van Jacobson gave a great talk about bufferbloat, BQL,= codel, and fq_codel
>>>> at last week's ietf meeting. Wel= l worth watching. At the end he outlines
>>>> the deployme= nt problems in particular.
>>>>
>>>> http= ://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=3DIETF84_TSV= AREA&chapter=3Dpart_3
>>>>
>>>> Far m= ore interesting than this email!
>>>>
>>>>= ;
>>>> --
>>>> Dave T=C3=A4ht
>&g= t;>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is = out
>>>> with fq_codel!"
>>>> ___________= ____________________________________
>>>> Cerowrt-devel ma= iling list
>>>> Cerowrt-devel@lists.bufferbloat.net
&= gt;>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
&= gt;>>
>>> _____________________________________________= __
>>> Cerowrt-devel mailing list
>>> Cerowrt-d= evel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/= listinfo/cerowrt-devel
>>> __________________________________= _____________
>>> Cerowrt-devel mailing list
>>>= ; Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.buffe= rbloat.net/listinfo/cerowrt-devel
>

=0A
 ------=_20120816130202000000_71442--