[Cake] Running Cake at long RTTs
Sebastian Moeller
moeller0 at gmx.de
Wed Oct 28 11:50:56 EDT 2015
Hi Toke,
On Oct 28, 2015, at 16:36 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Sebastian Moeller <moeller0 at gmx.de> writes:
>
>> Except I requested rtf 120 ms and got 122.7, which admittedly is
>> close. I know I repeat myself, but on of the is one things that
>> irritate me in software is if software silently pretends to know
>> better… Now 122.7 versus 120 might be in the noise, but look at that:
>
> I don't remember from where, but I suspect there's something wrong with
> the 'change' logic in Cake. Can you try removing the qdisc completely,
> then re-adding it, rather than doing a straight replace?
Good point:
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root pfifo_fast
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit besteffort rtt 100ms ; sudo tc-toke -s qdisc
qdisc cake 800c: dev eth0 root refcnt 6 bandwidth 1Mbit besteffort 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
thresh 1Mbit
target 18.2ms
interval 95.0ms
Pk-delay 0us
Av-delay 0us
Sp-delay 0us
pkts 0
bytes 0
way-inds 0
way-miss 0
way-cols 0
drops 0
marks 0
Sp-flows 0
Bk-flows 0
last-len 0
max-len 0
moeller at happy-horse:~/CODE/sch_cake>
Just 95 is not equal to 100 either…
>
> Might not be that, but do try it out just to be sure. I have not looked
> at the scaling of target/interval that goes on in the different bands;
> but there is one? Or is there? If there is, why? It's not immediately
> obvious that different diffserv markings needs different settings for
> the AQM…
Well:
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit diffserv4 rtt 100ms ; sudo tc-toke -s qdisc
qdisc cake 800e: 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 95.0ms 95.0ms 95.0ms 95.0ms
Pk-delay 0us 0us 0us 0us
Av-delay 0us 0us 0us 0us
Sp-delay 0us 0us 0us 0us
pkts 0 0 0 0
bytes 0 0 0 0
way-inds 0 0 0 0
way-miss 0 0 0 0
way-cols 0 0 0 0
drops 0 0 0 0
marks 0 0 0 0
Sp-flows 0 0 0 0
Bk-flows 0 0 0 0
last-len 0 0 0 0
max-len 0 0 0 0
moeller at happy-horse:~/CODE/sch_cake>
The different tins have different bandwidths and so might need to scale target differentially as the packet transfer time is different for the different tins (I note in my contrived example I have set the bandwidth to a measly 1Mbps). Interestingly rtt is auto-adjusted to 95.0 ms even if I do not request rtt 100:
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc del dev eth0 root
RTNETLINK answers: No such file or directory
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit diffserv4 rtt 100ms ; sudo tc-toke -s qdisc
qdisc cake 8016: 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 95.0ms 95.0ms 95.0ms 95.0ms
Pk-delay 0us 0us 0us 0us
Av-delay 0us 0us 0us 0us
Sp-delay 0us 0us 0us 0us
pkts 0 0 0 0
bytes 0 0 0 0
way-inds 0 0 0 0
way-miss 0 0 0 0
way-cols 0 0 0 0
drops 0 0 0 0
marks 0 0 0 0
Sp-flows 0 0 0 0
Bk-flows 0 0 0 0
last-len 0 0 0 0
max-len 0 0 0 0
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc del dev eth0 root
moeller at happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit diffserv4 ; sudo tc-toke -s qdisc
qdisc cake 8017: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows rtt 100.0ms raw
Sent 146 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
capacity estimate: 996096bit
Tin 0 Tin 1 Tin 2 Tin 3
thresh 1Mbit 937504bit 750Kbit 250Kbit
target 18.2ms 19.4ms 24.2ms 72.7ms
interval 95.0ms 95.0ms 95.0ms 95.0ms
Pk-delay 0us 0us 0us 0us
Av-delay 0us 0us 0us 0us
Sp-delay 0us 0us 0us 0us
pkts 0 1 0 0
bytes 0 146 0 0
way-inds 0 0 0 0
way-miss 0 1 0 0
way-cols 0 0 0 0
drops 0 0 0 0
marks 0 0 0 0
Sp-flows 0 1 0 0
Bk-flows 0 0 0 0
last-len 0 146 0 0
max-len 0 146 0 0
moeller at happy-horse:~/CODE/sch_cake>
At least in full automatic mode I would have assumed cake would also increase the interval according to the available bandwidth in the different Tins...
>
>> Also I notice the disparity between parameter name “rtt” and the name
>> of the reported statistic “interval”. Jonathan, Dave, what is your
>> preference change the reported stats name or the parameter name (I
>> believe it should be that statistic that needs renaming).
>
> Yes, if we're calling it RTT it should be RTT throughout. I do think
> that makes more sense than interval.
Ah, thanks. (Personaly I would prefer codel_interval ;) )
>
>> Next question what is the opinion on exposing target in addition to
>> interval? My point, which I might have over-repeated already, is we
>> should expose and honor it if possible. (Any with honor I mean replace
>> the 5ms default but do all calculations as cake usually does for
>> different priority bands; that also means that if only one of interval
>> or target where specified cake is free to scale the other one to what
>> it considers reasonable).
>
> I seem to recall that at some point we has "easy to configure" as a goal
> of Cake.
Well, in the easy configuration it lis full automatic and does the right thing; it does not get any easier to configure than:
tc qdisc replace dev eth0 root cake
All the additional parameters are there to tweak and experiment. So I argue exposing knobs is not making it difficult to configure as long as nobody needs to touch these (I also volunteer to make the tc help more specific in that regard…)
Best Regards
Sebastian
>
> -Toke
More information about the Cake
mailing list