http://www.measurementlab.net/tools/ndt/ 100% ad free. On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz@speedchecker.xyz> wrote:

It seems that some users reporting the site is back. I am counting 6+ hours of outage.

Alan - what you describe is something normal user will never do. When user sees red screen like that, he runs screaming. So in theory yes, it was accessible, but ... wasn't.

Its hard to avoid Google nanny when they offer so many useful services

On 20 July 2016 at 14:09, <A.L.M.Buxey@lboro.ac.uk> wrote:

...

Hi,

...

Since this morning Speedtest.net is not accessible in Chrome Reason:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.spe...

...

someones complained about the URL based on them stupidly installing 'cleanmymac' or such?

use the non flash junk HTML5 version instead

http://beta.speedtest.net/

still bleats about "Deceptive site ahead"

and PS "is not accessible in Chrome" - not true.

click DETAILS, then click on

visit this unsafe site.

(with the pre-condition of " if you understand the risks to your

security"

...

I personally dont want or need Google to start being my nanny on the internet :/

alan

PS you may have other interests involved here given your affiliation to speedchecker.xyz

In that case, for Canadians, go to http://performance.cira.ca, it's MLAB-NDT based and checks IPv6 and DNSSEC :-) 100% ad free

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ishmael Rufus Sent: July-20-16 10:33 AM To: Janusz Jezowicz Cc: NANOG list Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads

http://www.measurementlab.net/tools/ndt/

100% ad free.

On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz@speedchecker.xyz> wrote:

...

It seems that some users reporting the site is back. I am counting 6+ hours of outage.

Alan - what you describe is something normal user will never do. When user sees red screen like that, he runs screaming. So in theory yes, it was accessible, but ... wasn't.

Its hard to avoid Google nanny when they offer so many useful services

On 20 July 2016 at 14:09, <A.L.M.Buxey@lboro.ac.uk> wrote:

...

Hi,

...

Since this morning Speedtest.net is not accessible in Chrome Reason:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url =c.speedtest.net

...

someones complained about the URL based on them stupidly installing 'cleanmymac' or such?

use the non flash junk HTML5 version instead

http://beta.speedtest.net/

still bleats about "Deceptive site ahead"

and PS "is not accessible in Chrome" - not true.

click DETAILS, then click on

visit this unsafe site.

(with the pre-condition of " if you understand the risks to your

security"

...

I personally dont want or need Google to start being my nanny on the internet :/

alan

PS you may have other interests involved here given your affiliation to speedchecker.xyz

Yup, websocket implementations across all browsers not equal On 2016-07-20, 2:56 PM, "NANOG on behalf of David" <nanog-bounces@nanog.org on behalf of opendak@shaw.ca> wrote:

On 2016-07-20 12:52 PM, Jacques Latour wrote:

...

In that case, for Canadians, go to http://performance.cira.ca, it's MLAB-NDT based and checks IPv6 and DNSSEC :-)

100% ad free

And on the flip side, refuses to work with Safari.

Thanks for the mention – for what it's worth, we are testing a more accessible interface for the web-based NDT test. Link: https://speed.measurementlab.net/#/ Definitely interested in feedback from the NANOG community. On Wed, Jul 20, 2016 at 10:32 AM, Ishmael Rufus <sakamura@gmail.com> wrote:

http://www.measurementlab.net/tools/ndt/

100% ad free.

On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz <janusz@speedchecker.xyz> wrote:

...

It seems that some users reporting the site is back. I am counting 6+ hours of outage.

Alan - what you describe is something normal user will never do. When user sees red screen like that, he runs screaming. So in theory yes, it was accessible, but ... wasn't.

Its hard to avoid Google nanny when they offer so many useful services

On 20 July 2016 at 14:09, <A.L.M.Buxey@lboro.ac.uk> wrote:

...

Hi,

...

Since this morning Speedtest.net is not accessible in Chrome Reason:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url=c.spe...

...

...

someones complained about the URL based on them stupidly installing 'cleanmymac' or such?

use the non flash junk HTML5 version instead

http://beta.speedtest.net/

still bleats about "Deceptive site ahead"

and PS "is not accessible in Chrome" - not true.

click DETAILS, then click on

visit this unsafe site.

(with the pre-condition of " if you understand the risks to your

security"

...

I personally dont want or need Google to start being my nanny on the internet :/

alan

PS you may have other interests involved here given your affiliation to speedchecker.xyz

-- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C.

On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin <tony@lavanauts.org> wrote:

Feedback: needs IPv6 connectivity and support.

Point well taken. The vast majority of M-Lab sites have IPv6 connectivity, and we have enabled it for NDT at times, but I believe there was a concern at one point about an issue with error handling on the IPv6 side that lead to it being disabled temporarily. We will follow through on this. -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C.

Good point, we would need a piece of websocket code to run before or after NDT that figures out MAX speed so end users we can compare with other speed tests. NDT is about the quality of a connection, not absolute maximum quantity that can be jammed on a link irrespective of errors and all.

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Livingood, Jason Sent: July-22-16 8:33 AM To: Collin Anderson; Antonio Querubin Cc: NANOG list Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads

And work on accurate measurement of higher link speeds. ;-)

On 7/20/16, 11:42 PM, "NANOG on behalf of Collin Anderson" <nanog- bounces@nanog.org on behalf of collin@averysmallbird.com> wrote:

On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin <tony@lavanauts.org> wrote:

...

Feedback: needs IPv6 connectivity and support.

Point well taken. The vast majority of M-Lab sites have IPv6 connectivity, and we have enabled it for NDT at times, but I believe there was a concern at one point about an issue with error handling on the IPv6 side that lead to it being disabled temporarily. We will follow through on this.

-- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C.

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

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

...

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.

Den 22. jul. 2016 21.34 skrev "Jim Gettys" <jg@freedesktop.org>:

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

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.... On Fri, Jul 22, 2016 at 4:31 PM, Jim Gettys <jg@freedesktop.org> wrote:

On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl < baldur.norddahl@gmail.com> wrote:

...

Den 22. jul. 2016 21.34 skrev "Jim Gettys" <jg@freedesktop.org>:

...

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