On Fri, May 22, 2015 at 11:42 PM, Jonathan Morton <[email protected]> wrote: > In practice, I haven't noticed any loss of throughput due to using Codel on > 100ms+ RTTs. Probably most servers now use CUBIC, which contributes to that > impression.
There are only slight differences between these tcps (and everybody just uses multiple flows to do stuff anyway) > Using ECN rather than tail drops also makes the delivery > smoother. I can try some longer rtts than this (10,70). this was against the latest cake on linux 4.1rc3. http://snapon.lab.bufferbloat.net/~cero3/renovscubic.tgz (or the dir) > > There is a flaw in your analysis. Codel only starts dropping (or marking) > when the sojourn time has remained above target (5ms) for an entire interval > (100ms), during which time the cwnd is still growing. Thus the peak queue > occupancy is more than 5ms. yes. people keep missing the "wait for an interval" thing in codel. > It is however probably fair to say that a single Reno flow does lose some > throughput under AQM. very clear plot of reno's classic sawtooth behavior vs cubics: http://snapon.lab.bufferbloat.net/~cero3/renovscubic/reno.png http://snapon.lab.bufferbloat.net/~cero3/renovscubic/cubic.png On a 200ms rtt things look more interesting, but aqm hardly enters into it. Reno is simply less efficient than cubic, period. but I'll leave it to you to generate your own plots if you want, out of the netperf-eu dataset above. (it would be nice to be able to generate directly comparable plots vs cc algo types, presently you can't combine these data sets in "flent") > > - Jonathan Morton > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
