Re: [Cake] Running Cake at long RTTs

[Sebastian Moeller <moeller0@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 5178 bytes --]

Hi Toke,

so I just pulled both Dave’s ach_cake and your iproute2 repositories (edited codel5.h to exclude kvfree which is not needed on my opensuse patched? 3.16 kernel) and build the new stuff. After rmmod’ing the old module before insmod’ing the new one things started to work:

moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake rtt 120ms
moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke -s qdisc
qdisc cake 8004: dev eth0 root refcnt 6 unlimited besteffort flows rtt 120.0ms raw 
 Sent 42990 bytes 261 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
capacity estimate: 0bit
             Tin 0  
  thresh        0bit
  target       7.7ms
interval     122.7ms
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


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:

moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 root cake bandwidth 1Mbit besteffort rtt 100ms
moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke -s qdisc
qdisc cake 8008: dev eth0 root refcnt 6 bandwidth 1Mbit besteffort flows rtt 100.0ms raw 
 Sent 27367 bytes 188 pkt (dropped 0, overlimits 26 requeues 0) 
 backlog 0b 0p requeues 0 
capacity estimate: 981464bit
             Tin 0  
  thresh       1Mbit
  target      18.2ms
interval     145.3ms
Pk-delay       1.1ms
Av-delay        48us
Sp-delay         0us
  pkts           130
  bytes        18905
way-inds           0
way-miss          22
way-cols           0
  drops            0
  marks            0
Sp-flows           0
Bk-flows           1
last-len         159
max-len          584

	145.3 versus 100 that is way off (I know 145.2 = 8 * target, or target is 12.5% of interval), Not sure where the 18.2ms target comes from, the worst case single packet wire size is 33 ATM cells of 53 bytes which at the set rate of 1Mbps results in ((33*53*8)/1000^3) * 1000 = 0.013992 seconds = 14.0 ms seconds and 14*8 = 112 ms. So color me confused in what cake does under the hood. I would have preferred to find at least a “I'm sorry, Dave, I'm afraid I can't do that.” in the syslog regarding my request for an rtt of 100ms...



	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).
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).

Best Regards
	Sebastian



On Oct 27, 2015, at 16:14 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> So Dave and I did a bit of testing of Cake at a 1-second base RTT. That
> showed that, compared with a straight FIFO queue (with a sufficiently
> large buffer), throughput was suffering quite a bit under Cake,
> especially at large bandwidths. We did two changes to fix this:
> 
> - Turn the hard packet queue size into a lower bound rather than an
>  upper bound.
> 
> - Scale the target to be 1/16th of the interval.
> 
> The first change allows Cake to actually reach the target throughput,
> but it still takes a long while to get there. With the second change, we
> actually get the desired behaviour. The attached plot shows the
> difference, with the solid line being before the change and the dashed
> line being after the change.
> 
> Patch attached.
> 
> -Toke
> 
> diff --git a/sch_cake.c b/sch_cake.c
> index c97a212..91e556c 100644
> --- a/sch_cake.c
> +++ b/sch_cake.c
> @@ -854,10 +854,11 @@ static void cake_set_rate(struct cake_tin_data *b, u64 rate, u32 mtu,
> 
> 	byte_target_ns = (byte_target * rate_ns) >> rate_shft;
> 
> -	b->cparams.target = max(byte_target_ns, ns_target);
> 	b->cparams.interval = max(rtt_est_ns +
> 				     b->cparams.target - ns_target,
> 				     b->cparams.target * 8);
> +	b->cparams.target = max(max(byte_target_ns, ns_target),
> +				b->cparams.interval >> 4);
> 	b->cparams.threshold = (b->cparams.target >> 15) *
> 		(b->cparams.interval >> 15) * 2;
> 
> @@ -1144,7 +1145,7 @@ static void cake_reconfigure(struct Qdisc *sch)
> 		q->peel_threshold = 0;
> 	}
> 
> -	q->buffer_limit = min(q->buffer_limit, sch->limit *
> +	q->buffer_limit = max(q->buffer_limit, sch->limit *
> 			      psched_mtu(qdisc_dev(sch)));
> }
> 

[-- Attachment #2: cake-longrtt.pdf --]
[-- Type: application/pdf, Size: 149611 bytes --]

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake