From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <marchon@gmail.com>
Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com
	[209.85.212.43]) (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 8D10021F0E6
	for <cerowrt-devel@lists.bufferbloat.net>;
	Mon, 20 Aug 2012 19:44:58 -0700 (PDT)
Received: by vbbfq11 with SMTP id fq11so15100404vbb.16
	for <cerowrt-devel@lists.bufferbloat.net>;
	Mon, 20 Aug 2012 19:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to;
	bh=jmgxPGLPIhz4Tc/PIxKdqtuyfHlR4BctTvyIS4csdBk=;
	b=Sglz0Omos/oFzAu3jk9/5WzsdiUwSYac+kkH0pwU+OXISkA9iqc31Iy7FTCyFuCxzM
	eB9DmOuJPV5OrLyhmuNl8NAG61ue5Oj15TO/0DkOot0Wi2am0Wf+Jl5ioBV2LHmxG0oC
	aJB0+uG0JqU7XlimAeKLE0t56q9XZCVZ/nQJy9Qti67k2iPYX8EFdBQMXI2+gRAtoMnQ
	FlHd6UgrqVBtoOhGq0HvAxzIBXaJwhtHwfB+DenNnGsMTDt48kg9hbbkPnR88s41aAMR
	Cr7P2qkWK8A39DrvMJX/sMl3uj455N5Z4r/Bg/NUBhiMGkhW+CXpTnZl3+lbGp4oSSQk
	SYvA==
Received: by 10.220.39.206 with SMTP id h14mr12077041vce.63.1345517097258;
	Mon, 20 Aug 2012 19:44:57 -0700 (PDT)
Received: from [192.168.1.207] (c-76-24-143-33.hsd1.nh.comcast.net.
	[76.24.143.33])
	by mx.google.com with ESMTPS id xd6sm98956vec.7.2012.08.20.19.44.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 20 Aug 2012 19:44:56 -0700 (PDT)
References: <CAA93jw50MeqWH6TVKditFGfg-V-mOi-UUtsABqd+WHs2vedHQw@mail.gmail.com>
	<36D61FDC-9AA9-46CC-ACBB-2D28B250C660@gmx.de>
	<CAA93jw5JV0L0MLYxuO-ok2joOkodie_JkxNs_VAJat_eYhV1gw@mail.gmail.com>
	<2998C331-777B-41B3-A6BC-8285461EF729@gmx.de>
	<1345516397.664231592@apps.rackspace.com>
In-Reply-To: <1345516397.664231592@apps.rackspace.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-EE254C72-523B-46B8-9621-219F96A4BE58
Message-Id: <E7CFED87-2E10-4DF9-8A6B-06B2787476A1@gmail.com>
X-Mailer: iPhone Mail (9B206)
From: Marchon <marchon@gmail.com>
Date: Mon, 20 Aug 2012 22:44:52 -0400
To: "dpreed@reed.com" <dpreed@reed.com>
Cc: "cerowrt-devel@lists.bufferbloat.net" <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
	<cerowrt-devel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cerowrt-devel>
List-Post: <mailto:cerowrt-devel@lists.bufferbloat.net>
List-Help: <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2012 02:44:59 -0000


--Apple-Mail-EE254C72-523B-46B8-9621-219F96A4BE58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It The Fq_codel settings prevent excess buffering on the push of data out ov=
er the cable modem itself / it will prevent unnecessary premature reduction o=
f the  tcp sliding window size further preventing a cascading backlog that e=
nds up further reducing the sliding window and slowing down the overall outb=
ound transfer rate.=20

A buffering problem in the cable modem only happens if you feed it data to q=
uickly.=20






Sent from my iPhone

On Aug 20, 2012, at 10:33 PM, dpreed@reed.com wrote:

> I'm confused.  Fq_codel does not (to my knowledge) fix bufferbloat *in you=
r cable modem*  or *in the CMTS head-end*.
> =20
> How could it?   In order for that to be fixed, you need to manage the buff=
er in the cable modem itself.
> =20
> -----Original Message-----
> From: "Sebastian Moeller" <moeller0@gmx.de>
> Sent: Monday, August 20, 2012 2:24pm
> To: "Dave Taht" <dave.taht@gmail.com>
> Cc: cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released
>=20
> Hi Dave,
>=20
> so I went to play around with this a bit more. I turned to UDP flooding my=
 cable modem through the router and this surely allows me to create enough l=
oad on the wndr3700v2 to cause the allocation errors and as a "bonus" also t=
o drive the router to reboot (driven by the watchdog timer?). Here is the sc=
ript I used over 5G wireless (from http://blog.ioshints.info/2008/03/udp-flo=
od-in-perl.html)
>=20
> #!/usr/bin/perl
> ##############
>=20
> # udp flood.
> ##############
>=20
> use Socket;
> use strict;
>=20
> if ($#ARGV !=3D 3) {
> print "flood.pl <ip> <port> <size> <time>\n\n";
> print " port=3D0: use random ports\n";
> print " size=3D0: use random size between 64 and 1024\n";
> print " time=3D0: continuous flood\n";
> exit(1);
> }
>=20
> my ($ip,$port,$size,$time) =3D @ARGV;
>=20
> my ($iaddr,$endtime,$psize,$pport);
>=20
> $iaddr =3D inet_aton("$ip") or die "Cannot resolve hostname $ip\n";
> $endtime =3D time() + ($time ? $time : 1000000);
>=20
> socket(flood, PF_INET, SOCK_DGRAM, 17);
>=20
>=20
> print "Flooding $ip " . ($port ? $port : "random") . " port with " .=20
> ($size ? "$size-byte" : "random size") . " packets" .=20
> ($time ? " for $time seconds" : "") . "\n";
> print "Break with Ctrl-C\n" unless $time;
>=20
> for (;time() <=3D $endtime;) {
> $psize =3D $size ? $size : int(rand(1024-64)+64) ;
> $pport =3D $port ? $port : int(rand(65500))+1;
>=20
> send(flood, pack("a$psize","flood"), 0, pack_sockaddr_in($pport, $iaddr));=
}
>=20
> called as either
> udp_flood.pl 192.168.100.1 0 1024 240
> or=20
> udp_flood.pl 192.168.100.1 32000 1024 240
>=20
> The first version with randomized port number spreads the load nicely over=
 many fq_codel bins/flows and seems slightly more likely to cause allocation=
 errors and reboots than the 2nd invocation which restricts itself to port 3=
2000 and presumably just one flow.
> I wonder how to make cerowrt survive this kind of stress test=E2=80=A6=20
>=20
> best
> Sebastian
>=20
>=20
> On Aug 15, 2012, at 9:08 PM, Dave Taht wrote:
>=20
> > re: ath: skbuff alloc of size 1926 failed
> >=20
> > as for the ath skbuff problem, I've seen that a lot. I had put hard
> > packet limits (~600) on fq_codel in -11 and prior that were too low
> > and it mostly went away, but I hit tail drop behavior everywhere,
> > instead of codel behavior. What I have now (typically 1200) may well
> > be too high, but not as overly high as the default (10k packets).
> > There may be another means of increasing the size of that slab pool or
> > making it less onerous.
> >=20
> > I would like it if codel "kicked in" earlier than it currently does.
> > The code in ns2 is currently using half the period that the linux code
> > is. This would control things better, or so I hope (planning on trying
> > this as I get time)
> >=20
> > I am also considering means of artificially upscaling the drop
> > scheduler when we get close to queue limits.
> >=20
> > See some discussions on the codel list for these issues. (sims are
> > easier to deal with than cerowrt, too!)
> >=20
> > as for bind, it should be automagically restarted from xinetd, no need
> > to fiddle with anything. However, since you are already under massive
> > memory pressure, it may well fail to start up that way, too. At the
> > moment, I've largely given up on bind on anything but a more core home
> > gw, and am running dnsmasq on everything (3700v2, picostations,
> > nanostations) but the 3800s. (and the ones I run it on, aren't being
> > used for wifi right now).
> >=20
> > Lastly: Swap space won't help you on exhausting kernel limits.
> >=20
> > I'm glad you can reproduce the ath: slab problem - I can get it too at
> > high rates using netperf over wifi. I will try a 3700v2 with and
> > without bind to see if it's still there in 3.3.8-17. In the meantime
> > if anyone knows how to get more allocations in that (2048? 4096?) slab
> > by default, perhaps that will help?
> >=20
> >=20
> >=20
> > On Wed, Aug 15, 2012 at 10:23 AM, Sebastian Moeller <moeller0@gmx.de> wr=
ote:
> >> Hi Dave,
> >>=20
> >> 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 f=
or normal usage=E2=80=A6
> >> Netalyzr reports around 2800ms seconds of uplink buffering, yet saturat=
ing the uplink does not affect ping times to a remote target noticeably, bas=
ically the same as for all codellized ceo versions I tested so far...
> >>=20
> >> Some notes and a question:
> >> I noticed that even given plenty of swap space (1GB on a usb stick), us=
ing 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 5GH=
z 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=E2=80=A6).
> >> What then happens is that the OOM killer will aim for bind (reasonable s=
ince it is the largest single process) and kill it. When I try to restart bi=
nd 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 forc=
e
> >> 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. N=
ow I assume I am doing something wrong, but what, if you have any idea how t=
o solve this short of a reboot of the router (my current method) I would be h=
appy to learn
> >>=20
> >>=20
> >>=20
> >> best regards
> >> sebastian
> >>=20
> >> On Aug 12, 2012, at 11:08 PM, Dave Taht wrote:
> >>=20
> >>> 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.
> >>>=20
> >>> http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/
> >>>=20
> >>> 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.
> >>>=20
> >>> Go forth and break things!
> >>>=20
> >>> In other news:
> >>>=20
> >>> Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_c=
odel
> >>> at last week's ietf meeting. Well worth watching. At the end he outlin=
es
> >>> the deployment problems in particular.
> >>>=20
> >>> http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=3DI=
ETF84_TSVAREA&chapter=3Dpart_3
> >>>=20
> >>> Far more interesting than this email!
> >>>=20
> >>>=20
> >>> --
> >>> 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.net
> >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >>=20
> >=20
> >=20
> >=20
> > --=20
> > Dave T=C3=A4ht
> > http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
> > with fq_codel!"
>=20
> _______________________________________________
> 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

