Speedtest Results speedtest.net vs Mikrotik bandwidth test
All: I am having some speedtest results that are difficult to interpret. I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX. I am running BGP with each with 100 Mbps+ on each link. Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results. My network is Mikrotik based and as such, I have access to Mikrotik's built-in bandwidth testing. With a laptop on site, running against speedtest.net (which kicked me over to the Comcast speedtest server instance) I can only get 4 Mbps up and 1.5 Mbps down. That is consistent on their desktops too. We eliminated their routing equipment and other consumers of the bandwidth and tested and got similar results. But when we run the Mikrotik bandwidth tests (even to off-net Mikrotik devices in Hawaii and Mission, TX) we get 25+ Mbps synchronous. We have run traceroutes to various traceroute servers and they go through Cogent and/or Level 3. For the most part it does not seem to matter which path it takes, the bandwidth seems to be about the same going both routes. When we run the laptop-based btest.exe against Mikrotik bandwidth test servers, the laptop got significantly better results (14 Mbps) , but not 25+ Mbps. It is almost like there is a Java based problem with speedtest.net. Thoughts? Thanks, Lorell Hathcock
On Mon, 1 Apr 2013, Lorell Hathcock wrote:
I am having some speedtest results that are difficult to interpret.
Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results.
Take the speedtest results with a grain of salt. Once traffic leaves your network, you no longer have (much) control over how packets flow across the 'rest of the internet'. Did the customers report when the issue started? Are they seeing other performance problems (latency/jitter/packet loss)? Are you sure no internal links/routers are being saturated, even for brief periods of time? jms
Thanks for the many helpful suggestions I received offline. One thing that I was able to deduce was that one of the radios along the path had Ethernet auto negotiate turned on. I turned it off and the TCP speeds went way up. It seems that UDP was not affected by this setting while TCP was. Thanks again! Lorell -----Original Message----- From: Justin M. Streiner [mailto:streiner@cluebyfour.org] Sent: Monday, April 01, 2013 7:27 PM To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On Mon, 1 Apr 2013, Lorell Hathcock wrote:
I am having some speedtest results that are difficult to interpret.
Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results.
Take the speedtest results with a grain of salt. Once traffic leaves your network, you no longer have (much) control over how packets flow across the 'rest of the internet'. Did the customers report when the issue started? Are they seeing other performance problems (latency/jitter/packet loss)? Are you sure no internal links/routers are being saturated, even for brief periods of time? jms
You might want to consider putting up a speedtest server internal to your network. I know there is a fee but well worth it I believe. You will still need to take the results with a grain a salt but you will have the best results as well. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos@race.com / http://www.race.com -----Original Message----- From: Lorell Hathcock <lorell@hathcock.org> Date: Tuesday, April 2, 2013 12:54 PM To: "nanog@nanog.org" <nanog@nanog.org> Subject: RE: Speedtest Results speedtest.net vs Mikrotik bandwidth test Thanks for the many helpful suggestions I received offline. One thing that I was able to deduce was that one of the radios along the path had Ethernet auto negotiate turned on. I turned it off and the TCP speeds went way up. It seems that UDP was not affected by this setting while TCP was. Thanks again! Lorell -----Original Message----- From: Justin M. Streiner [mailto:streiner@cluebyfour.org] Sent: Monday, April 01, 2013 7:27 PM To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On Mon, 1 Apr 2013, Lorell Hathcock wrote:
I am having some speedtest results that are difficult to interpret.
Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results.
Take the speedtest results with a grain of salt. Once traffic leaves your network, you no longer have (much) control over how packets flow across the 'rest of the internet'. Did the customers report when the issue started? Are they seeing other performance problems (latency/jitter/packet loss)? Are you sure no internal links/routers are being saturated, even for brief periods of time? jms
On 4/2/13 2:24 PM, Carlos Alcantar wrote:
You might want to consider putting up a speedtest server internal to your network. I know there is a fee but well worth it I believe. You will still need to take the results with a grain a salt but you will have the best results as well.
The speedtest.net mini version is free. Same test methodology and brand recognition for the customers to be satisfied. Paid version if you need branding or whatever. ~Seth
On 04/02/2013 10:13 PM, Seth Mattinen wrote:
On 4/2/13 2:24 PM, Carlos Alcantar wrote:
You might want to consider putting up a speedtest server internal to your network. I know there is a fee but well worth it I believe. You will still need to take the results with a grain a salt but you will have the best results as well.
The speedtest.net mini version is free. Same test methodology and brand recognition for the customers to be satisfied. Paid version if you need branding or whatever.
~Seth
These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it. Mike-
On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it.
As far as I know, it's possible for the end-to-end reported values to be lower than your immediate upstream due to issues further upstream. But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able to go *at least* that fast. (If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
We host one of the gazillion speed test sites and for networks that are close to us we find it "reasonably accurate" .. a good benchmark at least .. Even our installers in the field use it as a "reference point".... YMMV obviously.... Paul -----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: April-03-13 5:48 PM To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it.
As far as I know, it's possible for the end-to-end reported values to be lower than your immediate upstream due to issues further upstream. But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able to go *at least* that fast. (If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
On 4/3/13 2:52 PM, Paul Stewart wrote:
We host one of the gazillion speed test sites and for networks that are close to us we find it "reasonably accurate" .. a good benchmark at least ..
The speedtest.net that's hosted on one of my directly connected transits is consistently wrong, which is always fun. But the customers cling to those results like it's the word of God. ~Seth
I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are the root of most complaints. Your link is congested (oversubed) and you then attempt to completely saturate your bandwidth to tell your provider what a suck job they are doing. I can't imagine wireless isps or those with limited bandwidth haven't black holed those kind of performance tools. My world (satellite) is plagued by people who are speed testing very narrow band connections and expecting 15mbps down. They don't realize Speedtest is not an accurate representation of your connection as you cannot influence your bandwidth upstream. Ds3 from you to your 56k modem type of scenario comes to mind. It may *not* be your provider who is responsible for your issues (some people Speedtest just to call their provider to complain for service credits etc). Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Seth Mattinen <sethm@rollernet.us> Date: 04/03/2013 6:13 PM (GMT-08:00) To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On 4/3/13 2:52 PM, Paul Stewart wrote:
We host one of the gazillion speed test sites and for networks that are close to us we find it "reasonably accurate" .. a good benchmark at least ..
The speedtest.net that's hosted on one of my directly connected transits is consistently wrong, which is always fun. But the customers cling to those results like it's the word of God. ~Seth
On 4/3/13 6:25 PM, Warren Bailey wrote:
I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are the root of most complaints. Your link is congested (oversubed) and you then attempt to completely saturate your bandwidth to tell your provider what a suck job they are doing. I can't imagine wireless isps or those with limited bandwidth haven't black holed those kind of performance tools. My world (satellite) is plagued by people who are speed testing very narrow band connections and expecting 15mbps down. They don't realize Speedtest is not an accurate representation of your connection as you cannot influence your bandwidth upstream. Ds3 from you to your 56k modem type of scenario comes to mind. It may *not* be your provider who is responsible for your issues (some people Speedtest just to call their provider to complain for service credits etc).
In my case I know the gig connection between me and that transit is nowhere near saturated and works OK, so I have to assume the server they're hosting speedtest.net on is either constantly hosed or uses a 10Base-T interface, possibly token ring. ~Seth
I guess the Speedtest servers near metro areas do probably get pretty beat up. Has anyone paid the Ookla ransom for their own public server? I'd be really curious to see what they peak at. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Seth Mattinen <sethm@rollernet.us> Date: 04/03/2013 6:36 PM (GMT-08:00) To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On 4/3/13 6:25 PM, Warren Bailey wrote:
I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are the root of most complaints. Your link is congested (oversubed) and you then attempt to completely saturate your bandwidth to tell your provider what a suck job they are doing. I can't imagine wireless isps or those with limited bandwidth haven't black holed those kind of performance tools. My world (satellite) is plagued by people who are speed testing very narrow band connections and expecting 15mbps down. They don't realize Speedtest is not an accurate representation of your connection as you cannot influence your bandwidth upstream. Ds3 from you to your 56k modem type of scenario comes to mind. It may *not* be your provider who is responsible for your issues (some people Speedtest just to call their provider to complain for service credits etc).
In my case I know the gig connection between me and that transit is nowhere near saturated and works OK, so I have to assume the server they're hosting speedtest.net on is either constantly hosed or uses a 10Base-T interface, possibly token ring. ~Seth
I have paid the ransom. Actually we pay it on a recurring basis even. ;) As for what it peaks at, good question. The infrastructure we run it on is going to be the problem at some point, although currently has not proven to be a limiting factor to the best of my knowledge. Our customers see valid results... I mean obviously it's not showing their link speed, it is showing the characteristics of their connectivity to our speed test server. We use a couple of threads on the download test and if I take results, divide by number of threads, look at the connection characteristics and do the math to estimate throughput, there is at least usable parity there. But it's really useful for our support team when a customer is complaining about some kind of bandwidth/latency issue into our cloud. We have some people in far places with 300+ms latency and 30+ms jitter, etc, trying to use interactive sessions. Oh and to be more correct, we actually have the whole Ookla Line Quality package. Very useful for us. Also, customers seem to love the whole flash animation thing. Its what web users expect these days... it's really been a great experience for everyone... no complaints on our end, aside from price, but I am always complaining about that. For those trying to just jam bits through a pipe to see if their last mile is performing, slightly less useful unless there is one at their ISP, but that is not our use case. -Carl On Wed, Apr 3, 2013 at 8:02 PM, Warren Bailey < wbailey@satelliteintelligencegroup.com> wrote:
I guess the Speedtest servers near metro areas do probably get pretty beat up. Has anyone paid the Ookla ransom for their own public server? I'd be really curious to see what they peak at.
Sent from my T-Mobile 4G LTE Device
-- *Carl Rosevear* Manager of Operations *Skytap, Inc. | The Intuitive Enterprise Cloud* crosevear@skytap.com | O: 206-588-8899 | F: 206-624-2214 Follow us: Blog <http://blog.skytap.com/> | Twitter<http://twitter.com/#!/skytap> | LinkedIn <http://www.linkedin.com/company/skytap>
On 4/3/13 6:25 PM, Warren Bailey wrote:
I'm shocked Ookla hasn't been eaten by some major ISP. Speed tests are the root of most complaints. Your link is congested (oversubed) and you then attempt to completely saturate your bandwidth to tell your provider what a suck job they are doing. I can't imagine wireless isps or those with limited bandwidth haven't black holed those kind of performance tools. My world (satellite) is plagued by people who are speed testing very narrow band connections and expecting 15mbps down. They don't realize Speedtest is not an accurate representation of your connection as you cannot influence your bandwidth upstream. Ds3 from you to your 56k modem type of scenario comes to mind. It may *not* be your provider who is responsible for your issues (some people Speedtest just to call their provider to complain for service credits etc).
Telling people to get by with even less instrumentation then they have already doesn't win you any friends. The solution to bad instruments is better instruments not breaking flow meter off the well.
Sent from my T-Mobile 4G LTE Device
-------- Original message -------- From: Seth Mattinen <sethm@rollernet.us> Date: 04/03/2013 6:13 PM (GMT-08:00) To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On 4/3/13 2:52 PM, Paul Stewart wrote:
We host one of the gazillion speed test sites and for networks that are close to us we find it "reasonably accurate" .. a good benchmark at least ..
The speedtest.net that's hosted on one of my directly connected transits is consistently wrong, which is always fun. But the customers cling to those results like it's the word of God.
~Seth
On Wed, 3 Apr 2013, joel jaeggli wrote:
Telling people to get by with even less instrumentation then they have already doesn't win you any friends. The solution to bad instruments is better instruments not breaking flow meter off the well.
I have pitched the idea in the IETF to have TCP stacks themselves report IP performance indicators (aggregate) and that a standard for this to be standardised. No takers so far. I hate test traffic, I want to know how the real traffic is doing instead. In my opinion, people are way too happy to inject a lot of "useless" test traffic. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Thu, 04 Apr 2013 06:18:34 +0200, Mikael Abrahamsson said:
I have pitched the idea in the IETF to have TCP stacks themselves report IP performance indicators (aggregate) and that a standard for this to be standardised. No takers so far.
RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED STANDARD) Looks like a taker to me. Also, see the work the Web10G group is doing for Linux: http://www.web10g.org
On Thu, 4 Apr 2013, Valdis.Kletnieks@vt.edu wrote:
RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED STANDARD)
Looks like a taker to me. Also, see the work the Web10G group is doing for Linux: http://www.web10g.org
RFC 4989 doesn't seem to officially exist. Ah, it's 4898. Yes, RFC4898 seems to contain a lot of interesting information, question is how to destill this down to something the user can understand and that is of interest for a support engineer who might be trying to diagnose the customer problem. I agree web10g seems to be of interest as well. I'm going to read through their documents tomorrow. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Thu, 04 Apr 2013 17:29:40 +0200, Mikael Abrahamsson said:
On Thu, 4 Apr 2013, Valdis.Kletnieks@vt.edu wrote:
RFC4989 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT=153768 bytes) (Status: PROPOSED STANDARD)
Looks like a taker to me. Also, see the work the Web10G group is doing for Linux: http://www.web10g.org
RFC 4989 doesn't seem to officially exist. Ah, it's 4898.
Bargh. How did I get a typo in there? :)
Yes, RFC4898 seems to contain a lot of interesting information, question is how to destill this down to something the user can understand and that is of interest for a support engineer who might be trying to diagnose the customer problem.
I agree web10g seems to be of interest as well. I'm going to read through their documents tomorrow.
I recently got the web10g folks and the Linux kernel and networking folks talking to each other, it may get upstreamed in the reasonably near future. I'll make sure somebody keeps this list informed....
On Wed, Apr 03, 2013 at 05:48:00PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it.
As far as I know, it's possible for the end-to-end reported values to be lower than your immediate upstream due to issues further upstream.
But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able to go *at least* that fast.
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've had speedtest.net report above ADSL sync rate on ADSL connection. Also from my testing, speedtest.net usually under-represents upload speed on fast upload connections. And for some reason ping shows higher in chrome than in internet explorer. It also tends to underrepresent far away connections by using too small file sizes. If you use curl on the speedtest random.jpg files and grab the 4000x4000.jpg it'll give a more representive test of download speed. Ben.
On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net give results significantly greater than the physical bw of the client's network link. Nick
Try it with upwards of 900ms of variable latency. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Nick Hilliard <nick@foobar.org> Date: 04/03/2013 3:04 PM (GMT-08:00) To: Valdis.Kletnieks@vt.edu Cc: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net give results significantly greater than the physical bw of the client's network link. Nick
On 3 Apr 2013, at 23:20, Warren Bailey <wbailey@satelliteintelligencegroup.com> wrote:
Try it with upwards of 900ms of variable latency.
The last crazy result I got was 146mbit/s on a hardwired 100 mbit link and 1-2ms latency to the speedtest.net server I was using at the time (same data centre). Testing this sort of thing with high latency and jitter is understandably hard, but I didn't see a good reason at the time why it should have been so badly out with good underlying network characteristics. Nick
Sent from my T-Mobile 4G LTE Device
-------- Original message -------- From: Nick Hilliard <nick@foobar.org> Date: 04/03/2013 3:04 PM (GMT-08:00) To: Valdis.Kletnieks@vt.edu Cc: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
Nick
They may do some magic with bandwidth delay products.. If that was the case, they may have written it for a standard latency versus something that is unreasonable by interweb standards. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Nick Hilliard <nick@foobar.org> Date: 04/03/2013 3:35 PM (GMT-08:00) To: Warren Bailey <wbailey@satelliteintelligencegroup.com> Cc: Valdis.Kletnieks@vt.edu,nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test On 3 Apr 2013, at 23:20, Warren Bailey <wbailey@satelliteintelligencegroup.com<mailto:wbailey@satelliteintelligencegroup.com>> wrote: Try it with upwards of 900ms of variable latency. The last crazy result I got was 146mbit/s on a hardwired 100 mbit link and 1-2ms latency to the speedtest.net<http://speedtest.net> server I was using at the time (same data centre). Testing this sort of thing with high latency and jitter is understandably hard, but I didn't see a good reason at the time why it should have been so badly out with good underlying network characteristics. Nick Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Nick Hilliard <nick@foobar.org<mailto:nick@foobar.org>> Date: 04/03/2013 3:04 PM (GMT-08:00) To: Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Subject: Re: Speedtest Results speedtest.net<http://speedtest.net> vs Mikrotik bandwidth test On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu<mailto:Valdis.Kletnieks@vt.edu> wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net<http://speedtest.net> give results significantly greater than the physical bw of the client's network link. Nick
On 3 Apr 2013, at 23:41, Warren Bailey <wbailey@satelliteintelligencegroup.com> wrote:
They may do some magic with bandwidth delay products.. If that was the case, they may have written it for a standard latency versus something that is unreasonable by interweb standards.
I don't know how they calculate bandwidth, but I was surprised that their system gave such wrong results under what were effectively lab conditions. Nick
Sent from my T-Mobile 4G LTE Device
-------- Original message -------- From: Nick Hilliard <nick@foobar.org> Date: 04/03/2013 3:35 PM (GMT-08:00) To: Warren Bailey <wbailey@satelliteintelligencegroup.com> Cc: Valdis.Kletnieks@vt.edu,nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On 3 Apr 2013, at 23:20, Warren Bailey <wbailey@satelliteintelligencegroup.com> wrote:
Try it with upwards of 900ms of variable latency.
The last crazy result I got was 146mbit/s on a hardwired 100 mbit link and 1-2ms latency to the speedtest.net server I was using at the time (same data centre). Testing this sort of thing with high latency and jitter is understandably hard, but I didn't see a good reason at the time why it should have been so badly out with good underlying network characteristics.
Nick
Sent from my T-Mobile 4G LTE Device
-------- Original message -------- From: Nick Hilliard <nick@foobar.org> Date: 04/03/2013 3:04 PM (GMT-08:00) To: Valdis.Kletnieks@vt.edu Cc: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
Nick
On 4/3/13 3:20 PM, Warren Bailey wrote:
Try it with upwards of 900ms of variable latency. on linux
tc qdisc add dev eth0 root netem delay 900ms 150msdistribution normal and then you can slowly test the internet to your hearts content.
Sent from my T-Mobile 4G LTE Device
-------- Original message -------- From: Nick Hilliard <nick@foobar.org> Date: 04/03/2013 3:04 PM (GMT-08:00) To: Valdis.Kletnieks@vt.edu Cc: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test
On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...) I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
Nick
I can run two speedtest.net session side by side on my home network on one laptop, and over VPN to my employer's Long Island locale on a second, pointed at the same speedtest server, over the same wifi and ADSL and have the VPN connection report speeds that are (a) 50% better on VPN than not; and, (b) exceed my ADSL's hard cap by 10+ mbps. That smells a bit fishy to me, all in all. -c On 03-04-2013 18:02 , "Nick Hilliard" <nick@foobar.org> wrote:
On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
Nick
(a) may be valid. (b) is fishy (a) may be valid because it may be that your ISP has a better set of peering relationships towards your VPN server and your company's ISP has better peering relationships towards the Speedtest server than your ISP has towards the Speedtest server. I'm not saying that IS the case, but I have seen instances where such results were, in fact, perfectly legitimate for such reasons. Owen On Apr 3, 2013, at 17:20 , Chris Hindy <chindy@lwpca.net> wrote:
I can run two speedtest.net session side by side on my home network on one laptop, and over VPN to my employer's Long Island locale on a second, pointed at the same speedtest server, over the same wifi and ADSL and have the VPN connection report speeds that are (a) 50% better on VPN than not; and, (b) exceed my ADSL's hard cap by 10+ mbps. That smells a bit fishy to me, all in all.
-c
On 03-04-2013 18:02 , "Nick Hilliard" <nick@foobar.org> wrote:
On 3 Apr 2013, at 22:48, Valdis.Kletnieks@vt.edu wrote:
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
I've seen speedtest.net give results significantly greater than the physical bw of the client's network link.
Nick
On 04/03/2013 02:48 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it.
As far as I know, it's possible for the end-to-end reported values to be lower than your immediate upstream due to issues further upstream.
But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able to go *at least* that fast.
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
Yeah, I do... I've had T1 lines reported at 4.7mbps down and 2.8mbps up. These tests are hogwash. Mike-
When is speed ever ensured past someone else's edge/border ? You may pass through your upstream that fast but once you are out in the open range you are free game to all the lions, tigers & bears.., There is always going to be something eating you. Best off letting it be the Spanish queasiness from the night before than the results from speedtest.net -- Jason Hellenthal JJH448-ARIN - (2^(N-1)) On Apr 4, 2013, at 4:14, Mike <mike-nanog@tiedyenetworks.com> wrote:
On 04/03/2013 02:48 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 03 Apr 2013 14:07:48 -0700, Mike said:
These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it.
As far as I know, it's possible for the end-to-end reported values to be lower than your immediate upstream due to issues further upstream.
But if it reports 20MBbits/sec down and 5MBits/sec up, then the link is able to go *at least* that fast.
(If anybody's got evidence of it reporting more than the link is technically capable of, feel free to correct me...)
Yeah, I do... I've had T1 lines reported at 4.7mbps down and 2.8mbps up.
These tests are hogwash.
Mike-
Here's a 39-page report that might differ with your perspective: http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measureme... And another report: http://www.netforecast.com/Reports/NFR5103_comScore_ISP_Speed_Test_Accuracy.... Frank -----Original Message----- From: Mike [mailto:mike-nanog@tiedyenetworks.com] Sent: Wednesday, April 03, 2013 4:08 PM To: nanog@nanog.org Subject: Re: Speedtest Results speedtest.net vs Mikrotik bandwidth test <snip> These speedtests are pure unscientific bs and I'd love to see them called out on the carpet for it. Mike-
The MT speed test is a multi-connection test, think 20 streams or connections at once. Most web based tests are single stream. Now you get into 802.11N speedtests where they are optimized for many connections MIMO operations, hence, a single connection don't show good results, where a MT test at 20 streams would. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace -----Original Message----- From: Lorell Hathcock [mailto:lorell@hathcock.org] Sent: Monday, April 1, 2013 7:19 PM To: nanog@nanog.org Cc: Nathan Hathcock Subject: Speedtest Results speedtest.net vs Mikrotik bandwidth test All: I am having some speedtest results that are difficult to interpret. I am a small WISP multi-homed with Cogent and Level 3 in Houston, TX. I am running BGP with each with 100 Mbps+ on each link. Some of my customers have begun complaining that they are not getting the proper speeds. They are using speedtest.net and/or speakeasy.net to test the results. My network is Mikrotik based and as such, I have access to Mikrotik's built-in bandwidth testing. With a laptop on site, running against speedtest.net (which kicked me over to the Comcast speedtest server instance) I can only get 4 Mbps up and 1.5 Mbps down. That is consistent on their desktops too. We eliminated their routing equipment and other consumers of the bandwidth and tested and got similar results. But when we run the Mikrotik bandwidth tests (even to off-net Mikrotik devices in Hawaii and Mission, TX) we get 25+ Mbps synchronous. We have run traceroutes to various traceroute servers and they go through Cogent and/or Level 3. For the most part it does not seem to matter which path it takes, the bandwidth seems to be about the same going both routes. When we run the laptop-based btest.exe against Mikrotik bandwidth test servers, the laptop got significantly better results (14 Mbps) , but not 25+ Mbps. It is almost like there is a Java based problem with speedtest.net. Thoughts? Thanks, Lorell Hathcock
participants (18)
-
Ben Aitchison -
Carl Rosevear -
Carlos Alcantar -
Chris Hindy -
Dennis Burgess -
Frank Bulk -
Jason Hellenthal -
joel jaeggli -
Justin M. Streiner -
Lorell Hathcock -
Mikael Abrahamsson -
Mike -
Nick Hilliard -
Owen DeLong -
Paul Stewart -
Seth Mattinen -
Valdis.Kletnieks＠vt.edu -
Warren Bailey