[Cake] cake target corner cases?

[Sebastian Moeller]

Hi Alan,

On Nov 1, 2015, at 21:58 , Alan Jenkins <alan.christopher.jenkins at gmail.com> wrote:

> On 01/11/2015, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Dear cake committee,
>> 
>> I just played around with the most recent sch_cake and noticed:
>> 
>> user at computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc del dev eth0 root
>> user at computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc replace dev eth0 root cake
>> bandwidth 1Mbit ; sudo tc-adv -s qdisc
>> qdisc cake 8005: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows rtt
>> 100.0ms raw
>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>> backlog 0b 0p requeues 0
>> capacity estimate: 1Mbit
>>             Tin 0       Tin 1       Tin 2       Tin 3
>>  thresh       1Mbit   937504bit     750Kbit     250Kbit
>>  target      18.2ms      19.4ms      24.2ms      72.7ms
>> interval     145.3ms     155.0ms     193.8ms     581.4ms
> 
> 
>> Here target is always 12.5% of interval instead of the expected 6.25%
>> 1/16 = 0.0625
>> 72.7/581.4 = 0.125042999656
>> 24.2/193.8 = 0.124871001032
>> 19.4/155.0 = 0.125161290323
>> 18.2/145.3 = 0.125258086717
>> But the bandwidth is really low, so pushing target closer to the bandwidth
>> conserving side of the codel rationale might be fine,
> 
> Pretty sure it's a minimum derived from the MTU
> 
> ((mtu=1.5kbyte) * 8 bits/byte) / 1000 Mbit/s = 0.012s
> 
> except I don't know where the .5 comes from, that's incredibly
> suspicious to have a round 1/8th :).

	As we agree later/earlier 1/8th it is ;)

> 
> The point is that if buffering falls below the MTU, the connection
> will be completely clobbered.
> 
> In a way it's nice cake reports this in the target.  Otherwise cake
> would claim the target is 5ms, but measurements would show the
> effective target is more than twice as high.
> 
>> since latency is bad
>> to begin with and bandwidth also pretty scarce. But it might be interesting
>> to do a few more measurements at low bandwidths to confirm that the 12.5% of
>> interval logic holds water; one could also argue that people with such links
>> (a lot of DSL lines have even less upload, so this certainly is not extreme)
>> might think that any added ms of delay matters (more than bandwidth);
>> currently we leave the user no remedy...
>> 
>> 
> 
> <snip>
> 
>> This looks okay, except Tin3 has target at 7.3/101.0 = 0.0722772277228 7% of
>> interval.
> 
> Looks like the same thing.

	Well, I believe there is a gradual shift from the default 5ms/6.2ms target to the 1/8th target and this is just somewhere in between, by virtue of the smallest bandwidth or so...

> 
> 
>> Both observations might actually be on purpose, but if so we should document
>> that behavior as expected, for example in the man page…
>> 
>> Best Regards
>> 	Sebastian
> 
> 
> I'm afraid I can't help mention my old niggle :).  _If_ you mention
> this alongside instructions for RRUL, I think you'd also want to
> explain^W mention the measurement increase for diffserv4 v.s.
> besteffort.
> 
> I think the ICMP ping measurement increases by another 10ms on my
> connection (11500k down /  850k up, so an mtu is ~15ms).  I concluded
> it was inherent in prioritization.  Now I guess it's equal to the sum
> of target * bandwidth_fraction for each class "above" icmp ping (and
> could be tested).

	Well, with standard sqm-scripts (htb and fq_codel) we leverage iptables to do the filtering, which comes with its own computation cost…  then again with your bandwidths there should be enough cycles left to do this...

> 
> I have graphs from sqm with and without classification.  I did test
> cake once and I think it's the same (otherwise would be a bug).
> 
> https://dl.dropboxusercontent.com/u/49925445/bufferbloat.net/220-cdf-531414.sqm_simplest_11500_850_atm40_udppingfix.svg
> 
> https://dl.dropboxusercontent.com/u/49925445/bufferbloat.net/221-cdf-360505.sqm_simple_11500_850_atm40_udppingfix.svg

	Yes, that is the picture I know, I believe cake looks a bit different, by virtue of doing a few things in a more integrated, clever way; not sure how it looks at low bandwidth though, I rarely test at low bandwidth nowadays. Even though I should…

Best Regards
	Sebastian

> 
> Warm regards
> Alan