[Bloat] DSLReports Speed Test has latency measurement built-in

Thu Apr 23 19:40:23 PDT 2015

On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown <richb.hanover at gmail.com> wrote:
>
> On Apr 23, 2015, at 6:22 PM, Dave Taht <dave.taht at gmail.com> wrote:
>
>> On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown <richb.hanover at gmail.com> wrote:
>>> Hi Justin,
>>>
>>> The newest Speed Test is great! It is more convincing than I even thought it would be. These comments are focused on the "theater" of the measurements, so that they are unambiguous, and that people can figure out what's happening
>>>
>>> I posted a video to Youtube at: http://youtu.be/EMkhKrXbjxQ to illustrate my points. NB: I turned fq_codel off for this demo, so that the results would be more extreme.
>>>
>>> 1) It would be great to label the gauge as "Latency (msec)" I love the term "bufferbloat" as much as the next guy, but the Speed Test page should call the measurement what it really is. (The help page can explain that the latency is almost certainly caused by bufferbloat, but that should be the place it's mentioned.)
>>
>> I would prefer that it say "bufferbloat (lag in msec)" there,
>
> OK - I change my opinion. I'll be fussy and say it should be "Bufferbloat (lag) in msec"

Works for me.

>
>> ... rather
>> than make people look up another word buried in the doc. Sending
>> people to the right thing, at the getgo, is important - looking for
>> "lag" on the internet takes you to a lot of wrong places,
>> misinformation, and snake oil. So perhaps in doc page I would have an
>> explanation of lag as it relates to bufferbloat and other possible
>> causes of these behaviors.
>>
>> I also do not see the gauge in my linux firefox, that you are showing
>> on youtube. Am I using a wrong link. I LOVE this gauge, however.
>
> I see this as well (Firefox in Linux). It seems OK in other browser combinations. (I have *not* done the full set of variations...)
>
> If this is a matter that FF won't show that gizmo, perhaps there could be a rectangle (like the blue/red ones) for Latency that shows:
>
>    Latency
>    Down: min/avg/max
>    Up: min/avg/max
>
>> Lastly, the static radar plot of pings occupies center stage yet does
>> not do anything later in the test. Either animating it to show the
>> bloat, or moving it off of center stage and the new bloat gauge to
>> center stage after it sounds the net, would be good.
>
> I have also wondered about whether we should find a way to add further value to the radar display. I have not yet come up with useful suggestions, though.

Stick it center stage and call it the "Bloat-o-Meter?"

>> bufferbloat as a single word is quite googlable to good resources, and
>> there is some activity on fixing up wikipedia going on that I like a
>> lot.
>>
>>>
>>> 2) I can't explain why the latency gauge starts at 1-3 msec. I am guessing that it's showing incremental latency above the nominal value measured during the initial setup. I recommend that the gauge always show actual latency. Thus the gauge could start at 45 msec (0:11 in the video) then change during the measurements.
>>>
>>> 3) I was a bit confused by the behavior of the gauge before/after the test. I'd like it to change only when when something else is moving in the window. Here are some suggestions for what would make it clearer:
>>>        - The gauge should not change until the graph starts moving. I found it confusing to see the latency jump up at 0:13 just before the blue download chart started, or at 0:28 before the upload chart started at 0:31.
>>>        - Between the download and upload tests, the gauge should drop back to the nominal measured values. I think it does.
>>>        - After the test, the gauge should also drop back to the nominal measured value. It seems stuck at 4928 msec (0:55).
>>
>> We had/have a lot of this problem in netperf-wrapper - a lot of data
>> tends to accumulate at the end of the test(s) and pollute the last few
>> data points in bloated scenarios. You have to wait for the queues to
>> drain to get a "clean" test - although this begins to show what
>> actually happen when the link is buried in both directions.
>>
>> Is there any chance to add a simultaneous up+down+ping test at the conclusion?
>
> This confuses the "speed test" notion of this site. Since the flow of ack's can eat up 25% of the bandwidth of a slow, asymmetric link, I am concerend that people would wonder why their upload bandwidth suddenly went down dramatically...

