On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown <[email protected]> wrote:
>
> 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"
Works for me.
>
>> ... 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.
Stick it center stage and call it the "Bloat-o-Meter?"
>> 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...
To me, that would help. Far too many think that data just arrives by
magic and doesn't have an ack clock.
> 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...
Nearly full scale (graph in red), with a few additional lines just
past that with the snarky annotations. (think of a classic automobile
rpm tach)
>
>> 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.
Well the actual number above the beyond redlined gauge makes for a
good screenshot.
>> 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
>
--
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
