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.
>>
>> -Toke
> 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.
>
>