Re: I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

[Jay Ashworth <jra () baylink com>]

Just a quick clarifying reply, I have had DSL test give me an A for bufferbloat and a C for Speed on a 75 Meg line.

On July 22, 2016 3:23:00 PM EDT, Jim Gettys <jg () freedesktop org> wrote:
> 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.net
> > > > > For any ISPs/content providers linking to speedtest.net you may
> want
> > to
> > > > > swap 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 a
> > > Are you talking about the dslreports speedtest? I like that one,
> very
> > detailed results.
> > > http://speedtest.dslreports.com/
> > >
> > >
> > > I’d agree with the pessimistic scoring.. 160Mbit was given a “B”
> grade.
> > >

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.