--Apple-Mail-EE254C72-523B-46B8-9621-219F96A4BE58
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body bgcolor=3D"#FFFFFF"><div>It The&nbsp;<span class=3D=
"Apple-style-span" style=3D"font-family: arial; -webkit-tap-highlight-color:=
 rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 2=
27, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469)=
; font-size: small; ">Fq_codel settings prevent excess buffering on the push=
 of data out over the cable modem itself / it will prevent unnecessary prema=
ture reduction of the &nbsp;tcp sliding window size further preventing a cas=
cading backlog that ends up further reducing the sliding window and slowing d=
own the overall outbound transfer rate.&nbsp;</span></div><div><span class=3D=
"Apple-style-span" style=3D"font-family: arial; -webkit-tap-highlight-color:=
 rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 2=
27, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469)=
; font-size: small; "><br></span></div><div><span class=3D"Apple-style-span"=
 style=3D"font-family: arial; -webkit-tap-highlight-color: rgba(26, 26, 26, 0=
.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -we=
bkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: small=
; ">A buffering problem in the cable modem only happens if you feed it data t=
o quickly.&nbsp;</span></div><div><span class=3D"Apple-style-span" style=3D"=
font-family: arial; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);=
 -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-comp=
osition-frame-color: rgba(77, 128, 180, 0.230469); font-size: small; "><br><=
/span></div><div><span class=3D"Apple-style-span" style=3D"font-family: aria=
l; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composit=
ion-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-col=
or: rgba(77, 128, 180, 0.230469); font-size: small; "><br></span></div><div>=
<span class=3D"Apple-style-span" style=3D"font-family: arial; -webkit-tap-hi=
ghlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: r=
gba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128,=
 180, 0.230469); font-size: small; "><br></span></div><div><font class=3D"Ap=
