nanog mailing list archives
Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)
From: Jim Gettys <jg () freedesktop org>
Date: Fri, 22 Jul 2016 15:23:00 -0400
I don't read this list continually, but do archive it; your note was flagged for me to comment on. On Thu, Jul 21, 2016 at 8:11 PM, Eric Tykwinski <eric-list () truenet com> wrote:
This is probably for Jim Gettys directly, but I’m sure most others have input. I could of sworn that that there was some test made to detect it directly on switches and routers? Sort of like iperf, but to test bufferbloat specifically given the OS stack which is going to have issues as well, as shown on bufferbloat.net <http://bufferbloat.net/>.
We recommend Toke Høiland-Jørgensen's "flent" https://flent.org/ for testing connections/devices/gear. It uses "netperf" transfers to load the link (by default with 4 simultaneous TCP connections in both directions, IIRC), and then runs another test (by default "ping") at the same time to test the connection under load. Turning on a netperf server is just as easy as turning on an iperf server (and the results are better, and netperf's maintainer responsive). See the documentation/paper on Toke's web site. The "RRUL" test ("Real-Time Response Under Load") is the one we use most/is best shaken down. I'm sure Toke would love help with other tests. Gives you lots of useful graphs, will do diffserv marking, etc...
On Jul 21, 2016, at 6:36 PM, Donn Lasher via NANOG <nanog () nanog org>wrote:On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <nanog-bounces () nanog org on behalf of jra () baylink com> wrote:----- Original Message -----From: "Janusz Jezowicz" <janusz () speedchecker xyz>Since this morning Speedtest.net is not accessible in Chrome Reason:https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.speedtest.netFor any ISPs/content providers linking to speedtest.net you may wanttoswap links to a different website or host your own speed test.So far, I am very pleased with how it works, though I think it's letter grades on speed are a bit pessimistic (65Mbps is a "C").
Most applications are as sensitive/more sensitive to latency than to bandwidth ; see the research in the field, for example, for web browsing. For web browsing, you are at the point of diminishing returns on bandwidth after a few megabits/second, for most use . For telephony, the metric is always the lower the better, and not more than 100ms or so (continental delay). So it is entirely appropriate in my view to give even "high speed" connections low grades; it's telling you that they suck under load , like when your kid is downloading a video (or uploading one for their friends); your performance (e.g. web surfing) can go to hell in a hand-basket despite having a lot of bandwidth on the connection. For most use, I'll take a 20Mbps link without bloat to a 200Mbps one with a half second of bloat any day. It will work reliably, I'll be able to make my phone calls without problems, I'll be able to frag my friends with the best of them, etc... Even video playback gets wonky with bad bufferbloat: the player's control loop is interacting with the (wildly excessive due to bloat) TCP control loop and can't find a good playback point; seeking also becomes slow, etc. Activities such as web browsing can/does cause transient latency on a link, since most links are not doing decent scheduling; the damage is done anytime the link gets used by anyone, for anything, including web surfing as well as background activities such as backup or system update. So no, I don't think dslreports grades pessimistically: it's just that bad bufferbloat is so *blinking* common and bad. And I had nothing to do with setting the scoring system: that's the opinion of the dslreports test's author; but I think Justin has done a good job choosing the grades to boil down the quality of a connection to something mere mortals (your customer's) will understand. So my hat is off to Justin for doing a great job.
Specifically, it measures bufferbloat, with both a realtime graph and aAre you talking about the dslreports speedtest? I like that one, verydetailed results.http://speedtest.dslreports.com/ I’d agree with the pessimistic scoring.. 160Mbit was given a “B” grade.
Current thread:
- Re: Speedtest.net not accessible in Chrome due to deceptive ads, (continued)
- Re: Speedtest.net not accessible in Chrome due to deceptive ads Jacques Latour (Jul 20)
- Re: Speedtest.net not accessible in Chrome due to deceptive ads Rubens Kuhl (Jul 20)
- Re: Speedtest.net not accessible in Chrome due to deceptive ads Collin Anderson (Jul 20)
- Re: Speedtest.net not accessible in Chrome due to deceptive ads Antonio Querubin (Jul 20)
- Re: Speedtest.net not accessible in Chrome due to deceptive ads Collin Anderson (Jul 20)
- Re: Speedtest.net not accessible in Chrome due to deceptive ads Livingood, Jason (Jul 22)
- RE: Speedtest.net not accessible in Chrome due to deceptive ads Jacques Latour (Jul 22)
- Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Donn Lasher via NANOG (Jul 21)
- Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Eric Tykwinski (Jul 21)
- Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Jim Gettys (Jul 22)
- RE: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Eric Tykwinski (Jul 22)
- Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Baldur Norddahl (Jul 22)
- Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Jim Gettys (Jul 22)
- Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads) Jim Gettys (Jul 26)