From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 9573B21F3BC for ; Thu, 23 Apr 2015 21:04:56 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so29135128obb.3 for ; Thu, 23 Apr 2015 21:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JRw8rvdtvMMdF7CeHNOT68PSJcHjpTlof8EiP2JCDCQ=; b=WFAC2K1V5ENtwBzNXW1jwbFdZcxTHPZmPiyJ5Cyku7Iw2bpnAvtAF27xlii6gawcws MotB4QWRz5Z4S8Mlxc9fXTTt0Judt4i5kPo/AfWCuJpwrWjl5sbbmJmPl6w8Tcs8MpgW 5raoLz70kni5ZMnR13G6MEFbJrqlzPzlBRbxMe7/7mOJAAAAMMhJDVzGQpRSJsO9ZaNo M52oQwpDZ2ICftMjKy5asQfvJzGsOF9nR74GInOxkuzwqK+3qfPg7/R/Syg/GKEFhJ77 bLMVHEAoJGt3m/7O1YUtK2xHUTCLmFPRdxkHqyIkccY3nGYucwcHvE8p7hRnmOkokc2I mu2Q== MIME-Version: 1.0 X-Received: by 10.60.60.70 with SMTP id f6mr5483822oer.8.1429848295392; Thu, 23 Apr 2015 21:04:55 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Thu, 23 Apr 2015 21:04:55 -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: Thu, 23 Apr 2015 21:04:55 -0700 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat 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 04:05:24 -0000 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, bu= t >> even minutes of bloat. The current interplanetary record for bufferbloa= t is >> GoGo inflight is 760(!) seconds of buffering (using netperf-wrapper, RRU= L >> 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 amou= nts >> of bloat on some cellular systems. Exactly how quickly one might fill s= uch >> 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 governm= ent >> 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 t= o >> them.... If anyone on the list happens to know someone from GoGo, I'd l= ike >> 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 >>> >> 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 fig= ure 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 t= hat 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 a= n >>> >> 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 showin= g >>> >> 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 coul= d >>> > 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 doe= s >>> >> 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 furthe= r >>> > value to the radar display. I have not yet come up with useful sugges= tions, >>> > though. >>> >>> Stick it center stage and call it the "Bloat-o-Meter?" >>> >>> >> bufferbloat as a single word is quite googlable to good resources, a= nd >>> >> 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 va= lue >>> >>> measured during the initial setup. I recommend that the gauge alway= s 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 t= he >>> >>> 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 t= he 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 dr= op >>> >>> 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 f= ew >>> >> 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 a= m >>> > concerend that people would wonder why their upload bandwidth suddenl= y 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 h= appy 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 --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67