From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d: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 CE37921F1FA for ; Thu, 23 Apr 2015 18:58:35 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so19229842qcb.2 for ; Thu, 23 Apr 2015 18:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9toJrK0eABRTzVIjUoAKC1UFzdT45lze/66qQ4A416g=; b=ID4xdQJQ61C7K0aZW86t2KnoF7x40TdmeQCCdLnbKP32+hjxfnbvbZtLZdvu4DxPGT g2STuzmvRPGub2RC+wCgcLOUDJh8Qc2ilDpui1aWuK1GGhr+1YMLudNApZeSuh2Vjvjv AgcVXo5/mRXxopALCft1ZnHk0y9oK8yIkuku4CqoysgH3b6MKM0C0xYiaFbdy9ksZPTx tv7DyqT/j0A2VQEvQUMp+wc0jmKy6to/flQztximCwPRvSAYkJmgOcMxciE/+jqY//Th Hqdc87/XgwGXCYcHbW/FW/qFHZzK2ebfpjLOs5BicI04eN9BL92UoCSd/bK4ocd2JW3c m3Yg== X-Received: by 10.140.217.17 with SMTP id n17mr7102175qhb.69.1429840714613; Thu, 23 Apr 2015 18:58:34 -0700 (PDT) Received: from richs-mbp-11940.home.lan (d-ptld-bng1-71-161-114-95.ngn.east.myfairpoint.net. [71.161.114.95]) by mx.google.com with ESMTPSA id k4sm3162130qhk.18.2015.04.23.18.58.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 18:58:33 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rich Brown In-Reply-To: Date: Thu, 23 Apr 2015 21:58:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87wq18jmak.fsf@toke.dk> <87oamkjfhf.fsf@toke.dk> <87k2x8jcnw.fsf@toke.dk> <0D391BB1-9CA5-4DAF-8FD6-6628AB09C1C5@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.1878.6) 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 01:59:04 -0000 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, >>=20 >> 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 >>=20 >> 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. >>=20 >> 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.) >=20 > 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" > ... 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. >=20 > 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. >=20 > 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. >=20 >>=20 >> 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. >>=20 >> 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). >=20 > 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. >=20 > 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...=20 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? >=20 > It is not clear to me what they are. >=20 >> 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 goes 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 - greater than 10 sec, say - should peg the indicator = at full scale. >=20 > 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 = flatlining (I assume that you mean full-scale indicator of the gauge) at = 250msec (which I agree is bad), perhaps the gauge could use the levels I = sent in a previous message... > I agree that the results graph should never be logarithmic - it hides = the bad > news of high latency.=20 >=20 > However, the gauge that shows instantaneous latency could be = logarithmic. I was > reacting to the appearance of slamming against the limit at 765 msec, = then not making it > more evident when latency jumped to 1768 msec, then to 4447 msec.=20 >=20 > Imagine the same gauge, with the following gradations at these clock = positions, > with the bar colored to match: >=20 > 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 = editorial 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. >=20 >> 6) On the Results page (1:20), I like the red background behind the = latency values. I don't understand why the grey bars at the right end of = the chart are so high. Is the latency still decreasing as the queue = drains? Perhaps the ping tests should run longer until it gets closer to = the nominal value. >=20 > 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! >=20 > 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. >=20 > Thank you very, very much for the work. >=20 > As a side note, justin, have you fixed your own bloat at home? >=20 >>=20 >> Rich >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 >=20 >=20 > --=20 > Dave T=E4ht > Open Networking needs **Open Source Hardware** >=20 > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 Rich