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 <[email protected]> wrote: > On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown <[email protected]> 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 >> [email protected] >> 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 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
