I like that instead of listing maximum speeds (which is always provided with a disclaimer) the provider is listing typical speeds, which should give the consumer a more general sense of what to expect.
I don’t love the “read our policy” lines, as it just continues the practice of hiding behind the complexity of legalese.
This is good, but is mostly useful in a place where you have enough competition to compare providers. Otherwise it’s just a simplified listing of how terrible your limited options are.
I think that we should be careful about "gamed" speed tests, like Ookla. I've learned that I should ignore whatever Ookla says, as the ISP optimizes for it.
I've heard that the Google tests are pretty good, and I also just learned that fast.com is good, because it sits on Netflix's IP range, and ISPs can't game it, without also letting Netflix have full throttle.
Netflix tests usually go to the Netflix cache at your ISP's nearest POP. Usually I find the Netflix speeds at close to max speed for my connection as I'm in the same city as my ISP's Netflix cache. However other test sites show more realistic speeds to sites in other networks. Ookla/Speedtest gives you the option to select offshore servers which helps to identify issues with ISPs underprovionsing off shore bandwidth. I've had ISPs with excellent on net speeds but poor off net speeds so I'm generally more interested in off net speeds.
But we have nothing to do with offnet speeds. I am fine with people looking at them but there isnt anything I can do to help them if they have bad speeds to random offnet networks.
You absolutely do. Who are you paying for peering, who are you paying for transit, what's your interconnect with them, and, well, how much are you paying them? Which IX are you in?
You might not be able to do anything about it as a tier-3 ISP, but to say you have nothing to do with off-net speeds glosses over a few details.
The speed tests can also tell a different story than actual use, even if they are not gamed. I went a bit deep when my HTTPS/TCP downloads from my otherwise unloaded server and previously beefy CDNs were not reaching anywhere close to what they should. I could get full speed with multiple downloads in parallel. speedtest.net and other sites showed everything was fine. I could also hit the speeds via iperf UDP tests in both directions, but iperf TCP download (to my home) showed the same slow speed.
The issue was a very low packet loss which does not really concern UDP or quick/small TCP transfers, but screws up big TCP (multi GB) transfers as TCP of course assumes congestion and throttles back. I could see some TCP retransmissions and DUP ACKs which confirmed that guess. I assume the speedtests used either not-TCP (WebRTC?) or multiple connections, so they were papering over the issue. One could also argue they did their job and stated the raw (IP-)capacity of the connection, without worrying about details of a specific protocol (TCP in this case).
I think fast.com is the right answer for some cases, because it is as close as you can get to "real" loads, if your intended use case is video streaming from Netflix.
(Sidenote: my issue magically resolved itself a few weeks later, before I could be bothered to haunt my ISP.)
Then what? The best thing I can get is Comcast with 1.2G down and 40mbit up. They don't have much pressure to do better, and because they have a very direct profit motive to make torrenting as bad as possible because they own a large stake in Hulu and content companies, they're not likely to change.
I don’t love the “read our policy” lines, as it just continues the practice of hiding behind the complexity of legalese.
This is good, but is mostly useful in a place where you have enough competition to compare providers. Otherwise it’s just a simplified listing of how terrible your limited options are.