Re: [Bloat] [Codel] [Cake] Control theory and congestion control

[Dave Taht <dave.taht@gmail.com>]

On Sun, May 10, 2015 at 10:48 AM, Dave Taht <dave.taht@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:
>
> 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
>>>> Cake@lists.bufferbloat.net
>>>> 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
>>> Codel@lists.bufferbloat.net
>>> 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