On Thu, Mar 27, 2014 at 3:21 AM, Aaron Wood <[email protected]> wrote: > Dave had asked about results from .32-12 on DSL, and in particular how pie > was fairing on dsl. I finally was able to setup a clean test env yesterday, > and ran a bunch of tests. > > Results: > http://burntchrome.blogspot.com/2014/03/cerowrt-31032-12-sqm-comparison-on.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 1sec > (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 5mbit... > > 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 buffering, 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 ipv6 > with Free.fr). > > In about 2 months, I'll be back in the Bay Area. With either sonic.net DSL > (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 > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
