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

[David Lang]

On Thu, 23 Apr 2015, Rich Brown 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.)
>
> 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).
>
> 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?
>
> 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.

the graph started out logarithmic and it was changed because that made it less 
obvious to people when the latency was significantly higher (most people are not 
used to evaluating log scale graphs)

> 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.

the client is no longer sending data, but the data hasn't arrived, so the 
latency for the data that does arrive is going to get longer as time goes by (if 
you stopped sending data at time X then the data arriving at time X+2 sec is 
going to show higher latency than the data that arrived at time X+1 sec because 
it's taken an additional second to arrive)

David Lang