[Codel] [Cake] Control theory and congestion control
dave.taht at gmail.com
Sun May 10 14:25:03 EDT 2015
On Sun, May 10, 2015 at 10:48 AM, Dave Taht <dave.taht at gmail.com> 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:
> 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)
> I think it is back to ns3 to get better grips on some of this.
>> Best Regards
>>> 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
>>>> Cake at lists.bufferbloat.net
>>> Dave Täht
>>> Open Networking needs **Open Source Hardware**
>>> Codel mailing list
>>> Codel at lists.bufferbloat.net
> Dave Täht
> Open Networking needs **Open Source Hardware**
Open Networking needs **Open Source Hardware**
More information about the Codel