Re: [Cake] Fighting bloat in the face of uncertinty

["Justin Kilpatrick" <justin@althea.net>]

> 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:

You are correct. My sampling was flawed and the 'metro' profile is not actually making any difference. 

the main contributor to bloat reduction was a  bandwidth parameter left over from too much use of `tc qdisc change` rather than add/del. 

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

Hand tuning this one link is not a problem. I'm searching for a set of settings that will provide generally good performance across a wide range of devices, links, and situations. 

From what you've indicated so far there's nothing as effective as a correct bandwidth estimation if we consider the antenna (link) a black box. Expecting the user to input expected throughput for every link and then managing that information is essentially a non-starter. 

Radio tuning provides some improvement, but until ubiquiti starts shipping with Codel on non-router devices I don't think there's a good solution here. 

Any way to have the receiving device detect bloat and insert an ECN? I don't think the time spent in the intermediate device is detectable at the kernel level but we keep track of latency for routing decisions and could detect bloat with some accuracy, the problem is how to respond. 

-- 
  Justin Kilpatrick
  justin@althea.net

On Sat, Sep 7, 2019, at 8:59 PM, Jonathan Morton wrote:
> > On 8 Sep, 2019, at 3:03 am, Justin Kilpatrick <justin@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