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

[Kathleen Nichols <nichols@pollere.com>]

in-line

On 8/26/16 4:20 PM, David Lang wrote:
> 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.

Yes, that's the point.
> 
> 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.

No, a large queue is a bunch of packets waiting in a queue (which is
contained in
a buffer). A large buffer with zero or a small number of packets in it
is not going
to result in packets being in transit for a long time.
> 
> David Lang