ple-style-span" face=3D"arial" size=3D"2"><span class=3D"Apple-style-span" s=
tyle=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-com=
position-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-fram=
e-color: rgba(77, 128, 180, 0.230469);"><br></span></font></div><div><font c=
lass=3D"Apple-style-span" face=3D"arial" size=3D"2"><span class=3D"Apple-sty=
le-span" style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -=
webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-compos=
ition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span></font><br>Sent=
 from my iPhone</div><div><br>On Aug 20, 2012, at 10:33 PM, <a href=3D"mailt=
o:dpreed@reed.com">dpreed@reed.com</a> wrote:<br><br></div><div></div><block=
quote type=3D"cite"><div><font face=3D"arial" size=3D"2"><p style=3D"margin:=
0;padding:0;">I'm confused.&nbsp; Fq_codel does not (to my knowledge) fix bu=
fferbloat *in your cable modem*&nbsp; or *in the CMTS head-end*.</p>
<p style=3D"margin:0;padding:0;">&nbsp;</p>
<p style=3D"margin:0;padding:0;">How could it?&nbsp;&nbsp; In order for that=
 to be fixed, you need to manage the buffer in the cable modem itself.</p>
<p style=3D"margin:0;padding:0;">&nbsp;</p>
<p style=3D"margin:0;padding:0;">-----Original Message-----<br>From: "Sebast=
ian Moeller" &lt;<a href=3D"mailto:moeller0@gmx.de">moeller0@gmx.de</a>&gt;<=
br>Sent: Monday, August 20, 2012 2:24pm<br>To: "Dave Taht" &lt;<a href=3D"ma=
ilto:dave.taht@gmail.com">dave.taht@gmail.com</a>&gt;<br>Cc: <a href=3D"mail=
to:cerowrt-devel@lists.bufferbloat.net">cerowrt-devel@lists.bufferbloat.net<=
/a><br>Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released<br><br></p>=

