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

[Dave Taht]

Summary result from my hotel, with 11 seconds of bloat.

http://www.dslreports.com/speedtest/353034

On Thu, Apr 23, 2015 at 8:39 PM, Dave Taht <dave.taht at gmail.com> wrote:
> 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



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

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