From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 7C55A21F199 for ; Mon, 27 Apr 2015 09:28:14 -0700 (PDT) Received: by obcux3 with SMTP id ux3so87354212obc.2 for ; Mon, 27 Apr 2015 09:28:11 -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=iqhnuS/+Rusxm/veVX6DxuSc51FOxC1CJpAMRsF3wfw=; b=pfzDHoXWPt85/eHRcUFyakJZ+iJ4IfQf0OXqEqMbJi62OdD7euDHPohvJNWle723Cx 8gBJagqPfAJQDdNfaNV7Gz3q3A7V7U3K86gvwiTNr1RYiLhYjNguhWzPEMfNXJV1HCqG +33oYWMgu/LUCM/K07egKaKUcqwQhbMzhSC+SeBwRuTAbXSqj4gIKSSy3GjJMIAv9lx7 fFpRcFgsevOtdNaK2v/cwwFg98X0zt6MHaMgpqeMjcPqE4z4xVWYeWkMZzHEumm0tr5r dQy9YL3Dk3DFjCBDQDJ9flNEJn3RXJJGUm9nWTdVNRUFr1F3lkgNmFd4d68QLPlRCgt+ o7mw== MIME-Version: 1.0 X-Received: by 10.182.29.101 with SMTP id j5mr10877470obh.0.1430152091593; Mon, 27 Apr 2015 09:28:11 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Mon, 27 Apr 2015 09:28:11 -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: Mon, 27 Apr 2015 09:28:11 -0700 Message-ID: From: Dave Taht To: jb 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: Mon, 27 Apr 2015 16:28:55 -0000 On Thu, Apr 23, 2015 at 10:00 PM, jb wrote: > The problem with metronome pinging is when there is a stall, they all pil= e > up then when they are released, you get this illusion of a 45 degree slop= e > of diminishing pings They all came back at the same instant (the 30 secon= d > 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 th= e > 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 o= f > each day doing other stuff too. So I only get an hour or two to add featu= res > 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 w= hen > asked to do these little charts so if there is no gauge visible during th= e > 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 o= k > at delegating to the OS most of the job of receiving or sending, and do n= ot > appear to be writing disk, But I think a desktop OS is always going to gi= ve > priority to interactive applications over "background" network activity. > > However it does seem that connection speeds are improving at a similar, b= ut > 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 Nationa= l > Broadband Network fiber to the home this year, and a 1 gig port - and pig= s > 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 fil= l >> >> 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 t= he >> >> plane will suffer, and their Squid proxy dies entirely. And the >> >> government >> >> just asked people to report "hackers" on airplanes.... Would that Go= Go >> >> listen to the mail and tweets I sent them to try to report the proble= m >> >> 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 wrot= e: >> >>> >> >>> 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 eve= n >> >>> >>> 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, s= o >> >>> >>> that the >> >>> >>> results would be more extreme. >> >>> >>> >> >>> >>> 1) It would be great to label the gauge as "Latency (msec)" I lo= ve >> >>> >>> 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 expla= in >> >>> >>> that the >> >>> >>> latency is almost certainly caused by bufferbloat, but that shou= ld >> >>> >>> 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 f= or >> >>> >> "lag" on the internet takes you to a lot of wrong places, >> >>> >> misinformation, and snake oil. So perhaps in doc page I would hav= e >> >>> >> an >> >>> >> explanation of lag as it relates to bufferbloat and other possibl= e >> >>> >> 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 browse= r >> >>> > 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 th= e >> >>> >> bloat, or moving it off of center stage and the new bloat gauge t= o >> >>> >> 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 lik= e >> >>> >> a >> >>> >> lot. >> >>> >> >> >>> >>> >> >>> >>> 2) I can't explain why the latency gauge starts at 1-3 msec. I a= m >> >>> >>> 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 t= he >> >>> >>> video) >> >>> >>> then change during the measurements. >> >>> >>> >> >>> >>> 3) I was a bit confused by the behavior of the gauge before/afte= r >> >>> >>> 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 befor= e >> >>> >>> the blue >> >>> >>> download chart started, or at 0:28 before the upload chart start= ed >> >>> >>> 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 las= t >> >>> >> 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 th= e >> >>> >> 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 wou= ld >> >>> > 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 tes= t. >> >>> >>> It's OK for it to use the color to indicate an "opinion". Are yo= u >> >>> >>> 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 > > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67