From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) (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 205FA200B49 for ; Wed, 15 Aug 2012 15:53:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 5A43F14910A; Wed, 15 Aug 2012 18:53:42 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy22.wa-web.iad1a (legacy22.wa-web.iad1a.rsapps.net [192.168.2.208]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2EBAE148FC6; Wed, 15 Aug 2012 18:53:42 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy22.wa-web.iad1a (Postfix) with ESMTP id 0B6553AE8042; Wed, 15 Aug 2012 18:53:42 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 15 Aug 2012 18:53:42 -0400 (EDT) Date: Wed, 15 Aug 2012 18:53:42 -0400 (EDT) From: dpreed@reed.com To: "Sebastian Moeller" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20120815185342000000_33299" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de> References: <36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de> Message-ID: <1345071222.04317697@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: Wed, 15 Aug 2012 22:53:44 -0000 ------=_20120815185342000000_33299 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AJust 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 ca= n generate. So it's making certain assumptions about the location and FIF= O nature of the "bottleneck queue" when it calculates that.=0A =0AI don't t= hink this is good news that you are reproting.=0A =0AAssuming codel is meas= uring "sojourn time" and controlling it properly, you should not see 2.8 *s= econds* of UDP queueing delay on the uplink - packets should be being dropp= ed to keep that delay down to under 10 milliseconds.=0AI have no idea how t= hat jibes with low ping times, unless you are getting the ICMP packets spoo= fed.=0A =0A =0A-----Original Message-----=0AFrom: "Sebastian Moeller" =0ASent: Wednesday, August 15, 2012 1:23pm=0ATo: "Dave Taht" =0ACc: cerowrt-devel@lists.bufferbloat.net=0ASubject: Re= : [Cerowrt-devel] cerowrt 3.3.8-17 is released=0A=0A=0A=0AHi Dave,=0A=0Agre= 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=0ANetalyzr reports around 2800ms seconds of uplink buffe= ring, yet saturating the uplink does not affect ping times to a remote targ= et noticeably, basically the same as for all codellized ceo versions I test= ed so far...=0A=0ASome notes and a question:=0AI noticed that even given pl= enty 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):=0A= Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.132812] ath: skbuff all= oc of size 1926 failed=0A(and plenty of those=E2=80=A6). =0AWhat then happe= ns is that the OOM killer will aim for bind (reasonable since it is the lar= gest single process) and kill it. When I try to restart bind by:=0Aroot@nac= ktmulle:~# /etc/rc.d/S47namedprep start=0Aroot@nacktmulle:~# /etc/rc.d/S48n= amed restart=0AStopping isc-bind=0A /etc/chroot/named//var/run/named/named.= pid not found, trying brute force =0Akillall: named: no process killed=0AKi= cking isc-bind in xinetd=0Arndc: connect failed: 127.0.0.1#953: connection = refused=0AAnd bind does not start again and the router becomes less than us= eful. Now I assume I am doing something wrong, but what, if you have any id= ea how to solve this short of a reboot of the router (my current method) I = would be happy to learn=0A=0A=0A=0Abest regards=0A sebastian=0A=0AOn Aug 12= , 2012, at 11:08 PM, Dave Taht wrote:=0A=0A> I'm too tired to write up a fu= ll set of release notes, but I've been=0A> testing it all day,=0A> and it l= ooks better than -10 and certainly better than -11, but I won't know=0A> un= til some more folk sit down and test it, so here it is.=0A> =0A> http://huc= hra.bufferbloat.net/~cero1/3.3/3.3.8-17/=0A> =0A> fresh merge with openwrt,= fix 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 fo= rth and break things!=0A> =0A> In other news:=0A> =0A> Van Jacobson gave a = great talk about bufferbloat, BQL, codel, and fq_codel=0A> at last week's i= etf meeting. Well worth watching. At the end he outlines=0A> the deployment= problems in particular.=0A> =0A> http://recordings.conf.meetecho.com/Recor= dings/watch.jsp?recording=3DIETF84_TSVAREA&chapter=3Dpart_3=0A> =0A> Far mo= re interesting than this email!=0A> =0A> =0A> -- =0A> Dave T=C3=A4ht=0A> ht= tp://www.bufferbloat.net/projects/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://list= s.bufferbloat.net/listinfo/cerowrt-devel=0A=0A_____________________________= __________________=0ACerowrt-devel mailing list=0ACerowrt-devel@lists.buffe= rbloat.net=0Ahttps://lists.bufferbloat.net/listinfo/cerowrt-devel ------=_20120815185342000000_33299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just to cl= arify, the way Netalyzr attempts to measure "uplink buffering" may not actu= ally measure queue length.   It just spews UDP packets at the tar= get, and measures sender-receiver packet delay at the maximum load it can g= enerate.   So it's making certain assumptions about the location = and FIFO nature of the "bottleneck queue" when it calculates that.

=0A 

=0A

I don't think this is good news that you are reproting.

=0A

 

=0A

Assumin= g 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.

=0A<= p style=3D"margin:0;padding:0;">I have no idea how that jibes with low ping= times, unless you are getting the ICMP packets spoofed.

=0A

 

=0A

 =0A

-----Original Message-----
From:= "Sebastian Moeller" <moeller0@gmx.de>
Sent: Wednesday, August 1= 5, 2012 1:23pm
To: "Dave Taht" <dave.taht@gmail.com>
Cc: ce= rowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt= 3.3.8-17 is released

=0A
= =0A

Hi Dave,

great work, as alwa= ys 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
Netalyzr reports around 2800ms seconds of uplink buffering, yet sa= turating the uplink does not affect ping times to a remote target noticeabl= y, basically the same as for all codellized ceo versions I tested so far...=

Some notes and a question:
I noticed that even given plent= y of swap space (1GB on a usb stick), using http://broadband.mpi-sws.org/re= sidential/ to exercise UDP stress (on the uplink I assume) I can easily pro= duce (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 all= oc of size 1926 failed
(and plenty of those=E2=80=A6).
What then= happens is that the OOM killer will aim for bind (reasonable since it is t= he largest single process) and kill it. When I try to restart bind by:
root@nacktmulle:~# /etc/rc.d/S47namedprep start
root@nacktmulle:~# /e= tc/rc.d/S48named restart
Stopping isc-bind
/etc/chroot/named//va= r/run/named/named.pid not found, trying brute force
killall: named: n= o process killed
Kicking isc-bind in xinetd
rndc: connect failed:= 127.0.0.1#953: connection refused
And bind does not start again and t= he 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, Dav= e Taht wrote:

> I'm too tired to write up a full set of relea= se notes, but I've been
> testing it all day,
> and it look= s 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 we= ek's ietf meeting. Well worth watching. At the end he outlines
> th= e deployment problems in particular.
>
> http://recordings= .conf.meetecho.com/Recordings/watch.jsp?recording=3DIETF84_TSVAREA&chap= ter=3Dpart_3
>
> Far more interesting than this email!
>
>
> --
> Dave T=C3=A4ht
> http://= www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
> with= fq_codel!"
> _______________________________________________
= > Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.n= et
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

_______________________________________________
Cerowrt-devel mailin= g list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbl= oat.net/listinfo/cerowrt-devel

=0A
 ------=_20120815185342000000_33299--