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

[Dave Taht]

On Thu, Apr 23, 2015 at 8:20 PM, Jim Gettys <jg at freedesktop.org> wrote:
> 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.

I have also sent mail and tweets to no effect.

I hereby donate 1k to the "bufferbloat testing vs gogo-in-flight legal
defense fund".  Anyone that gets busted by testing for bufferbloat on
an airplane using these new tools or the rrul test can tap me for
that. Anyone else willing to chip in?[1]

I note that tweeting in the air after such a test might be impossible
(on at least one bloat test done so far the connection never came
back) so you'd probably have to tweet something like

"I am about to test for bufferbloat on my flight. If I do not tweet
again for the next 4 hours, I blew up gogo-in-flight, and expect to be
met by secret service agents on landing with no sense of humor about
how network congestion control is supposed to work."

FIRST. (and shrink the above to 140 pithy characters)

[1] I guess this makes me liable for inciting someone to do a network
test, also, which I hope is not illegal (?). I personally don't want
to do the test as I have better things to do than rewrite walden and
am not fond of roomates named "bubba".

... but I admit to being tempted.

> 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) -

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67