To me, that would help. Far too many think that data just arrives by
magic and doesn't have an ack clock.

> Given that other speed test sites only show upload/download, I would vote to keep that format here. Perhaps there could be an option/preference/setting to do up/down/ping .
>
>>> 4) I like the way the latency gauge changes color during the test. It's OK for it to use the color to indicate an "opinion". Are you happy with the thresholds for yellow & red colors?
>>
>> It is not clear to me what they are.
>>
>>> 5) The gauge makes it appear that moderate latency - 765 msec (0:29) - is the same as when the value goes to 1768 msec (0:31), and also when it goes to 4,447 msec (0:35), etc. It might make more sense to have the chart's full-scale at something like 10 seconds during the test. The scale could be logarithmic, so that "normal" values occupy up to a third or half of scale, and bad values get pretty close to the top end. Horrible latency - greater than 10 sec, say - should peg the indicator at full scale.
>>
>> I am generally resistant to log scales as misleading an untrained eye.
>> In this case I can certainly see the gauge behaving almost as
>> described above, except that I would nearly flatline the gauge at >
>> 250ms, and add indicators for higher rates at the outer edges of the
>> graph.
>
> I am suggesting a slightly different representation. Instead of flatlining (I assume that you mean full-scale indicator of the gauge) at 250msec (which I agree is bad), perhaps the gauge could use the levels I sent in a previous message...

Nearly full scale (graph in red), with a few additional lines just
past that with the snarky annotations. (think of a classic automobile
rpm tach)

>
>> I agree that the results graph should never be logarithmic - it hides the bad
>> news of high latency.
>>
>> However, the gauge that shows instantaneous latency could be logarithmic. I was
>> reacting to the appearance of slamming against the limit at 765 msec, then not making it
>> more evident when latency jumped to 1768 msec, then to 4447 msec.

Well the actual number above the beyond redlined gauge makes for a
good screenshot.

>> Imagine the same gauge, with the following gradations at these clock positions,
>> with the bar colored to match:
>>
>> 0 msec - 9:00 (straight to the left)
>> 25 msec - 10:00
>> 100 msec - 11:00
>> 250 msec - 12:00
>> 1,000 msec - 1:00
>> 3,000 msec - 2:00
>> 10,000+ msec - 3:00 (straight to the left)
>
>> I can see staying below 30ms induced latency as "green", below 100ms
>> as "blue", below 250ms as yellow, and > 250ms as red, and a line
>> marking "rediculous" at > 1sec, and "insane" at 2sec would be good.
>> Other pithy markings at the end of the tach would be fun. For example,
>> gogo in flight has the interplanetary record for bufferbloat,
>> something like 760 seconds the last time we tried it, so a 3rd line on
>> the tach for earth-mars distances would be amusing.
>
> These color schemes sound good. It could indeed be amusing to have editorial comments ("ludicrous bloat") for the worst situations.
>
>> In the long term, somehow detecting if FQ is in play would be good,
>> but I have no idea how to do that in a browser.
>>
>>> 6) On the Results page (1:20), I like the red background behind the latency values. I don't understand why the grey bars at the right end of the chart are so high. Is the latency still decreasing as the queue drains? Perhaps the ping tests should run longer until it gets closer to the nominal value.
>>
>> I would suspect the queues are still draining, filled with missing
>> acknowledgements, etc, etc. waiting until the ping returned closer to
>> normal before starting the next phase of the test would help.
>
> This sounds right to me.
>
>>> This is such a great tool. Thanks!
>>
>> I am very, very, very delighted also. I hope that with tools like
>> these in more users hands, AND the data collected from them, that we
>> can make a logarithmic jump in the number of users, devices, and ISPs
>> that have good bandwidth and low latency in the near future.
>>
>> Thank you very, very much for the work.
>>
>> As a side note, justin, have you fixed your own bloat at home?
>>
>>>
>>> Rich
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
>>
>> --
>> Dave Täht
>> Open Networking needs **Open Source Hardware**
>>
>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
> Rich
>

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67