From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0C64D3B25E for ; Sat, 27 Aug 2016 12:03:26 -0400 (EDT) Received: by mail-wm0-x230.google.com with SMTP id i5so32039444wmg.0 for ; Sat, 27 Aug 2016 09:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=oNhNe04RMIiMudz8rLkRmPqtEIk6jbGeM7wS8h3rZ1A=; b=flrqAySO6GQLsS49/cGsIsL9JR57U+CKWlB+hniwRUgBmaSWa34bC76OveD5j68qZQ 63e9ljB5rmH0a4la9EPr4SEibnbCkqda1Yi9FizmRC0vgLWSUIFDyc/gDTzKOmU4N9lp OhBdKpSg1+b8kWX4JgE7kewIJdUa63e4Zsaa0ikcuxeQhusH67mvnqNvB+09WgNgVKiV lFLSJwTT4NEU8Ujii3SMtO5dqhV1Jixa5Alx9O/Zcqq2yK+VAlYQOvMgfbcRuQA9hJwd iULoFwSL6Vwz2Eu29vaVCTPBOWLFscGTpOHkCcJKGBFphd8MaxrAhWC00EBXXQ3/TraV BLnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=oNhNe04RMIiMudz8rLkRmPqtEIk6jbGeM7wS8h3rZ1A=; b=I47HobYLj6eyl/jRDGIDq1fhx8b6MvoO2pFwx5tPmUBjHHfpSMBetECn03AIqa/Yw2 /LCBpxHdj3d8SCzr+hdxgoZ/X5+yxJ+EEmKZDG03ebGc3qntmqyEFbJwipLz1GHIVmvM krpfWl6BVam5Q8X5AkXVaeFpWwKdT23xKipFlfZinqESkJAKhtXGTLeJmIp18lw/MpsQ z4jfLy1MmOU2GFQ6gnIFwCQIJNaVLQmt3BwiHwzKZf9P41tuEZDuBDF/psdUhm546VtO odbElDVabNjg9xFnOPXVXsqb9cXFQwx4BtnxNhKcJ9rwECXchNzxrUVdZaaTf7OynrDj DyDA== X-Gm-Message-State: AE9vXwN4O4Yt2vLhWYH+2LgYJTzS3i6UfVEqIURSrDaVpH6V8qAFQOyoHHYaL7sdJLOTOQ== X-Received: by 10.194.53.234 with SMTP id e10mr3523607wjp.85.1472313805586; Sat, 27 Aug 2016 09:03:25 -0700 (PDT) Received: from localhost.localdomain (host-89-243-172-136.as13285.net. [89.243.172.136]) by smtp.googlemail.com with ESMTPSA id n131sm4400225wmd.3.2016.08.27.09.03.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Aug 2016 09:03:24 -0700 (PDT) To: Kathleen Nichols , bloat@lists.bufferbloat.net References: <05056A85-894D-477F-A10D-C912C7D52C2F@gmail.com> <448a25be-160f-701e-f56b-b3a33d49cff8@pollere.com> From: Alan Jenkins Message-ID: <63403b38-94fa-1670-908c-e14573f822a8@gmail.com> Date: Sat, 27 Aug 2016 17:03:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <448a25be-160f-701e-f56b-b3a33d49cff8@pollere.com> Content-Type: multipart/alternative; boundary="------------2EEF2C0DEA614F28478D17AD" Subject: Re: [Bloat] Bufferbloat test measurements 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 16:03:27 -0000 This is a multi-part message in MIME format. --------------2EEF2C0DEA614F28478D17AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit That's the simplest measure of bufferbloat though :). Do you have a criticism in terms of dslreports.com? I think it's fairly transparent, showing idle v.s. download v.s. upload. The headline figures are an average, and you can look at all the data points. (You can increase the measurement frequency if you're specifically interested in that). [random selection from Google] http://www.dslreports.com/speedtest/419540 http://forum.kitz.co.uk/index.php?topic=15620.0 It's more aggressive than a single file download, but that's not deliberately to exacerbate bufferbloat. It's just designed to measure performance of prolonged downloads / streaming, in a competitively short test. "For our busy lives", as the overused saying goes. (The initial summary only gives a grade. The figure wouldn't be one of the headlines their ISP advertises. Saying "100ms" would confuse people. And the tests they're used to / compare with, show idle latency instead.) On 27/08/16 16:19, Kathleen Nichols wrote: > Yeah. > > I admit to muddying the waters because I think of the size of a buffer as > being in megabytes and the size of a queue (latency) as being in > milliseconds. I think the tests attempt to measure the worst possible > latency/queue that can occur on a path. > > On 8/27/16 4:46 AM, Rich Brown wrote: >> It has always been my intent to define bufferbloat as *latency*. The >> first sentence on www.bufferbloat.net says, "Bufferbloat is the >> undesirable latency that comes from a router or other network >> equipment buffering too much data." >> >> That definition focuses on observable/measurable values. It sidesteps >> objections I've seen on the forums, "How could $TEST measure the size >> of buffers?" >> >> So what matters is whether the buffers (of any size) are filling up. >> _______________________________________________ Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --------------2EEF2C0DEA614F28478D17AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
That's the simplest measure of bufferbloat though :).

Do you have a criticism in terms of dslreports.com?  I think it's fairly transparent, showing idle v.s. download v.s. upload.  The headline figures are an average, and you can look at all the data points.  (You can increase the measurement frequency if you're specifically interested in that).

[random selection from Google]
http://www.dslreports.com/speedtest/419540
http://forum.kitz.co.uk/index.php?topic=15620.0

It's more aggressive than a single file download, but that's not deliberately to exacerbate bufferbloat.  It's just designed to measure performance of prolonged downloads / streaming, in a competitively short test.  "For our busy lives", as the overused saying goes.

(The initial summary only gives a grade.  The figure wouldn't be one of the headlines their ISP advertises.  Saying "100ms" would confuse people.  And the tests they're used to / compare with, show idle latency instead.)

On 27/08/16 16:19, Kathleen Nichols wrote:
Yeah.

I admit to muddying the waters because I think of the size of a buffer as
being in megabytes and the size of a queue (latency) as being in
milliseconds. I think the tests attempt to measure the worst possible
latency/queue that can occur on a path.

On 8/27/16 4:46 AM, Rich Brown wrote:

It has always been my intent to define bufferbloat as *latency*. The
first sentence on www.bufferbloat.net says, "Bufferbloat is the
undesirable latency that comes from a router or other network
equipment buffering too much data."

That definition focuses on observable/measurable values. It sidesteps
objections I've seen on the forums, "How could $TEST measure the size
of buffers?"

So what matters is whether the buffers (of any size) are filling up. 
_______________________________________________ Bloat mailing list 
Bloat@lists.bufferbloat.net 
https://lists.bufferbloat.net/listinfo/bloat


_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--------------2EEF2C0DEA614F28478D17AD--