Andy Furniss wrote:
Jonathan Morton wrote:
On 29 Apr, 2017, at 18:11, Andy Furniss <[email protected]>
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.
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
