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