<div id=3D"SafeStyles1345516296">
<p style=3D"margin:0;padding:0;">Hi Dave,<br><br>so I went to play around wi=
th this a bit more. I turned to UDP flooding my cable modem through the rout=
er and this surely allows me to create enough load on the wndr3700v2 to caus=
e the allocation errors and as a "bonus" also to drive the router to reboot (=
driven by the watchdog timer?). Here is the script I used over 5G wireless (=
from <a href=3D"http://blog.ioshints.info/2008/03/udp-flood-in-perl.html">ht=
tp://blog.ioshints.info/2008/03/udp-flood-in-perl.html</a>)<br><br>#!/usr/bi=
n/perl<br>##############<br><br># udp flood.<br>##############<br><br>use So=
cket;<br>use strict;<br><br>if ($#ARGV !=3D 3) {<br> print "flood.pl &lt;ip&=
gt; &lt;port&gt; &lt;size&gt; &lt;time&gt;\n\n";<br> print " port=3D0: use r=
andom ports\n";<br> print " size=3D0: use random size between 64 and 1024\n"=
;<br> print " time=3D0: continuous flood\n";<br> exit(1);<br>}<br><br>my ($i=
p,$port,$size,$time) =3D @ARGV;<br><br>my ($iaddr,$endtime,$psize,$pport);<b=
r><br>$iaddr =3D inet_aton("$ip") or die "Cannot resolve hostname $ip\n";<br=
>$endtime =3D time() + ($time ? $time : 1000000);<br><br>socket(flood, PF_IN=
ET, SOCK_DGRAM, 17);<br><br><br>print "Flooding $ip " . ($port ? $port : "ra=
ndom") . " port with " . <br> ($size ? "$size-byte" : "random size") . " pac=
kets" . <br> ($time ? " for $time seconds" : "") . "\n";<br>print "Break wit=
h Ctrl-C\n" unless $time;<br><br>for (;time() &lt;=3D $endtime;) {<br> $psiz=
e =3D $size ? $size : int(rand(1024-64)+64) ;<br> $pport =3D $port ? $port :=
 int(rand(65500))+1;<br><br> send(flood, pack("a$psize","flood"), 0, pack_so=
ckaddr_in($pport, $iaddr));}<br><br>called as either<br>udp_flood.pl 192.168=
.100.1 0 1024 240<br>or <br>udp_flood.pl 192.168.100.1 32000 1024 240<br><br=
>The first version with randomized port number spreads the load nicely over m=
any fq_codel bins/flows and seems slightly more likely to cause allocation e=
rrors and reboots than the 2nd invocation which restricts itself to port 320=
00 and presumably just one flow.<br> I wonder how to make cerowrt survive th=
is kind of stress test=E2=80=A6 <br><br>best<br> Sebastian<br><br><br>On Aug=
 15, 2012, at 9:08 PM, Dave Taht wrote:<br><br>&gt; re: ath: skbuff alloc of=
 size 1926 failed<br>&gt; <br>&gt; as for the ath skbuff problem, I've seen t=
hat a lot. I had put hard<br>&gt; packet limits (~600) on fq_codel in -11 an=
d prior that were too low<br>&gt; and it mostly went away, but I hit tail dr=
op behavior everywhere,<br>&gt; instead of codel behavior. What I have now (=
typically 1200) may well<br>&gt; be too high, but not as overly high as the d=
efault (10k packets).<br>&gt; There may be another means of increasing the s=
ize of that slab pool or<br>&gt; making it less onerous.<br>&gt; <br>&gt; I w=
ould like it if codel "kicked in" earlier than it currently does.<br>&gt; Th=
e code in ns2 is currently using half the period that the linux code<br>&gt;=
 is. This would control things better, or so I hope (planning on trying<br>&=
gt; this as I get time)<br>&gt; <br>&gt; I am also considering means of arti=
ficially upscaling the drop<br>&gt; scheduler when we get close to queue lim=
its.<br>&gt; <br>&gt; See some discussions on the codel list for these issue=
s. (sims are<br>&gt; easier to deal with than cerowrt, too!)<br>&gt; <br>&gt=
; as for bind, it should be automagically restarted from xinetd, no need<br>=
&gt; to fiddle with anything. However, since you are already under massive<b=
r>&gt; memory pressure, it may well fail to start up that way, too. At the<b=
r>&gt; moment, I've largely given up on bind on anything but a more core hom=
e<br>&gt; gw, and am running dnsmasq on everything (3700v2, picostations,<br=
>&gt; nanostations) but the 3800s. (and the ones I run it on, aren't being<b=
r>&gt; used for wifi right now).<br>&gt; <br>&gt; Lastly: Swap space won't h=
elp you on exhausting kernel limits.<br>&gt; <br>&gt; I'm glad you can repro=
duce the ath: slab problem - I can get it too at<br>&gt; high rates using ne=
tperf over wifi. I will try a 3700v2 with and<br>&gt; without bind to see if=
 it's still there in 3.3.8-17. In the meantime<br>&gt; if anyone knows how t=
o get more allocations in that (2048? 4096?) slab<br>&gt; by default, perhap=
s that will help?<br>&gt; <br>&gt; <br>&gt; <br>&gt; On Wed, Aug 15, 2012 at=
 10:23 AM, Sebastian Moeller &lt;<a href=3D"mailto:moeller0@gmx.de">moeller0=
@gmx.de</a>&gt; wrote:<br>&gt;&gt; Hi Dave,<br>&gt;&gt; <br>&gt;&gt; great w=
ork, as always I upgraded my production router to the latest and greatest (s=
ince I only have one router=E2=80=A6). And it works quite well for normal us=
age=E2=80=A6<br>&gt;&gt; Netalyzr reports around 2800ms seconds of uplink bu=
ffering, yet saturating the uplink does not affect ping times to a remote ta=
rget noticeably, basically the same as for all codellized ceo versions I tes=
ted so far...<br>&gt;&gt; <br>&gt;&gt; Some notes and a question:<br>&gt;&gt=
; I noticed that even given plenty of swap space (1GB on a usb stick), using=
 <a href=3D"http://broadband.mpi-sws.org/residential/">http://broadband.mpi-=
sws.org/residential/</a> to exercise UDP stress (on the uplink I assume) I c=
an easily produce (I run the test from a macosx via 5GHz wireless over 1.5 y=
ards):<br>&gt;&gt; Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.13281=
2] ath: skbuff alloc of size 1926 failed<br>&gt;&gt; (and plenty of those=E2=
=80=A6).<br>&gt;&gt; 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 t=
ry to restart bind by:<br>&gt;&gt; root@nacktmulle:~# /etc/rc.d/S47namedprep=
 start<br>&gt;&gt; root@nacktmulle:~# /etc/rc.d/S48named restart<br>&gt;&gt;=
 Stopping isc-bind<br>&gt;&gt;  /etc/chroot/named//var/run/named/named.pid n=
