From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C5A5521F3B3 for ; Thu, 23 Apr 2015 22:00:28 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so85896423ied.1 for ; Thu, 23 Apr 2015 22:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=2B76POXD9b+7I5cLYgkEcf4Q7kL1Qf0MgEK7xp+EKZA=; b=0tT28dUiyJtMllKfV6nUNYPo50rGzmQbXbLgqqptsRWSaokzFFh9YvmftPJNx8eDmz +5bLdNlu93OKdAAw+y5YXPWzooZJ1pMSG25zeS1TxvQ8wCEGn0A9KbUd01QqcGhHVlJe BSKmDbND2jQpgaepvVoqNdjshFiqW+u15wSElRV/uNv0vYrUS1+Z/MY/MIF5AHc0lfB7 T0dnLHCGlaR3VkyPoB/XlBMUP/6CX6bMfPwS3RIgj+qXGWHQ7fqAJH8sKmFyrTAra7lQ Rud4NC8xO3UpajT/513apLwocMfhf0XjRhiOVzJsCtSqoZ/Zv4PpsNyQO49mEuQVtjod 4eaw== MIME-Version: 1.0 X-Received: by 10.42.213.136 with SMTP id gw8mr7667713icb.95.1429851627553; Thu, 23 Apr 2015 22:00:27 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Thu, 23 Apr 2015 22:00:27 -0700 (PDT) In-Reply-To: References: <87wq18jmak.fsf@toke.dk> <87oamkjfhf.fsf@toke.dk> <87k2x8jcnw.fsf@toke.dk> <0D391BB1-9CA5-4DAF-8FD6-6628AB09C1C5@gmail.com> Date: Fri, 24 Apr 2015 15:00:27 +1000 X-Google-Sender-Auth: zbIu149Cd9zlBkIc34Q2enOYlCk Message-ID: From: jb To: Dave Taht , bloat Content-Type: multipart/alternative; boundary=001a11c31700578a28051471460e Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 05:00:57 -0000 --001a11c31700578a28051471460e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 wrote: > > On Thu, Apr 23, 2015 at 8:20 PM, Jim Gettys 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 th= e > >> plane will suffer, and their Squid proxy dies entirely. And the > government > >> just asked people to report "hackers" on airplanes.... Would that GoG= o > >> 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 wrote= : > >>> > >>> On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown > >>> wrote: > >>> > > >>> > On Apr 23, 2015, at 6:22 PM, Dave Taht 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 lov= e > 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 explai= n > that the > >>> >>> latency is almost certainly caused by bufferbloat, but that shoul= d > 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 fo= r > >>> >> "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 th= e > 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 starte= d > 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 da= ta > >>> >> 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 woul= d > >>> > 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=C3=A4ht > > Open Networking needs **Open Source Hardware** > > > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > > > > -- > Dave T=C3=A4ht > 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 > --001a11c31700578a28051471460e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The problem with metronome pinging is when there is a stal= l, 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 instan= t (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= 9;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'l= l 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 hou= r or two to add features or improve existing ones. If something is suggeste= d but not implemented, or noted but not fixed it is just my time management= failing.

I've a continuing problem with brows= ers 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 hope= fully the measurements are still being taken, and will be in the results.

I agree that browsers are not ideal for testing, al= though most now seem ok at delegating to the OS most of the job of receivin= g or sending, and do not appear to be writing disk, But I think a desktop O= S is always going to give priority to interactive applications over "b= ackground" network activity.

However it does = seem that connection speeds are improving at a similar, but not faster, rat= e to new hardware, so perhaps it will never be an issue. There is always th= e option of linking two or more devices with browsers behind the same IP, a= nd 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 probl= em overwhelming the port with the gadgets on hand, and the browsers they co= me with.

On Fri, Apr 24, 2015 at 2:04 PM, Dave Taht <dave.taht@gmail.com&g= t; wrote:
Summary result from my h= otel, with 11 seconds of bloat.

