<div dir="ltr">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.<div><br></div><div>I'm not sure what to do with that information, just there it is.</div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 24, 2015 at 2:04 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Summary result from my hotel, with 11 seconds of bloat.<br>
<br>
<a href="http://www.dslreports.com/speedtest/353034" target="_blank">http://www.dslreports.com/speedtest/353034</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Apr 23, 2015 at 8:39 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
> On Thu, Apr 23, 2015 at 8:20 PM, Jim Gettys <<a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a>> wrote:<br>
>> I love the test, and thanks for the video!<br>
>><br>
>> There is an interesting problem: some paths have for all intents and<br>
>> purposes infinite buffering, so you can end up with not just seconds, but<br>
>> even minutes of bloat. The current interplanetary record for bufferbloat is<br>
>> GoGo inflight is 760(!) seconds of buffering (using netperf-wrapper, RRUL<br>
>> test, on several flights); Mars is closer to Earth than that for part of its<br>
>> orbit. I've seen 60 seconds or so on some XFinity WiFi and similar amounts<br>
>> of bloat on some cellular systems. Exactly how quickly one might fill such<br>
>> buffers depends on the details of load parts of a test.<br>
>><br>
>> Please don't try the netperf-wrapper test on GoGo; all the users on the<br>
>> plane will suffer, and their Squid proxy dies entirely. And the government<br>
>> just asked people to report "hackers" on airplanes.... Would that GoGo<br>
>> listen to the mail and tweets I sent them to try to report the problem to<br>
>> them.... If anyone on the list happens to know someone from GoGo, I'd like<br>
>> to hear about it.<br>
><br>
> I have also sent mail and tweets to no effect.<br>
><br>
> I hereby donate 1k to the "bufferbloat testing vs gogo-in-flight legal<br>
> defense fund". Anyone that gets busted by testing for bufferbloat on<br>
> an airplane using these new tools or the rrul test can tap me for<br>
> that. Anyone else willing to chip in?[1]<br>
><br>
> 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<br>
> back) so you'd probably have to tweet something like<br>
><br>
> "I am about to test for bufferbloat on my flight. If I do not tweet<br>
> again for the next 4 hours, I blew up gogo-in-flight, and expect to be<br>
> met by secret service agents on landing with no sense of humor about<br>
> how network congestion control is supposed to work."<br>
><br>
> FIRST. (and shrink the above to 140 pithy characters)<br>
><br>
> [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 want<br>
> to do the test as I have better things to do than rewrite walden and<br>
> am not fond of roomates named "bubba".<br>
><br>
> ... but I admit to being tempted.<br>
><br>
>> On Thu, Apr 23, 2015 at 7:40 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>>><br>
>>> On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown <<a href="mailto:richb.hanover@gmail.com">richb.hanover@gmail.com</a>><br>
>>> wrote:<br>
>>> ><br>
>>> > On Apr 23, 2015, at 6:22 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
>>> ><br>
>>> >> On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown <<a href="mailto:richb.hanover@gmail.com">richb.hanover@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >>> Hi Justin,<br>
>>> >>><br>
>>> >>> The newest Speed Test is great! It is more convincing than I even<br>
>>> >>> thought it would be. These comments are focused on the "theater" of the<br>
>>> >>> measurements, so that they are unambiguous, and that people can figure out<br>
>>> >>> what's happening<br>
>>> >>><br>
>>> >>> I posted a video to Youtube at: <a href="http://youtu.be/EMkhKrXbjxQ" target="_blank">http://youtu.be/EMkhKrXbjxQ</a> to<br>
>>> >>> illustrate my points. NB: I turned fq_codel off for this demo, so that the<br>
>>> >>> results would be more extreme.<br>
>>> >>><br>
>>> >>> 1) It would be great to label the gauge as "Latency (msec)" I love the<br>
>>> >>> term "bufferbloat" as much as the next guy, but the Speed Test page should<br>
>>> >>> call the measurement what it really is. (The help page can explain that the<br>
>>> >>> latency is almost certainly caused by bufferbloat, but that should be the<br>
>>> >>> place it's mentioned.)<br>
>>> >><br>
>>> >> I would prefer that it say "bufferbloat (lag in msec)" there,<br>
>>> ><br>
>>> > OK - I change my opinion. I'll be fussy and say it should be<br>
>>> > "Bufferbloat (lag) in msec"<br>
>>><br>
>>> Works for me.<br>
>>><br>
>>> ><br>
>>> >> ... rather<br>
>>> >> than make people look up another word buried in the doc. Sending<br>
>>> >> people to the right thing, at the getgo, is important - looking for<br>
>>> >> "lag" on the internet takes you to a lot of wrong places,<br>
>>> >> misinformation, and snake oil. So perhaps in doc page I would have an<br>
>>> >> explanation of lag as it relates to bufferbloat and other possible<br>
>>> >> causes of these behaviors.<br>
>>> >><br>
>>> >> I also do not see the gauge in my linux firefox, that you are showing<br>
>>> >> on youtube. Am I using a wrong link. I LOVE this gauge, however.<br>
>>> ><br>
>>> > I see this as well (Firefox in Linux). It seems OK in other browser<br>
>>> > combinations. (I have *not* done the full set of variations...)<br>
>>> ><br>
>>> > If this is a matter that FF won't show that gizmo, perhaps there could<br>
>>> > be a rectangle (like the blue/red ones) for Latency that shows:<br>
>>> ><br>
>>> > Latency<br>
>>> > Down: min/avg/max<br>
>>> > Up: min/avg/max<br>
>>> ><br>
>>> >> Lastly, the static radar plot of pings occupies center stage yet does<br>
>>> >> not do anything later in the test. Either animating it to show the<br>
>>> >> bloat, or moving it off of center stage and the new bloat gauge to<br>
>>> >> center stage after it sounds the net, would be good.<br>
>>> ><br>
>>> > I have also wondered about whether we should find a way to add further<br>
>>> > value to the radar display. I have not yet come up with useful suggestions,<br>
>>> > though.<br>
>>><br>
>>> Stick it center stage and call it the "Bloat-o-Meter?"<br>
>>><br>
>>> >> bufferbloat as a single word is quite googlable to good resources, and<br>
>>> >> there is some activity on fixing up wikipedia going on that I like a<br>
>>> >> lot.<br>
>>> >><br>
>>> >>><br>
>>> >>> 2) I can't explain why the latency gauge starts at 1-3 msec. I am<br>
>>> >>> guessing that it's showing incremental latency above the nominal value<br>
>>> >>> measured during the initial setup. I recommend that the gauge always show<br>
>>> >>> actual latency. Thus the gauge could start at 45 msec (0:11 in the video)<br>
>>> >>> then change during the measurements.<br>
>>> >>><br>
>>> >>> 3) I was a bit confused by the behavior of the gauge before/after the<br>
>>> >>> test. I'd like it to change only when when something else is moving in the<br>
>>> >>> window. Here are some suggestions for what would make it clearer:<br>
>>> >>> - The gauge should not change until the graph starts moving. I<br>
>>> >>> found it confusing to see the latency jump up at 0:13 just before the blue<br>
>>> >>> download chart started, or at 0:28 before the upload chart started at 0:31.<br>
>>> >>> - Between the download and upload tests, the gauge should drop<br>
>>> >>> back to the nominal measured values. I think it does.<br>
>>> >>> - After the test, the gauge should also drop back to the<br>
>>> >>> nominal measured value. It seems stuck at 4928 msec (0:55).<br>
>>> >><br>
>>> >> We had/have a lot of this problem in netperf-wrapper - a lot of data<br>
>>> >> tends to accumulate at the end of the test(s) and pollute the last few<br>
>>> >> data points in bloated scenarios. You have to wait for the queues to<br>
>>> >> drain to get a "clean" test - although this begins to show what<br>
>>> >> actually happen when the link is buried in both directions.<br>
>>> >><br>
>>> >> Is there any chance to add a simultaneous up+down+ping test at the<br>
>>> >> conclusion?<br>
>>> ><br>
>>> > This confuses the "speed test" notion of this site. Since the flow of<br>
>>> > ack's can eat up 25% of the bandwidth of a slow, asymmetric link, I am<br>
>>> > concerend that people would wonder why their upload bandwidth suddenly went<br>
>>> > down dramatically...<br>
>>><br>
>>> To me, that would help. Far too many think that data just arrives by<br>
>>> magic and doesn't have an ack clock.<br>
>>><br>
>>> > Given that other speed test sites only show upload/download, I would<br>
>>> > vote to keep that format here. Perhaps there could be an<br>
>>> > option/preference/setting to do up/down/ping .<br>
>>> ><br>
>>> >>> 4) I like the way the latency gauge changes color during the test.<br>
>>> >>> It's OK for it to use the color to indicate an "opinion". Are you happy with<br>
>>> >>> the thresholds for yellow & red colors?<br>
>>> >><br>
>>> >> It is not clear to me what they are.<br>
>>> >><br>
>>> >>> 5) The gauge makes it appear that moderate latency - 765 msec (0:29) -<br>
><br>
> --<br>
> Dave Täht<br>
> Open Networking needs **Open Source Hardware**<br>
><br>
> <a href="https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67" target="_blank">https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67</a><br>
<br>
<br>
<br>
--<br>
Dave Täht<br>
Open Networking needs **Open Source Hardware**<br>
<br>
<a href="https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67" target="_blank">https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</div></div></blockquote></div><br></div>