Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: dpreed@reed.com
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] cerowrt 3.3.8-17 is released
Date: Wed, 15 Aug 2012 21:51:11 -0700	[thread overview]
Message-ID: <CE5E0FFF-3A0B-467A-B781-286F0E0AB631@gmx.de> (raw)
In-Reply-To: <1345071222.04317697@apps.rackspace.com>

Hi,


On Aug 15, 2012, at 3: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 see, pretty much what I expected in regards to methodology, even though I am not sure about the 'maximum load it can generate part'. 


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

	My take on this was that the 3 seconds max buffer seemed wrong, even though the interactivity was/is right there where it should be with codel. BTW I was following Dave's recommendation and used openwork's default QOS instead of simple_qos.sh if that matters.

>  
> 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.

	My totally current pet theory (totally created with out looking at data) is that fq_codel somehow manages to confine the over buffering to the UDP probe flow(s) and keep my pings in unencumbered flows (that or openwrts hfsc packet scheduler saves the interactivity…). But as I stated I have no data to back this up (nor am I likely to get some any time soon).

Thanks
	Sebastian

>  
>  
> -----Original Message-----
> From: "Sebastian Moeller" <moeller0@gmx.de>
> Sent: Wednesday, August 15, 2012 1:23pm
> To: "Dave Taht" <dave.taht@gmail.com>
> 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…). 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
> > 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


  parent reply	other threads:[~2012-08-16  4:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-13  6:08 Dave Taht
2012-08-13 16:06 ` Maciej Soltysiak
2012-08-13 16:20   ` Dave Taht
2012-08-15 17:23 ` Sebastian Moeller
2012-08-15 22:53   ` dpreed
2012-08-15 22:57     ` William Katsak
2012-08-16  4:54       ` Sebastian Moeller
2012-08-16 11:08         ` William Katsak
2012-08-16 17:02           ` dpreed
2012-08-20 18:17             ` Sebastian Moeller
2012-08-16  4:51     ` Sebastian Moeller [this message]
2012-08-16  4:58       ` Dave Taht
2012-08-16  6:09         ` Sebastian Moeller
2012-08-20 18:13         ` Sebastian Moeller
2012-08-16  4:08   ` Dave Taht
2012-08-16  5:15     ` Sebastian Moeller
2012-08-20 18:24     ` Sebastian Moeller
2012-08-21  2:33       ` dpreed
2012-08-21  2:44         ` Marchon
2012-08-21  5:28           ` Sebastian Moeller
2012-08-22 18:23             ` dpreed
2012-08-22 18:54               ` Dave Taht
2012-08-22 19:23                 ` Kenneth Finnegan
2012-08-22 20:44                   ` Dave Taht
2012-08-21  5:23         ` Sebastian Moeller
2012-08-17  8:52 ` [Cerowrt-devel] cerowrt 3.3.8-17: nice latency improvements, some issues with bind Török Edwin
2012-08-17 18:05   ` Dave Taht
2012-08-17 19:05     ` Török Edwin
2012-08-17 19:52       ` Dave Taht
2012-08-17 20:13         ` Török Edwin
2012-08-18 20:16         ` Michael Richardson
2012-08-20 20:16           ` david
2012-08-20 20:41             ` George Lambert
2012-08-20 20:48               ` david
2012-08-20 21:27                 ` George Lambert
2012-08-20 23:19               ` Michael Richardson
2012-08-21 22:03                 ` Maciej Soltysiak
2012-08-21 22:31                   ` George Lambert
2012-08-22  1:21                   ` Michael Richardson
2012-08-18  9:38     ` Török Edwin
2012-08-18 10:20       ` [Cerowrt-devel] [Bloat] " Jonathan Morton
2012-08-18 17:07       ` [Cerowrt-devel] " Dave Taht
2012-08-25 13:56         ` Török Edwin
2012-08-25 18:09           ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CE5E0FFF-3A0B-467A-B781-286F0E0AB631@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dpreed@reed.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox