From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 266BA21F3AA for ; Thu, 23 Apr 2015 19:40:24 -0700 (PDT) Received: by obfe9 with SMTP id e9so28173418obf.1 for ; Thu, 23 Apr 2015 19:40:23 -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=O6sevxqAG2VjJzRjgkvtoQIbmNQ3RSTQWaChnmQwJUU=; b=P80Vv2BeO3ahXwDaYpMiDaXFLvKlyDBz6MtAMDYyVPiR4RhJGpvDQvJ/vtMDDU/d+7 JfkA1fqahlZPtu8iSmdUlyAcY9WMskLS+u4WEg1hOawIKYLJAf10fz328/+adXQdecNS 7yAx72e/1kzsy5bd2CtxQMXY7vyLLlfLG7yumonUOu/7zBmj6qMjGOhJdzEGN0j5Yyyu eoc5rozIEL45AHID1huvjcX9PWHNKByDA9zj2ZjymA70NHlyiQa9kmPGoeQFo65noBuO 3NPJLtbZmmf4N5KRCoHKn56P84o8xK25/2SvE1Vppqv9xiMzrAM/8M2U8C3ANXK57Vbv zs7A== MIME-Version: 1.0 X-Received: by 10.182.148.166 with SMTP id tt6mr5163865obb.63.1429843223714; Thu, 23 Apr 2015 19:40:23 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Thu, 23 Apr 2015 19:40:23 -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 19:40:23 -0700 Message-ID: From: Dave Taht To: Rich Brown 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 02:40:53 -0000 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 wr= ote: >>> Hi Justin, >>> >>> The newest Speed Test is great! It is more convincing than I even thoug= ht it would be. These comments are focused on the "theater" of the measurem= ents, so that they are unambiguous, and that people can figure out what's h= appening >>> >>> I posted a video to Youtube at: http://youtu.be/EMkhKrXbjxQ to illustra= te 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 combi= nations. (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 va= lue to the radar display. I have not yet come up with useful suggestions, t= hough. 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 guess= ing that it's showing incremental latency above the nominal value measured = during the initial setup. I recommend that the gauge always show actual lat= ency. 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 t= est. I'd like it to change only when when something else is moving in the w= indow. Here are some suggestions for what would make it clearer: >>> - The gauge should not change until the graph starts moving. I f= ound it confusing to see the latency jump up at 0:13 just before the blue d= ownload chart started, or at 0:28 before the upload chart started at 0:31. >>> - Between the download and upload tests, the gauge should drop b= ack 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 concl= usion? > > 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 concere= nd that people would wonder why their upload bandwidth suddenly went down d= ramatically... 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/sett= ing 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 th= e 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) - = is the same as when the value goes to 1768 msec (0:31), and also when it go= es to 4,447 msec (0:35), etc. It might make more sense to have the chart's = full-scale at something like 10 seconds during the test. The scale could be= logarithmic, so that "normal" values occupy up to a third or half of scale= , and bad values get pretty close to the top end. Horrible latency - greate= r than 10 sec, say - should peg the indicator at full scale. >> >> I am generally resistant to log scales as misleading an untrained eye. >> In this case I can certainly see the gauge behaving almost as >> described above, except that I would nearly flatline the gauge at > >> 250ms, and add indicators for higher rates at the outer edges of the >> graph. > > I am suggesting a slightly different representation. Instead of flatlinin= g (I assume that you mean full-scale indicator of the gauge) at 250msec (wh= ich I agree is bad), perhaps the gauge could use the levels I sent in a pre= vious message... Nearly full scale (graph in red), with a few additional lines just past that with the snarky annotations. (think of a classic automobile rpm tach) > >> I agree that the results graph should never be logarithmic - it hides th= e bad >> news of high latency. >> >> However, the gauge that shows instantaneous latency could be logarithmic= . I was >> reacting to the appearance of slamming against the limit at 765 msec, th= en not making it >> more evident when latency jumped to 1768 msec, then to 4447 msec. Well the actual number above the beyond redlined gauge makes for a good screenshot. >> Imagine the same gauge, with the following gradations at these clock pos= itions, >> with the bar colored to match: >> >> 0 msec - 9:00 (straight to the left) >> 25 msec - 10:00 >> 100 msec - 11:00 >> 250 msec - 12:00 >> 1,000 msec - 1:00 >> 3,000 msec - 2:00 >> 10,000+ msec - 3:00 (straight to the left) > >> I can see staying below 30ms induced latency as "green", below 100ms >> as "blue", below 250ms as yellow, and > 250ms as red, and a line >> marking "rediculous" at > 1sec, and "insane" at 2sec would be good. >> Other pithy markings at the end of the tach would be fun. For example, >> gogo in flight has the interplanetary record for bufferbloat, >> something like 760 seconds the last time we tried it, so a 3rd line on >> the tach for earth-mars distances would be amusing. > > These color schemes sound good. It could indeed be amusing to have editor= ial comments ("ludicrous bloat") for the worst situations. > >> In the long term, somehow detecting if FQ is in play would be good, >> but I have no idea how to do that in a browser. >> >>> 6) On the Results page (1:20), I like the red background behind the lat= ency values. I don't understand why the grey bars at the right end of the c= hart are so high. Is the latency still decreasing as the queue drains? Perh= aps the ping tests should run longer until it gets closer to the nominal va= lue. >> >> I would suspect the queues are still draining, filled with missing >> acknowledgements, etc, etc. waiting until the ping returned closer to >> normal before starting the next phase of the test would help. > > This sounds right to me. > >>> This is such a great tool. Thanks! >> >> I am very, very, very delighted also. I hope that with tools like >> these in more users hands, AND the data collected from them, that we >> can make a logarithmic jump in the number of users, devices, and ISPs >> that have good bandwidth and low latency in the near future. >> >> Thank you very, very much for the work. >> >> As a side note, justin, have you fixed your own bloat at home? >> >>> >>> Rich >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> >> >> -- >> Dave T=C3=A4ht >> Open Networking needs **Open Source Hardware** >> >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > > Rich > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67