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

[jb]

The problem with metronome pinging is when there is a stall, they all pile
up then when they are released, you get this illusion of a 45 degree slope
of diminishing pings They all came back at the same instant (the 30 second
mark), but were all sent at the ticks along the X-Axis. So from 15 to 30
seconds was basically a total stall.

I'm not sure what to do with that information, just there it is.
Oh and the latency was so high, everything else is invisible, and even the
red barrier, which I arbitrarily set to end at 9999 ms, is exceeded.

Regarding the other suggestions on the list, I'll certainly try to
incorporate all of them. I'm the sole programmer on this and spend half of
each day doing other stuff too. So I only get an hour or two to add
features or improve existing ones. If something is suggested but not
implemented, or noted but not fixed it is just my time management failing.

I've a continuing problem with browsers under Linux getting bogged down
when asked to do these little charts so if there is no gauge visible during
the test, that is the reason, but hopefully the measurements are still
being taken, and will be in the results.

I agree that browsers are not ideal for testing, although most now seem ok
at delegating to the OS most of the job of receiving or sending, and do not
appear to be writing disk, But I think a desktop OS is always going to give
priority to interactive applications over "background" network activity.

However it does seem that connection speeds are improving at a similar, but
not faster, rate to new hardware, so perhaps it will never be an issue.
There is always the option of linking two or more devices with browsers
behind the same IP, and synchronising a test so all start at the same
instant. I don't know about everyone else, but we have two iMacs, one
tablet, two iPhones, and a laptop in the house. Even if I get the National
Broadband Network fiber to the home this year, and a 1 gig port - and pigs
fly - it'll be no problem overwhelming the port with the gadgets on hand,
and the browsers they come with.

On Fri, Apr 24, 2015 at 2:04 PM, Dave Taht <dave.taht at gmail.com> wrote:

> 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
> _______________________________________________
> 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/20150424/b9d716e5/attachment-0001.html>