Re: [Cake] Getting Cake to work better with Steam and similar applications

[Andy Furniss <adf.lists@gmail.com>]

Andy Furniss wrote:
> Jonathan Morton wrote:
>> 
>>> On 29 Apr, 2017, at 18:11, Andy Furniss <adf.lists@gmail.com> 
>>> wrote:
>>> 
>>> With the ingress param shaping at 1mbit 5 tcps (cubic or bbr) 
>>> really destroys latency.
>>> 
>>> With the caveat that my test may be flawed, I am currently 
>>> suspecting that cake cobalt head + ingress param and a low rate
>>> is buggy.
>> 
>> That’s odd, since I’m currently dogfooding it at 512Kbit, and it 
>> works fine like that.  Not to the point of wanting to play online 
>> games while torrenting and downloading Steam updates, but that
>> sort of limitation comes with the territory.
>> 
>> With a game updater that uses *80* web-seeds simultaneously (a 
>> libtorrent quirk which should get patched in the next version), I
>> can still reliably use my Web browser and e-mail on a second
>> machine; these are things that start to fail intermittently over
>> about 2 seconds RTT, and I’ve measured this ISP at 45 seconds
>> without modification.
>> 
>> The key thing to remember is that in ingress mode, you *must*
>> reduce the shaped rate to some (large) fraction of the bottleneck
>> link, otherwise it won’t control the queue at all.  For example,
>> I’m reasonably sure my current link is dumb-shaped to 576Kbit at
>> the ISP. The smaller the fraction, the better the control of
>> latency Cake can achieve.
>> 
>> This is in contrast to egress mode, where you want to match the
>> link capacity as closely as possible to get maximum performance;
>> latency control remains ideal as long as you never actually
>> *exceed* the true link capacity.
> 
> It was a rather artificial test with cake set at 1mbit behind hfsc
> at 18mbit - just trying to recreate one of Dendari's tests. With the 
> ingress parameter latency was hurt quite badly compared to without, 
> which was unexpected. There were a lot of drops - but it seemed like 
> they were hurting the ping flow. Putting ping into voice didn't
> help.

Also seen on a very simple test case with cake on eth. In this case brr
is worse than cubic, but both are "bad".

I am guessing that the ingress param just shouldn't be used when it's
not (as you said) a large fraction of the bottleneck.

I suspect that with low bandwidth + many drops + pretending the drops
were sent, that the whole queue goes over rate, rather than just the
individual flows.