This was -6, so I was using simple_qos.sh. Bill
Sent from my iPhone On Aug 16, 2012, at 12:54 AM, Sebastian Moeller <[email protected]> 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 >> 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. > > QOS or simple_qos.sh? I might switch to simple_qos next to see the effects > there. > > best > Sebastian > >> >> Bill >> >> Sent from my iPhone >> >> On Aug 15, 2012, at 6:53 PM, "[email protected]" <[email protected]> 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" <[email protected]> >>> Sent: Wednesday, August 15, 2012 1:23pm >>> To: "Dave Taht" <[email protected]> >>> Cc: [email protected] >>> 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…). And it works quite well for >>> normal usage… >>> 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…). >>> 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_codel >>>> 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=IETF84_TSVAREA&chapter=part_3 >>>> >>>> Far more interesting than this email! >>>> >>>> >>>> -- >>>> Dave Täht >>>> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out >>>> with fq_codel!" >>>> _______________________________________________ >>>> Cerowrt-devel mailing list >>>> [email protected] >>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> [email protected] >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> [email protected] >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