ht= tp://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 a= nd
>> purposes infinite buffering, so you can end up with not just secon= ds, but
>> even minutes of bloat.=C2=A0 The current interplanetary record for= bufferbloat is
>> GoGo inflight is 760(!) seconds of buffering (using netperf-wrappe= r, RRUL
>> test, on several flights); Mars is closer to Earth than that for p= art of its
>> orbit.=C2=A0 I've seen 60 seconds or so on some XFinity WiFi a= nd similar amounts
>> of bloat on some cellular systems.=C2=A0 Exactly how quickly one m= ight 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 use= rs on the
>> plane will suffer, and their Squid proxy dies entirely.=C2=A0 And = the government
>> just asked people to report "hackers" on airplanes....= =C2=A0 Would that GoGo
>> listen to the mail and tweets I sent them to try to report the pro= blem to
>> them....=C2=A0 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".=C2=A0 Anyone that gets busted by testing for buffe= rbloat 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<= br> > (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 twe= et
> 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<= br> > test, also, which I hope is not illegal (?). I personally don't wa= nt
> 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 convin= cing than I even
>>> >>> thought it would be. These comments are focused o= n the "theater" of the
>>> >>> measurements, so that they are unambiguous, and t= hat 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 f= or 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 sh= ould be
>>> > "Bufferbloat (lag) in msec"
>>>
>>> Works for me.
>>>
>>> >
>>> >> ... rather
>>> >> than make people look up another word buried in the d= oc. 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 o= ther 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 gaug= e, however.
>>> >
>>> > I see this as well (Firefox in Linux). It seems OK in oth= er browser
>>> > combinations. (I have *not* done the full set of variatio= ns...)
>>> >
>>> > If this is a matter that FF won't show that gizmo, pe= rhaps there could
>>> > be a rectangle (like the blue/red ones) for Latency that = shows:
>>> >
>>> >=C2=A0 =C2=A0 Latency
>>> >=C2=A0 =C2=A0 Down: min/avg/max
>>> >=C2=A0 =C2=A0 Up: min/avg/max
>>> >
>>> >> Lastly, the static radar plot of pings occupies cente= r stage yet does
>>> >> not do anything later in the test. Either animating i= t to show the
>>> >> bloat, or moving it off of center stage and the new b= loat gauge to
>>> >> center stage after it sounds the net, would be good.<= br> >>> >
>>> > I have also wondered about whether we should find a way t= o add further
>>> > value to the radar display. I have not yet come up with u= seful suggestions,
>>> > though.
>>>
>>> Stick it center stage and call it the "Bloat-o-Meter?&quo= t;
>>>
>>> >> bufferbloat as a single word is quite googlable to go= od resources, and
>>> >> there is some activity on fixing up wikipedia going o= n that I like a
>>> >> lot.
>>> >>
>>> >>>
>>> >>> 2) I can't explain why the latency gauge star= ts at 1-3 msec. I am
>>> >>> guessing that it's showing incremental latenc= y above the nominal value
>>> >>> measured during the initial setup. I recommend th= at 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 ga= uge before/after the
>>> >>> test. I'd like it to change only when when so= mething else is moving in the
>>> >>> window. Here are some suggestions for what would = make it clearer:
>>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - 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 upl= oad chart started at 0:31.
>>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Between the download= and upload tests, the gauge should drop
>>> >>> back to the nominal measured values. I think it d= oes.
>>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - After the test, the = gauge should also drop back to the
>>> >>> nominal measured value. It seems stuck at 4928 ms= ec (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 pol= lute the last few
>>> >> data points in bloated scenarios. You have to wait fo= r the queues to
>>> >> drain to get a "clean" test - although this= begins to show what
>>> >> actually happen when the link is buried in both direc= tions.
>>> >>
>>> >> Is there any chance to add a simultaneous up+down+pin= g test at the
>>> >> conclusion?
>>> >
>>> > This confuses the "speed test" notion of this s= ite. Since the flow of
>>> > ack's can eat up 25% of the bandwidth of a slow, asym= metric link, I am
>>> > concerend that people would wonder why their upload bandw= idth suddenly went
>>> > down dramatically...
>>>
>>> To me, that would help. Far too many think that data just arri= ves by
>>> magic and doesn't have an ack clock.
>>>
>>> > Given that other speed test sites only show upload/downlo= ad, I would
>>> > vote to keep that format here. Perhaps there could be an<= br> >>> > 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 a= n "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 latenc= y - 765 msec (0:29) -
>
> --
> Dave T=C3=A4ht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr= 67



--
Dave T=C3=A4ht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat

--001a11c31700578a28051471460e--