ot found, trying brute force<br>&gt;&gt; killall: named: no process killed<b=
r>&gt;&gt; Kicking isc-bind in xinetd<br>&gt;&gt; rndc: connect failed: 127.=
0.0.1#953: connection refused<br>&gt;&gt; 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 r=
outer (my current method) I would be happy to learn<br>&gt;&gt; <br>&gt;&gt;=
 <br>&gt;&gt; <br>&gt;&gt; best regards<br>&gt;&gt;        sebastian<br>&gt;=
&gt; <br>&gt;&gt; On Aug 12, 2012, at 11:08 PM, Dave Taht wrote:<br>&gt;&gt;=
 <br>&gt;&gt;&gt; I'm too tired to write up a full set of release notes, but=
 I've been<br>&gt;&gt;&gt; testing it all day,<br>&gt;&gt;&gt; and it looks b=
etter than -10 and certainly better than -11, but I won't know<br>&gt;&gt;&g=
t; until some more folk sit down and test it, so here it is.<br>&gt;&gt;&gt;=
 <br>&gt;&gt;&gt; <a href=3D"http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-=
17/">http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/</a><br>&gt;&gt;&gt; <=
br>&gt;&gt;&gt; fresh merge with openwrt, fix to a bind CVE, fixes for 6in4 a=
nd quagga<br>&gt;&gt;&gt; routing problems,<br>&gt;&gt;&gt; and a few tweaks=
 to fq_codel setup that might make voip better.<br>&gt;&gt;&gt; <br>&gt;&gt;=
