[Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring)

[David Lang]

On Fri, 26 Aug 2016, Kathleen Nichols wrote:

> I think it might be useful to say these tests measure the maximum
> *potential* for
> bufferbloat. That is, they plumb the depths of the buffers in the path.
> I tried running
> dslreports while I was running a video and though dslreports ramps
> delays up to 700ms,
> before and after that peak delay is more like 45ms. I don't think large
> buffers are going
> to go away, what matters is whether they are getting filled up.
>
> So, is "bufferbloat" the existence of large buffers or the existence of
> large queues? I think
> the latter.

large buffers that never fill up may as well be small buffers.

it's the fact that the large buffers fill that's the problem.

so you can call it large queues instead of large buffers, but the result is that 
packets end up being 'in transit' for a long time.

David Lang