[Cake] Running Cake at long RTTs
kevin at darbyshire-bryant.me.uk
Fri Oct 30 16:30:29 EDT 2015
On 29/10/15 17:36, Kevin Darbyshire-Bryant wrote:
> On 27/10/15 15:14, Toke Høiland-Jørgensen wrote:
>> So Dave and I did a bit of testing of Cake at a 1-second base RTT. That
>> showed that, compared with a straight FIFO queue (with a sufficiently
>> large buffer), throughput was suffering quite a bit under Cake,
>> especially at large bandwidths. We did two changes to fix this:
>> - Turn the hard packet queue size into a lower bound rather than an
>> upper bound.
>> - Scale the target to be 1/16th of the interval.
>> The first change allows Cake to actually reach the target throughput,
>> but it still takes a long while to get there. With the second change, we
>> actually get the desired behaviour. The attached plot shows the
>> difference, with the solid line being before the change and the dashed
>> line being after the change.
>> Patch attached.
> That patch is really going to behave strangely indeed. You end up with
> b->cparams.interval = max(rtt_est_ns + b->cparams.target -
> ns_target,b->cparams.target * 8);
> b->cparams.target = max(max(byte_target_ns, ns_target),
> b->cparams.interval >> 4);
> So interval no matter what happens takes note of 'cparams.target' which
> hasn't yet been set (on first run is 0)
> And target wants to take interval/16, which may be based on the previous
> calculation. Erm. Needs more thought.
> My brain isn't working at the moment due to illness, but recursively
> playing with bandwidth settings on cake is most entertaining at the
> moment ;-)
> Kevin (dead with cold/high as a kite on cold drugs)
Right, I've just pushed a slightly uncomfortable fix for this but it
does at least make cake behave in a deterministic manner again.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
More information about the Cake