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

[Dave Taht <dave.taht@gmail.com>]

On Thu, Apr 23, 2015 at 10:00 PM, jb <justin@dslr.net> wrote:
> 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.

Ugh. To clarify what you wrote here, is "the problem with metronome
pinging *over TCP/IP* is when you get a stall..."

I keep thinking that leveraging a webrtc (udp) for this test would be good...

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

PITA, isn't it?

I have had a variety of (mostly extraordinary amounts of bufferbloat)
failures with this test thus far, and I have this fear that users (and
your back end db) will discard them as noise - when they really
aren't. Is there/will there be a way to look hard at the failures?

> 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@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@gmail.com> wrote:
>> > On Thu, Apr 23, 2015 at 8:20 PM, Jim Gettys <jg@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@gmail.com> wrote:
>> >>>
>> >>> On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown <richb.hanover@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> > On Apr 23, 2015, at 6:22 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> >>> >
>> >>> >> On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown
>> >>> >> <richb.hanover@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@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