On Sun, May 10, 2015 at 10:48 AM, Dave Taht <[email protected]> wrote:
>>> A control theory-ish issue with codel is that it depends on an >>> arbitrary ideal (5ms) as a definition for "good queue", where "a >>> gooder queue” >> >> I thought that our set point really is 5% of the estimated RTT, and >> we just default to 5 sincere we guestimate our RTT to be 100ms. Not that I >> complain, these two numbers seem to work decently over a relive broad range >> of true RTTs… > > Yes, I should have talked about it as estimated RTT (interval) and a > seemingly desirable percentage(target). It is very helpful to think of > it that way if (as in my current testing) you are trying to see how > much better you can do at very short (sub 1ms) RTTs, where it really > is the interval you want to be modifying... oops. I meant target = interval >> 4; and would have decreased interval by a larger amount or something relative to the rate, but merely wanted to see the slope of the curve, and really need to write cake_drop_monitor rather than just "watch tc -s qdisc show dev eth0" > > I have been fiddling with as a proof of concept - not an actual > algorithm - how much shorter you can make the queues at short RTTs. > What I did was gradually (per packet) subtract 10ns from the cake > target while at 100% utilization until the target hit 1ms (or bytes > outstanding dropped below 3k). Had the cake code still used a > calculated target from the interval (target >> 4) I would have fiddled > with the interval instead. Using the netperf-wrapper tcp_upload test: > > There were two significant results from that (I really should just > start a blog so I can do images inline) > > 1) At 100Mbit, TSO offloads (bulking) add significant latency to > competing streams: > > http://snapon.lab.bufferbloat.net/~d/cake_reduced_target/offload_damage_100mbit.png > > This gets much worse as you add tcp flows. I figure day traders would > take notice. TSO packets have much more mass. > > 2) You CAN get less packets outstanding at this RTT and still keep the > link 100% utilized. > > The default codel algo stayed steady at 30-31 packets outstanding with > no losses or marks evident (TSQ?) while the shrinking dynamic target > ecn marked fairly heavily and ultimately reduced the packets > outstanding to 7-17 packets with a slight improvement in actual > throughput. (This stuff is so totally inside the noise floor that it > is hard to discern a difference at all - and you can see the linux > de-optimization for handing ping packets off to hardware in some of > the tests, after the tcp flows end, which skews the latency figures) > > http://snapon.lab.bufferbloat.net/~d/cake_reduced_target/dynamic_target_vs_static.png > > I think it is back to ns3 to get better grips on some of this. > >> >> >> Best Regards >> Sebastian >> >>> is, in my definition at the moment, "1 packet outstanding ever closer >>> to 100% of the time while there is 100% utilization". >>> >>> We could continue to bang on things (reducing the target or other >>> methods) and aim for a lower ideal setpoint until utilization dropped >>> below 100%. >>> >>> Which becomes easier the more flows we know are in progress. >>> >>>> - Jonathan Morton >>>> >>>> >>>> _______________________________________________ >>>> Cake mailing list >>>> [email protected] >>>> https://lists.bufferbloat.net/listinfo/cake >>>> >>> >>> >>> >>> -- >>> Dave Täht >>> Open Networking needs **Open Source Hardware** >>> >>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >>> _______________________________________________ >>> Codel mailing list >>> [email protected] >>> https://lists.bufferbloat.net/listinfo/codel >> > > > > -- > Dave Täht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
