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

[Jim Gettys]

Some additional comments from Dave Taht, who does not subscribe to the
nanog list.  Also note the early WiFi results, which are spectacular.  Your
customers will have bufferbloat both due to the ISP, and due to the WiFi
hop that is usually between them and their home router.  Unfortunately,
it's going to take years for the WiFi fixes to percolate through the
ecosystem, which is very dysfunctional (it's taken about 4 years to see
Docsis 3.1 modems, which are only now appearing).
- Jim

If you would like to see a plot of all the millions of samples
dslreports collected to date on the endemic bufferbloat along the edge
of the internet, as well as breakdowns by ISPs, see:

uploads: http://www.dslreports.com/speedtest/results/bufferbloat?up=1

downloads: http://www.dslreports.com/speedtest/results/bufferbloat

And look at the sea of stuff with latencies measured in the hundreds of
ms...
and get up off your ass and do something about it on your networks.

It's easy now.

The algorithms we've developed to fix it (fq_codel, pie) are in bsd,
and linux now; the ietf drafts are complete. These algorithms can move
induced latencies to well below 30ms in most cases, on ethernet, dsl,
cable, and fiber. fq_codel has been out there since 2012. A goodly
percentage of linux distros now defaults to fq_codel, but doing up the
chokepoints right involves replacing old shapers and policers with
these algorithms, additionally. See the "sqm-scripts" for how.

... side note ...


Fixing wifi with similar stuff has proven *very* difficult, but we've
made quite a bit of progress lately in the ath10k and ath9k chipsets,
that is not quite ready for prime time: pretty exciting summary, here:

https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html



On Fri, Jul 22, 2016 at 4:31 PM, Jim Gettys  wrote:

>
>
> On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl <
> baldur.nordd...@gmail.com> wrote:
>
>> Den 22. jul. 2016 21.34 skrev "Jim Gettys" :
>> >
>> >
>> > 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.
>> > ​
>>
>> I will expect that high speed links will have little bloat simply because
>> even large buffers empty quite fast.
>>
>
> ​Unfortunately, that is often/usually not the case.​
>
> ​  The buffering has typically scaled up as fast/faster than the bandwidth
> has, in my observation. You can have as much/more bloat on a higher
> bandwidth line as a low bandwidth line.
>
> That's why I always refer to buffering in seconds​, not bytes, unless I'm
> trying to understand how the identical equipment will behave at differing
> bandwidths.
>
> The worst is usually someone taking modern equipment and then running it
> at low speed: e.g. a gigabit switch being used at 100Mbps will generally be
> 10x worse than the old equipment it replaces (at best).
>
>  - Jim
>
>

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

[Jay Ashworth]

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  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 
>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 .
>>
>>
>​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
>
>> wrote:
>> >
>> > On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <
>> nanog-boun...@nanog.org on behalf of j...@baylink.com> wrote:
>> >
>> >
>> >
>> >> - Original Message -
>> >>> From: "Janusz Jezowicz" 
>> >>
>> >>> 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.

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

[Jim Gettys]

On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl 
wrote:

> Den 22. jul. 2016 21.34 skrev "Jim Gettys" :
> >
> >
> > 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.
> > ​
>
> I will expect that high speed links will have little bloat simply because
> even large buffers empty quite fast.
>

​Unfortunately, that is often/usually not the case.​

​  The buffering has typically scaled up as fast/faster than the bandwidth
has, in my observation. You can have as much/more bloat on a higher
bandwidth line as a low bandwidth line.

That's why I always refer to buffering in seconds​, not bytes, unless I'm
trying to understand how the identical equipment will behave at differing
bandwidths.

The worst is usually someone taking modern equipment and then running it at
low speed: e.g. a gigabit switch being used at 100Mbps will generally be
10x worse than the old equipment it replaces (at best).

 - Jim

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

[Baldur Norddahl]

Den 22. jul. 2016 21.34 skrev "Jim Gettys" :
>
>
> 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.
> ​

I will expect that high speed links will have little bloat simply because
even large buffers empty quite fast.

Regards

Baldur

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

[Eric Tykwinski]

Jim,

No problems, I just knew you were one of the project founders.  I found it on 
the website shortly after posting.
My google-fu wasn’t up to par.
https://www.bufferbloat.net/projects/cerowrt/wiki/Tests_for_Bufferbloat/

I’m assuming I used the script last time for netperf, but have downloaded Flent 
to give it a shot.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
__
From: gettys...@gmail.com [mailto:gettys...@gmail.com] On Behalf Of Jim Gettys
Sent: Friday, July 22, 2016 3:23 PM
To: Eric Tykwinski
Cc: nanog list; jb; Toke Høiland-Jørgensen; Dave Taht
Subject: Re: I recommend dslreports.com/speedtest these days (was Speedtest.net 
not accessible in Chrome due to deceptive ads)

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  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 .

​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...​

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

[Jim Gettys]

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 
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 .
>
>
​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 
> wrote:
> >
> > On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" <
> nanog-boun...@nanog.org on behalf of j...@baylink.com> wrote:
> >
> >
> >
> >> - Original Message -
> >>> From: "Janusz Jezowicz" 
> >>
> >>> 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.
> >
> >
> >
> >
>
>

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

[Eric Tykwinski]

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 . 

> On Jul 21, 2016, at 6:36 PM, Donn Lasher via NANOG  wrote:
> 
> On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" 
>  wrote:
> 
> 
> 
>> - Original Message -
>>> From: "Janusz Jezowicz" 
>> 
>>> 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").
>> 
>> 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.
> 
> 
> 
> 

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

[Donn Lasher via NANOG]

On 7/21/16, 2:19 PM, "NANOG on behalf of Jay R. Ashworth" 
 wrote:



>- Original Message -
>> From: "Janusz Jezowicz" 
>
>> 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").
>
>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.

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

[Jay R. Ashworth]

- Original Message -
> From: "Janusz Jezowicz" 

> 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").

Specifically, it measures bufferbloat, with both a realtime graph and a 
letter grade -- this is, in fact, how I discovered it in the first place.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274