From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 EA4C03B260 for ; Fri, 26 Aug 2016 21:06:49 -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 u7R16lqZ000334; Fri, 26 Aug 2016 18:06:47 -0700 Date: Fri, 26 Aug 2016 18:06:47 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Kathleen Nichols cc: bloat@lists.bufferbloat.net In-Reply-To: Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 01:06:50 -0000 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