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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
