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

Thu Apr 23 15:29:20 PDT 2015

Justifications for the gradations of color and thresholds I just
suggested you can find in the "real time applications" section of:

https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

This might be a good set of phrases to insert lines on the tach for.

I note that jitter is important to track too, and I figure this test
gets good data on that but am visually challenged enough to not know a
good way to represent that, either.

On Thu, Apr 23, 2015 at 3: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, 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.
>
> 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.
>
> 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?
>
>> 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 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.
>
> 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 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

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

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