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: Speedtest.net not accessible in Chrome due to deceptive ads

[Jacques Latour]

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-boun...@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" boun...@nanog.org on behalf of col...@averysmallbird.com> wrote:
>
>On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin 
>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.
>
>

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Livingood, Jason]

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

On 7/20/16, 11:42 PM, "NANOG on behalf of Collin Anderson" 
 wrote:

On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin 
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.

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

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Collin Anderson]

On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin 
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.

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Antonio Querubin]

On Wed, 20 Jul 2016, Collin Anderson wrote:


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.


Feedback:  needs IPv6 connectivity and support.

Antonio Querubin
e-mail:  t...@lavanauts.org
xmpp:  antonioqueru...@gmail.com

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Collin Anderson]

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  wrote:

> http://www.measurementlab.net/tools/ndt/
>
> 100% ad free.
>
> On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz 
> 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,  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
> > >
> >
>



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

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Rubens Kuhl]

On Wed, Jul 20, 2016 at 3:56 PM, David  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.
>

Working with Safari might require Java which is also not a popular choice
among security conscious users... ... http://simet.nic.br requires either
Chrome or a Java-enabled browser.


Rubens

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Jacques Latour]

Yup, websocket implementations across all browsers not equal

On 2016-07-20, 2:56 PM, "NANOG on behalf of David"
 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.

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[David]

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.

RE: Speedtest.net not accessible in Chrome due to deceptive ads

[Jacques Latour]

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-boun...@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 
>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,  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
>> >
>>

RE: Speedtest.net not accessible in Chrome due to deceptive ads

[Robert Jacobs]

It is back for us in Houston via NTT and Level 3 ... no warnings when you got 
to site... 

Robert Jacobs | Network Director/Architect 

Direct:  832-615-7742
Main:   832-615-8000
Fax:    713-510-1650

5959 Corporate Dr. Suite 3300; Houston, TX 77036



A Certified Woman-Owned Business 

24x7x365 Customer  Support: 832-615-8000 | supp...@pslightwave.com
This electronic message contains information from Phonoscope Lightwave which 
may be privileged and confidential. The information is intended to be for the 
use of individual(s) or entity named above. If you are not the intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information is prohibited. If you have received this electronic message in 
error, please notify me by telephone or e-mail immediately.



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ishmael Rufus
Sent: Wednesday, July 20, 2016 9: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 
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,  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
> >
>

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Ishmael Rufus]

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

100% ad free.

On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz 
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,  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
> >
>

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Janusz Jezowicz]

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

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[A . L . M . Buxey]

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 

Speedtest.net not accessible in Chrome due to deceptive ads

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

e.g. Netflix at http://fast.com

Regards,

Janusz Jezowicz
*Speedchecker Ltd*
*email*: jan...@speedchecker.xyz
*skype*: jezowicz
*phone*: +442032863573
*web*: www.speedchecker.xyz
The Black Church, St. Mary’s Place, Dublin 7, D07 P4AX, Ireland