From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <david@lang.hm>
Received: from bifrost.lang.hm (lang.hm [66.167.227.134])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id 47D453B260
 for <bloat@lists.bufferbloat.net>; Fri, 26 Aug 2016 19:20:34 -0400 (EDT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100])
 by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u7QNKVrB028894;
 Fri, 26 Aug 2016 16:20:31 -0700
Date: Fri, 26 Aug 2016 16:20:31 -0700 (PDT)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: Kathleen Nichols <nichols@pollere.com>
cc: bloat@lists.bufferbloat.net
In-Reply-To: <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com>
Message-ID: <alpine.DEB.2.02.1608261619030.18129@nftneq.ynat.uz>
References: <0B9BB2F0-611E-4388-8784-0AC71556AB4B@cable.comcast.com>
 <20160824090847.4e77ce8f@xeon-e3>
 <1C99BD90-7688-4168-814D-57DA12F0F08C@cable.comcast.com>
 <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed
 monitoring)
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2016 23:20:34 -0000

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