On Apr 23, 2015, at 6: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,
OK - I change my opinion. I'll be fussy and say it should be "Bufferbloat (lag)
in msec"
> ... 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.
>
> 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...
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...
> 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.
>
> 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
>> [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
Rich
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
