[Cake] cake target corner cases?
alan.christopher.jenkins at gmail.com
Mon Nov 2 15:38:11 EST 2015
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 at 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
> 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.
More information about the Cake