Can't give full explanation now but the bytes per ns calculation which is used as a basis for target on 'slow' links uses mtu*1.5 -- Cheers, Kevin@Darbyshire-Bryant.me.uk > On 1 Nov 2015, at 20:58, Alan Jenkins wrote: > >> On 01/11/2015, Sebastian Moeller wrote: >> Dear cake committee, >> >> I just played around with the most recent sch_cake and noticed us: >> >> user@computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc del dev eth0 root >> user@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 :). > > 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... >> >> > > > >> This looks okay, except Tin3 has target at 7.3/101.0 = 0.0722772277228 7% of >> interval. > > Looks like the same thing. > > >> 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). > > 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 > > Warm regards > Alan > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake