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 unl

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