<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>