From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4851F3B260 for ; Fri, 26 Aug 2016 19:37:45 -0400 (EDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 810E42005D82B; Fri, 26 Aug 2016 16:37:44 -0700 (PDT) Received: from kmnimac.local (unknown [50.136.231.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 62F2E2005D829; Fri, 26 Aug 2016 16:37:44 -0700 (PDT) To: David Lang 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> Cc: bloat@lists.bufferbloat.net From: Kathleen Nichols Message-ID: Date: Fri, 26 Aug 2016 16:37:43 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Fri, 26 Aug 2016 23:37:45 -0000 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