Re: [Cake] cake target corner cases?

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 02/11/15 18:49, Sebastian Moeller wrote:
> Hi Alan,
Hi again Sebastian

> On Nov 2, 2015, at 17:20 , Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
>
>> Actually I'm
>> failing to measure any changes at all, even for mtu*1.5.  I'm sure
>> there's a real effect on buffering, if I had a less noisy way to
>> measure it :(.  I couldn't work out exactly what you wanted testing;
>> if there's something more specific I could probably spend more time on
>> it.
> 	This is pretty much what I expected; the only interesting measurement left then is to disable this completely and see how a to small target affects latency under load… (I just wonder if this might be better measured with larger probe packets, say full MTU ICMP packets instead of small ones?)

Good point!  I should test with the "adaptation" feature entirely 
disabled, i.e. target=5ms.  There should be a case where it decreases 
bandwidth.  Setting the rate artificially low might be useful to make it 
easier to measure.

Ah, the worst case for bandwidth should be a single stream, with tcp 
congestion control set to Reno (like non-server versions of Windows).  
Whereas my basic tests are multi-stream and use Linux' default Cubic.  
So that's probably what I was doing wrong.

>> I agree with the reasoning for 1749 bytes.  If you think mtu*1.5 is a
>> good idea for SQM, I can't follow the logic, but it wouldn't bother me
>> for fq_codel.
> 	Oh, the 1.5 * 1749 is really just to be on the safe side, but until this setting makes a dent in at least one measurement, I guess I am not going to bother increasing this further; I will try to play with keeping interval at 20 to 10 times target though...

I guess you want a similar setup to the 1s rtt test.  Simulate a path 
delay of exactly 100ms, set a low rate, then look at the effect interval 
has on bandwidth.

Regards
Alan