[Cake] Configuring cake for VDSL2 bridged connection
alan.christopher.jenkins at gmail.com
Sat Aug 27 13:48:35 EDT 2016
On 27/08/16 17:17, techicist at gmail.com wrote:
> Here you go:
- Average latency is perfectly fine (for the points you mentioned)
- Reading the docs for this tool ("How do I interpret my BQM graph?"),
they suggest that spikes which show in yellow (the maximum, taken from
100 pings) but don't show in blue (average) "do not affect gaming".
"The connection is good". (Also, your yellow spikes are shorter than
some of the ones they show).
I think they mean that 1% "late" packets will effectively be treated as
lost packets for latency-sensitive apps, and such apps should be
designed to handle low-level loss. Our Dave might call this a bit of a
cop out though.
- They're only to do with your bufferbloat / AQM, if they happen while
the connection is used. If your connection is idle, you don't have any
queue you could manage to decrease the queuing latency :).
That said, the BQM docs suggest that if there was congestion at a larger
shared link within your ISP, you would generally see an increase in the
minimum latency (green). Because when the problem is caused by a large
number users, the load will be averaged out and be much more consistent.
-> They could be transient bufferbloat.
Cake isn't running at the ISP end. If your connection was maliciously
flooded >100% capacity, then a dumb ISP queue could fill, and delay the
lucky packets that got through. Despite the cake on your end.
Flooding the connection >100% is not that different to what a TCP
connection does while starting up, in order to find what the current
link capacity actually is. Browsing to a new web page typically
involves starting a surprisingly large number of TCP connections.
I run smokeping on a slower connection with fq_codel. I don't think my
spikes are as high - I'd say +5-10ms to your +30-40. However my ISP's
(download) queue management is relatively good (against web browsing).
-> I don't think you've posted "bufferbloat" measurements for your ISP
download queue, i.e. _without_ using rate-limiting on your router.
That's my first cut.
You could compare cake to traditional fq_codel (I think you might have
to disable TCP offloads, in case you're effectively relying on Cake's
peeling feature). I believe fq_codel is well characterized, whereas
cake is more experimental. I don't expect that's the issue though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cake