&gt; Go forth and break things!<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; In other ne=
ws:<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; Van Jacobson gave a great talk about bu=
fferbloat, BQL, codel, and fq_codel<br>&gt;&gt;&gt; at last week's ietf meet=
ing. Well worth watching. At the end he outlines<br>&gt;&gt;&gt; the deploym=
ent problems in particular.<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; <a href=3D"http=
://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=3DIETF84_TSVA=
REA&amp;chapter=3Dpart_3">http://recordings.conf.meetecho.com/Recordings/wat=
ch.jsp?recording=3DIETF84_TSVAREA&amp;chapter=3Dpart_3</a><br>&gt;&gt;&gt; <=
br>&gt;&gt;&gt; Far more interesting than this email!<br>&gt;&gt;&gt; <br>&g=
t;&gt;&gt; <br>&gt;&gt;&gt; --<br>&gt;&gt;&gt; Dave T=C3=A4ht<br>&gt;&gt;&gt=
; <a href=3D"http://www.bufferbloat.net/projects/cerowrt/wiki">http://www.bu=
fferbloat.net/projects/cerowrt/wiki</a> - "3.3.8-17 is out<br>&gt;&gt;&gt; w=
ith fq_codel!"<br>&gt;&gt;&gt; _____________________________________________=
__<br>&gt;&gt;&gt; Cerowrt-devel mailing list<br>&gt;&gt;&gt; <a href=3D"mai=
lto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net=
</a><br>&gt;&gt;&gt; <a href=3D"https://lists.bufferbloat.net/listinfo/cerow=
rt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>&gt;&g=
t; <br>&gt; <br>&gt; <br>&gt; <br>&gt; -- <br>&gt; Dave T=C3=A4ht<br>&gt; <a=
 href=3D"http://www.bufferbloat.net/projects/cerowrt/wiki">http://www.buffer=
bloat.net/projects/cerowrt/wiki</a> - "3.3.8-17 is out<br>&gt; with fq_codel=
!"<br><br>_______________________________________________<br>Cerowrt-devel m=
ailing list<br><a href=3D"mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowr=
t-devel@lists.bufferbloat.net</a><br><a href=3D"https://lists.bufferbloat.ne=
t/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-dev=
el</a></p>
</div></font></div></blockquote><blockquote type=3D"cite"><div><span>_______=
________________________________________</span><br><span>Cerowrt-devel maili=
ng list</span><br><span><a href=3D"mailto:Cerowrt-devel@lists.bufferbloat.ne=
t">Cerowrt-devel@lists.bufferbloat.net</a></span><br><span><a href=3D"https:=
//lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.ne=
t/listinfo/cerowrt-devel</a></span><br></div></blockquote></body></html>=

--Apple-Mail-EE254C72-523B-46B8-9621-219F96A4BE58--