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

Thu Apr 23 20:20:27 PDT 2015

I love the test, and thanks for the video!

There is an interesting problem: some paths have for all intents and
purposes infinite buffering, so you can end up with not just seconds, but
even minutes of bloat.  The current interplanetary record for bufferbloat
is GoGo inflight is 760(!) seconds of buffering (using netperf-wrapper,
RRUL test, on several flights); Mars is closer to Earth than that for part
of its orbit.  I've seen 60 seconds or so on some XFinity WiFi and similar
amounts of bloat on some cellular systems.  Exactly how quickly one might
fill such buffers depends on the details of load parts of a test.

Please don't try the netperf-wrapper test on GoGo; all the users on the
plane will suffer, and their Squid proxy dies entirely.  And the government
just asked people to report "hackers" on airplanes....  Would that GoGo
listen to the mail and tweets I sent them to try to report the problem to
them....  If anyone on the list happens to know someone from GoGo, I'd like
to hear about it.

But I agree that a log display hides just how bad things are; in some
cases, rescaleing the display probably needs to happen, possibly more than
once as the buffers fill during the tests.
                                                   - Jim

On Thu, Apr 23, 2015 at 7:40 PM, Dave Taht <dave.taht at gmail.com> wrote:

> On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown <richb.hanover at gmail.com>
> wrote:
> >
> > On Apr 23, 2015, at 6:22 PM, Dave Taht <dave.taht at gmail.com> wrote:
> >
> >> On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown <richb.hanover at gmail.com>
> 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
> >>> Bloat at lists.bufferbloat.net
> >>> 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
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150423/96ee3d4e/attachment-0001.html>