In-line below. Only for geeks.

On 8/27/16 9:03 AM, Alan Jenkins wrote:
> 
> That's the simplest measure of bufferbloat though :).

Don't I know! :)  Have spent a couple of years figuring out how to measure
experienced delay...
> 
> 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).

"Criticism" seems too harsh. The uplink and downlink speed stuff is great
and agrees with all other measures. The "bufferbloat" grade is, I think,
sort
of confusing. Also, it's not clear where the queue the test builds up is
located.
It could be in ISP or home. So, I ran the test while I was also streaming a
Netflix video. Under the column "RTT/jitter Avg" the test lists values that
range from 654 to 702 with +/- 5.2 to 20.8 ms (for the four servers). I
couldn't
figure out what that means. I can see the delay ramp up over the test
(the video
stream also follows that ramp though it's normal delay ranges from about
1ms to
about 40ms). If I took the RT delay experienced by the packets to/from
those servers,
I got median values between 391 and 429 ms. The IQRs were about 240ms to
536-616ms. The maximum values where all just over 700ms, agreeing with
the dslreports
number. But that number is listed as an average so I don't understand?
Also what is the
jitter. I looked around for info on the numbers but I didn't find it.
Probably I just totally
missed some obvious thing to click on.

But the thing is, I've been doing a lot of monitoring of my link and I
don't normally see
those kinds of delays. In the note I put out a bit ago, there is
definitely this bursting
behavior that is particularly indulged in by netflix and google but when
our downstream
bandwidth went up, those bursts no longer caused such long transient
delays (okay, duh).
So, I'm not sure who should be tagged as the "responsible party" for the
grade that the
test gives. Nor am I convinced that users have to assume that means they
are going to see
those kinds of delays. But this is a general issue with active measurement.

It's not a criticism of the test, but maybe of the presentation of the
result.

        Kathie
> 
> [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
> 

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

Reply via email to