<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 27/08/16 17:17, <a class="moz-txt-link-abbreviated" href="mailto:techicist@gmail.com">techicist@gmail.com</a> wrote:<br>
<blockquote
cite="mid:CANiaOCk=mA4yYiBT+E20bTUuGLo7duWtNE3m5XH0YZASkyECJg@mail.gmail.com"
type="cite">
<pre wrap="">Here you go:
<a class="moz-txt-link-freetext" href="http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html">http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html</a>
</pre>
</blockquote>
<br>
ok.<br>
<br>
- Average latency is perfectly fine (for the points you mentioned)<br>
<br>
- 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).<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.thinkbroadband.com/faq/sections/bqm.html#313">http://www.thinkbroadband.com/faq/sections/bqm.html#313</a><br>
<br>
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.<br>
<br>
- 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 :).<br>
<br>
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.<br>
<br>
-> They could be transient bufferbloat.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
-> I don't think you've posted "bufferbloat" measurements for
your ISP download queue, i.e. _without_ using rate-limiting on your
router.<br>
<br>
That's my first cut.<br>
<br>
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.<br>
</body>
</html>