From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A649921F0D3 for ; Tue, 1 Apr 2014 11:21:47 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so7719380wgh.8 for ; Tue, 01 Apr 2014 11:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=M/3aeaU/jEJtzL+hXWBMH+Olfrmc0FzSjvS4YjHOSxI=; b=Kozi2ExM/1a86ODqHEpVQjCxRVWP+gQhnPGK9Ni0hXZKlGzgWcyU/rzNUJzPYFNfvu CjbwexO+pFauUXwVHawTpqZJdTBAN5hgbFMDSgqz3ITVzZZT0ji51uvCL802/sxoal+r eBuh6MRCl8ibxFkJR1SFSL9R8QrsXBKFoa0NLNbtGjSaz+Gtg32uze13+UU/AdGastzD I+ucgSznlNNIieyPwqVVYFtlUdd0Wzp2b+LJYBUPNcNg5+htrvj62iBBZ2BPWDkM/qTT PQ0bJDfM5/Stpu85TEIEapb0AZVBvqQNuB/FdmiA6pI4PrSvnyPnjNlLbf8FDijsLsRg QoLQ== MIME-Version: 1.0 X-Received: by 10.180.37.178 with SMTP id z18mr22039603wij.46.1396376504763; Tue, 01 Apr 2014 11:21:44 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Tue, 1 Apr 2014 11:21:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 11:21:44 -0700 Message-ID: From: Dave Taht To: Aaron Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] 3.10.32-12 results on Free.fr 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: Tue, 01 Apr 2014 18:21:48 -0000 On Thu, Mar 27, 2014 at 3:21 AM, Aaron Wood wrote: > Dave had asked about results from .32-12 on DSL, and in particular how pi= e > was fairing on dsl. I finally was able to setup a clean test env yesterd= ay, > and ran a bunch of tests. > > Results: > http://burntchrome.blogspot.com/2014/03/cerowrt-31032-12-sqm-comparison-o= n.html > > Takeaways: > > - I'm still dropping a lot of "small-flow" packets when heavily loaded, I= 'm > not sure why. Free.fr's freebox doesn't do this, it's definitely in cero= . Try the simplest.qos model. > > - pie still sucks on dsl (or on my dsl). latency with rrul was up over 1= sec > (and continually growing over the course of the test) Hmm. I see it spike at 120ms on the rrul test and also otherwise have trouble with stuff in slow start, particularly at bandwidths below 5mb= it... > > I feel like _something_ is misconfigured, and that's why I'm dropping > packets the way that I am. I really would like to solve that. Free.fr's > sfq implementation behaves quite nicely, and by comparison, doesn't drop = UDP > packets under load. So you are not behind a freedombox revolution V6? (that's the linux 3.6 fq_codel version) post 3.6 fq_codel will drop some packets from all flows in order to reduce latency. I wish the netperf benchmark had better behavior for the udp flows rather than stopping after the first loss... some non-bursty packet loss really isn't a problem for things like voip, and dns traffic. But that said, I liked this 3.6 behavior of codel and sometimes wish we had a better solution for sparser flows under heavy load than what is in there now. Pie has sprouted a very large estimation window in the Linux release, and it's not a surprise to me that it doesn't work well below 10Mbit... But I have generally been reluctant to publish benchmarks on pie of my own (since, despite working on making pie work rather hard, I would be seen to have a bias), and thus I encourage others to try it using whatever benchmarks they wish to use, and keep working on finding ways to improve the ns2 models others are working from... Now that there is a final pie version in linux 3.14, I feel more comfortable attempting benchmarks on a wide range of bandwidths and conditions, (but would prefer more people tried more stuff). I DID do some testing with webrtc today, and am thinking leveraging/improving their benchmarks and methods with testing aqm and packet schedulers makes sense. A 3 way intercontinental call was pretty much perfect with fq_codel while running a rrul test: http://snapon.lab.bufferbloat.net/~d/mike/webrtc.svg (the dip in the data was when I ALSO transferred a large file) And the pie result, while not horrible, did have some sort of observable problems when I hit it with traffic in slow start, which I didn't manage to capture... http://snapon.lab.bufferbloat.net/~d/mike/pie.svg One thing I've noticed is the academic community is now seemingly defining "bufferbloat" as something that happens with > 200ms induced queuing delay delay, where I (we) define it as "excessive queueing", and in this group, are "settling" for <20ms delay in both directions in most cases. This really changes the mental model a lot. TCP reacts very differently at 200ms RTT than 5ms. I keep seeing papers that put one end of the link with 100ms worth of buffe= ring, against X aqm on the other end of the link, and doing measurements... where here we artificially put it on both sides lacking hope the big dlsm/cmts vendors will do anything to fix it.... The part that bugs me is that if you say "bufferbloat is > 200ms induced queuing delay" and then look at data, you can show that bufferbloat occurs only rarely in the 90 percentile of normal use. If on the other hand you regard > 20ms queuing delay as bufferbloat, or something more dynamic like "persistent queue lasting more than X * 1.1 * RTT", the rate of bufferbloat occurrence in the real world goes way, way, up. > > This was all ipv4-only (I haven't asked the apartment owner to turn on ip= v6 > with Free.fr). > > In about 2 months, I'll be back in the Bay Area. With either sonic.net D= SL > (bonded channels for 30/2 service), or with Comcast. Comcast most likely= . > It would be nice to have 3-5Mb upload again. sonic has a higher end service too, so far as I know. > Any other tests/questions, feel free to ask. I can perform tests in the > morning and early afternoon when things are quiet around here. > > -Aaron > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html