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

David Lang david at lang.hm
Fri Aug 26 21:06:47 EDT 2016


On Fri, 26 Aug 2016, Kathleen Nichols wrote:

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

Is a large buffer that is never used really a large buffer? or does whatever 
prevents it from being used really turn it into a small buffer?

The problem has never been a matter of the number of bytes the buffers hold, but 
rather the number of bytes relative to the data rate (also known as the time 
that data can wait in the buffer). A buffer that's the right size for a 1Gb/s 
connection is horribly bloated if the data rate is only 10Mb/s

We've found that the solution isn't just to shrink the size of the buffers (even 
if we first change from X packets to X bytes), and instead the proper solution 
is some form of active queue management that has the side effect of keeping 
the queues small.

I don't understand what you are trying to call out by trying to change the 
terminology.

David Lang


More information about the Bloat mailing list