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