On Thu, Apr 23, 2015 at 10:00 PM, jb <[email protected]> wrote: > 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.
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 the > 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 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. > > 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. > > 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. > > 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. > > On Fri, Apr 24, 2015 at 2:04 PM, Dave Taht <[email protected]> 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 <[email protected]> wrote: >> > On Thu, Apr 23, 2015 at 8:20 PM, Jim Gettys <[email protected]> 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 fill >> >> 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 the >> >> plane will suffer, and their Squid proxy dies entirely. And the >> >> government >> >> 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 >> >> 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 <[email protected]> wrote: >> >>> >> >>> On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown <[email protected]> >> >>> wrote: >> >>> > >> >>> > On Apr 23, 2015, at 6:22 PM, Dave Taht <[email protected]> wrote: >> >>> > >> >>> >> On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown >> >>> >> <[email protected]> >> >>> >> 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 >> >>> >>> 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, 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 >> >>> > 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. >> >>> >> >>> 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 >> >>> >>> 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. >> >>> >>> >> >>> >>> 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). >> >>> >> >> >>> >> 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 >> >>> >> 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 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? >> >>> >> >> >>> >> It is not clear to me what they are. >> >>> >> >> >>> >>> 5) The gauge makes it appear that moderate latency - 765 msec >> >>> >>> (0:29) - >> > >> > -- >> > Dave Täht >> > Open Networking needs **Open Source Hardware** >> > >> > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >> >> >> >> -- >> Dave Täht >> Open Networking needs **Open Source Hardware** >> >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >> _______________________________________________ >> Bloat mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/bloat > > -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
