[190715] in North American Network Operators' Group
Re: I recommend dslreports.com/speedtest these days (was
daemon@ATHENA.MIT.EDU (Jim Gettys)
Fri Jul 22 15:35:52 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <414BCE73-08E8-4D0B-9056-C629CA8F2C03@truenet.com>
From: Jim Gettys <jg@freedesktop.org>
Date: Fri, 22 Jul 2016 15:23:00 -0400
To: Eric Tykwinski <eric-list@truenet.com>
Cc: jb <justin@dslr.net>, nanog list <nanog@nanog.org>,
=?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>,
Dave Taht <dave.taht@gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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=E2=80=99m sure most other=
s 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/>.
>
>
=E2=80=8BWe recommend Toke H=C3=B8iland-J=C3=B8rgensen's
=E2=80=8B
"flent" =E2=80=8B
=E2=80=8Bhttps://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).=E2=80=8B
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.
=E2=80=8B
Gives you lots of useful graphs, will do diffserv marking, etc...=E2=80=8B
=E2=80=8B
> > 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=3D=
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 lette=
r
> >> grades on speed are a bit pessimistic (65Mbps is a "C").
>
=E2=80=8B
Most applications are as sensitive/more sensitive to latency than to
bandwidth
=E2=80=8B; see the research in the field, for example, for web browsing. F=
or web
browsing, you are at the point of diminishing returns on bandwidth after a
few megabits/second, for most use=E2=80=8B
.
=E2=80=8B For telephony, the metric is always the lower the better, and no=
t more
than 100ms or so (continental delay).=E2=80=8B
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
=E2=80=8B, 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
=E2=80=8B =E2=80=8B
day.
=E2=80=8B It will work reliably, I'll be able to make my phone calls withou=
t
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.
=E2=80=8B
> >>
> >> 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=E2=80=99d agree with the pessimistic scoring.. 160Mbit was given a =
=E2=80=9CB=E2=80=9D grade.
> >
> >
> >
> >
>
>
