[190723] in North American Network Operators' Group
Re: I recommend dslreports.com/speedtest these days (was
daemon@ATHENA.MIT.EDU (Jay Ashworth)
Fri Jul 22 18:05:26 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <CAGhGL2Bm1WuCWVZzqxhBS7jWFn1ws_x=Wz2sZoEf1Kd9+9pH7A@mail.gmail.com>
From: Jay Ashworth <jra@baylink.com>
Date: Fri, 22 Jul 2016 18:05:18 -0400
To: Jim Gettys <jg@freedesktop.org>,Eric Tykwinski <eric-list@truenet.com>
Cc: jb <justin@dslr.net>, nanog list <nanog@nanog.org>,
=?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= <toke@toke.dk>,
Dave Taht <dave.taht@gmail.com>
Errors-To: nanog-bounces@nanog.org
Just a quick clarifying reply, I have had DSL test give me an A for buffe=
rbloat 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=E2=80=99m sure most ot=
hers
>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 use=
s
>"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
>letter
>> >> 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.=
For
>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=
not
>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 f=
or
>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 wit=
hout
>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.
>> >
>> >
>> >
>> >
>>
>>
--=20
Sent from my Android device with K-9 Mail. Please excuse my brevity.
