<html><head></head><body bgcolor="#FFFFFF"><div>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 (<span class="Apple-style-span" style>Netalyzr) </span><span class="Apple-style-span" style>natively, but as soon as I got the AQM running<span class="Apple-style-span" style> properly, that went away completely. </span></span></div>
<div><br></div><div>Bill<br><br>Sent from my iPhone</div><div><br>On Aug 15, 2012, at 6:53 PM, "<a href="mailto:dpreed@reed.com">dpreed@reed.com</a>" <<a href="mailto:dpreed@reed.com">dpreed@reed.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div><font face="arial"><p style="margin:0;padding:0">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.</p>

<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">I don't think this is good news that you are reproting.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>

<p style="margin:0;padding:0">I have no idea how that jibes with low ping times, unless you are getting the ICMP packets spoofed.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">-----Original Message-----<br>From: "Sebastian Moeller" <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>><br>Sent: Wednesday, August 15, 2012 1:23pm<br>To: "Dave Taht" <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>><br>
Cc: <a href="mailto: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="SafeStyles1345070706">
<p style="margin:0;padding:0">Hi Dave,<br><br>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…<br>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...<br>
<br>Some notes and a question:<br>I noticed that even given plenty of swap space (1GB on a usb stick), using <a href="http://broadband.mpi-sws.org/residential/">http://broadband.mpi-sws.org/residential/</a> 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):<br>
Aug 15 01:16:29 nacktmulle kern.err kernel: [175395.132812] ath: skbuff alloc of size 1926 failed<br>(and plenty of those…). <br>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:<br>
root@nacktmulle:~# /etc/rc.d/S47namedprep start<br>root@nacktmulle:~# /etc/rc.d/S48named restart<br>Stopping isc-bind<br> /etc/chroot/named//var/run/named/named.pid not found, trying brute force <br>killall: named: no process killed<br>
Kicking isc-bind in xinetd<br>rndc: connect failed: 127.0.0.1#953: connection refused<br>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<br>
<br><br><br>best regards<br> sebastian<br><br>On Aug 12, 2012, at 11:08 PM, Dave Taht wrote:<br><br>> I'm too tired to write up a full set of release notes, but I've been<br>> testing it all day,<br>> and it looks better than -10 and certainly better than -11, but I won't know<br>
> until some more folk sit down and test it, so here it is.<br>> <br>> <a href="http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/">http://huchra.bufferbloat.net/~cero1/3.3/3.3.8-17/</a><br>> <br>> fresh merge with openwrt, fix to a bind CVE, fixes for 6in4 and quagga<br>
> routing problems,<br>> and a few tweaks to fq_codel setup that might make voip better.<br>> <br>> Go forth and break things!<br>> <br>> In other news:<br>> <br>> Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel<br>
> at last week's ietf meeting. Well worth watching. At the end he outlines<br>> the deployment problems in particular.<br>> <br>> <a href="http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREA&chapter=part_3">http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREA&chapter=part_3</a><br>
> <br>> Far more interesting than this email!<br>> <br>> <br>> -- <br>> Dave Täht<br>> <a href="http://www.bufferbloat.net/projects/cerowrt/wiki">http://www.bufferbloat.net/projects/cerowrt/wiki</a> - "3.3.8-17 is out<br>
> with fq_codel!"<br>> _______________________________________________<br>> Cerowrt-devel mailing list<br>> <a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br><br>_______________________________________________<br>Cerowrt-devel mailing list<br><a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a></p>
</div></font></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Cerowrt-devel mailing list</span><br><span><a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a></span><br>
<span><a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a></span><br></div></blockquote></body></html>