From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 71EE2200B49 for ; Wed, 15 Aug 2012 15:57:08 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so73077wib.10 for ; Wed, 15 Aug 2012 15:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=pw3eqN5Bg0+8fSZrGKZ4tGqf2AqSXqGvqflgiowSfRU=; b=Dwsa3PfqOravZpsroyifnPP1An6i+x1az4opTkugiDGKRciq+VAavwchl0zU2cJzL2 Xmzrqn8PpoqZvYImL6Q3eTAK75wo0qMYXYwwP2hW/wOy6NIxnBjUXwuOPu+HvCLzT51k NY8s2M+GxR+M/8Aj8zJY0oN6fTCd8dbWJm3JtxaB85+eU7zRt+X1NcJzB2wp37QZ5lgm cBsrypQ53wbBxxddc9UAHKtZxfq46QBsB/Szs0DmgTwTYexhwZcMfVA7n/Oqj57JeF5D NvagS9LkeTqbfq8gVtZZ+IRG/nfe/Tnntn43HEVSy4HpTIoFBIhbfgR5VCbKNJ7DZhF7 /gow== Received: by 10.216.243.10 with SMTP id j10mr11143465wer.211.1345071426156; Wed, 15 Aug 2012 15:57:06 -0700 (PDT) References: <36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de> <1345071222.04317697@apps.rackspace.com> From: William Katsak In-Reply-To: <1345071222.04317697@apps.rackspace.com> Mime-Version: 1.0 (1.0) Date: Wed, 15 Aug 2012 18:57:04 -0400 Message-ID: <6403367419286815483@unknownmsgid> To: "dpreed@reed.com" Content-Type: multipart/alternative; boundary=e0cb4e38520a8dbab304c755d8d9 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:57:09 -0000 --e0cb4e38520a8dbab304c755d8d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. 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_code= l > 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=3DIETF84= _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 --e0cb4e38520a8dbab304c755d8d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I agree with this assessm= ent as far as behavior goes. =A0With my recent experimentation on a Russian= DSL line, I was seeing ~1200ms of uplink buffer reported (Netalyzr)=A0natively, but as soon as I got the AQM running=A0properly, that went away completely.=A0

Bill

Sent from my iPhone

On Aug 15= , 2012, at 6:53 PM, "dpreed@reed.co= m" <dpreed@reed.com> = wrote:

Just to clarify, the way Netalyzr attempts to= measure "uplink buffering" may not actually measure queue length= .=A0=A0 It just spews UDP packets at the target, and measures sender-receiv= er packet delay at the maximum load it can generate.=A0=A0 So it's maki= ng certain assumptions about the location and FIFO nature of the "bott= leneck queue" when it calculates that.

=A0

I don't think this is good news that yo= u are reproting.

=A0

Assuming codel is measuring "sojourn t= ime" 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.

=A0

=A0

-----Original Message-----
From: "S= ebastian Moeller" <moeller0@gmx.= de>
Sent: Wednesday, August 15, 2012 1:23pm
To: "Dave Tah= t" <dave.taht@gmail.com&= gt;
Cc: cerowrt-devel@li= sts.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is= released

Hi Dave,

great work, as always I upg= raded my production router to the latest and greatest (since I only have on= e router=85). And it works quite well for normal usage=85
Netalyzr repor= ts around 2800ms seconds of uplink buffering, yet saturating the uplink doe= s not affect ping times to a remote target noticeably, basically the same a= s 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 all= oc of size 1926 failed
(and plenty of those=85).
What then happens i= s 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/n= amed/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: connecti= on refused
And bind does not start again and the router becomes less tha= n useful. Now I assume I am doing something wrong, but what, if you have an= y 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 r= elease 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 merg= e with openwrt, fix to a bind CVE, fixes for 6in4 and quagga
> routing problems,
> and a few tweaks to fq_codel setup that migh= t 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 ou= tlines
> the deployment problems in particular.
>
> http://recordings.conf.meetecho.com= /Recordings/watch.jsp?recording=3DIETF84_TSVAREA&chapter=3Dpart_3 >
> Far more interesting than this email!
>
>
&g= t; --
> 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.bufferbloa= t.net
https://li= sts.bufferbloat.net/listinfo/cerowrt-devel

______= _________________________________________
Cerowrt-devel mai= ling list
Cerowrt-devel@lists.bufferbloat.net
http= s://lists.bufferbloat.net/listinfo/cerowrt-devel
--e0cb4e38520a8dbab304c755d8d9--