On Tue, Jun 9, 2015 at 10:14 AM, Simon Barber <[email protected]> wrote: > My concern with fq_codel is that by putting single flows into single Codel > instances you hit the problem with Codel where it limits bandwidth on higher > RTT paths.
I recently did a bit of work, testing rtt_fairness from my location (los gatos, california) to linodes in london, dallas, tokoyo, and newark, at RTTs of roughly 145, 45, 115, and 85ms. The servers are all using sch_fq and a modern linux (on a vm) There is a rangley box inbetween running the sqm scripts that let me test pie, codel, fq_codel, cake, etc. On the long path, with pie, the download rate was generally higher than on the shorter paths, which was kind of interesting and would bear a repeated look at. Codel, more even, and fq_codel was very even across all rtts. http://snapon.lab.bufferbloat.net/~d/qdisc-stats2/download_comparison.png http://snapon.lab.bufferbloat.net/~d/qdisc-stats2/upload_comparison.png (rawer data in that dir or you can get it all via: http://snapon.lab.bufferbloat.net/~d/qdisc-stats2.tgz toke is also working on getting buffering, drop, and delay measurements, some of those and preliminary plot types are in there also. pull flent from git. ) the rtt_fair4be dataset is noisy (and limited to my local connection speed of 70/10mbits) If anyone would like access to these servers for more extensive testing, I still have quite a few more gigabits to use up, and no time to use them. Contact me offlist for access. > Simon > > Sent with AquaMail for Android > http://www.aqua-mail.com > > > > On June 9, 2015 9:32:15 AM Jonathan Morton <[email protected]> wrote: > >> >> > On 9 Jun, 2015, at 19:11, Steven Blake <[email protected]> wrote: >> > >> > On a 10 GE link >> > serving 2.5 MPPs on average, CoDel would only drop 0.013% of packets >> > after 1000 drops (which would occur after 6.18 secs). This doesn't seem >> > to be very effective. >> >> Question: have you worked out what drop rate is required to achieve >> control of a TCP at that speed? There are well-known formulae for standard >> TCPs, particularly Reno. You might be surprised by the result. >> >> Fundamentally, Codel operates on the principle that one mark/drop per RTT >> per flow is sufficient to control a TCP, or a flow which behaves like a TCP; >> *not* a particular percentage of packets. This is because TCPs are >> generally required to perform multiplicative decrease upon a *single* >> congestion event. The increasing count over time is meant to adapt to >> higher flow counts and lower RTTs. Other types of flows tend to be sparse >> and unresponsive in general, and must be controlled using some harder >> mechanism if necessary. >> >> One such mechanism is to combine Codel with an FQ system, which is exactly >> what fq_codel in Linux does. Fq_codel has been tested successfully at >> 10Gbps. Codel then operates separately for each flow, and unresponsive >> flows are isolated. >> >> - Jonathan Morton >> >> _______________________________________________ >> aqm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/aqm > > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
