> On 8 Sep, 2019, at 3:03 am, Justin Kilpatrick <jus...@althea.net> wrote:
>
> So you believe that setting the target RTT closer to the path latency was not
> the main contributor to reducing bloat? Is there a configuration I could use
> to demonstrate that one way or the other?
The second-order effect I mentioned is related to the 'target' parameter.
Checking the code, I am reminded that while Cake itself can have 'target' set
from userspace, there actually isn't a parameter to the tc module which allows
setting it independently of 'rtt'. But there *is* a table in q_cake.c (in tc)
which you can temporarily extend with the following entries for experimentation:
static struct cake_preset presets[] = {
{"datacentre", 5, 100},
{"lan", 50, 1000},
{"metro", 500, 10000},
{"regional", 1500, 30000},
{"internet", 5000, 100000},
{"oceanic", 15000, 300000},
{"satellite", 50000, 1000000},
{"interplanetary", 50000000, 1000000000},
+
+ {"metro-loose", 5000, 10000},
+ {"internet-tight", 500, 100000},
};
If the effect is genuinely due to marking rate, then 'metro-loose' should
behave like 'metro' and 'internet-tight' should behave like 'internet', to a
first-order approximation. If, on the other hand, it's due to the second-order
interaction with CPU scheduling latency, the reverse may be true. The latter
is not something you should be counting on, as it will insert random AQM
marking even when the link is not actually saturated.
You could also set it back to 'internet' and progressively reduce the bandwidth
parameter, making the Cake shaper into the actual bottleneck. This is the
correct fix for the problem, and you should notice an instant improvement as
soon as the bandwidth parameter is correct.
- Jonathan Morton
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
