On 27/08/16 17:17, techicist@gmail.com wrote:
> Here you go:
> http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html

ok.

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

http://www.thinkbroadband.com/faq/sections/bqm.html#313

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.