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.
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
