I was on the phone with a buddy trying to troubleshoot Local file transfer speeds vs Speedtest results.
Speedtest kept reporting 100Mb/s range speeds (the tier he was paying for). Local file transfers however were stuck in the 1MB/s range.
After some questions and troubleshooting he discovered that he had used a 10Mb/s hub instead of a 1Gb/s switch that was sitting right next to it. A simple mixup.
His internet connection was also plugged into that same 10Mb/s hub.
There is NO WAY his PC could have reported 100Mb/s to speedtest.
Do not trust them for accurate results.
> Do not trust them for accurate results.
Ookla speedtest properly transfers data and divides to find throughput-- both with the website, the GUI app, and their CLI program. The open source speedtest-cli that uses their infrastructure is hampered by only one connection and can't seem to ever report higher than 300mbps.
Fast.com is ... a little optimistic about transients getting transfers started and sometimes reports numbers 5-10% too high.
Neither is grossly wrong by an order of magnitude. Maybe there was also wifi around and simultaneously connected, confounding the situation? Easy to end up in a situation where all your internet traffic is going over wifi (because e.g. your dhcp client replaces the default route with one going over the wifi interface), and all your local traffic goes over ethernet.
> speedtest-cli ... can't seem to ever report higher than 300mbps.
I routinely get 700-900Mbps reported using speedtest-cli from centurylink fiber. My bottleneck is the CPU on my router running openwrt.
Can you look at this, and tell me which of the 2 you're using:
https://news.ycombinator.com/item?id=31063868
From speedtest's official cli program, on my 2.5gbase-t connected machine I get 2200mbps up and down.. but from the open source speedtest-cli I get 300-350mbps.
(Here, I only got ~900mbps because I was running from a raspberry pi with a 1000BaseT link).
I'm seeing gigabit(-ish) via speedtest-cli:
FTTH, Ubiquiti EdgeSwitch -> UniFi Dream Machine Pro SE via 10G link -> Nokia ONT.
I _do_ get limited to around 300mbps if my Mikrotik is in the mix and using CPU for routing.
Yeah, my home network is overkill but it's a cheaper hobby than other ones might be, hah.
> I'm seeing gigabit(-ish) via speedtest-cli:
You're using their cli client, not the open source one. Below, first their "speedtest" and then the open source "speedtest-cli"
vs.
speedtest-cli is a python program, vs. the native speedtest:
Practically the same. Perhaps it's a server selection issue?
Interesting. I consistently get garbage results with speedtest-cli (across multiple machines and network connections) and good results with speedtest's own.
On the pi, I suspect it's running out of CPU--
But that doesn't explain the systemic problem.
The Pi is definitely limited in terms of CPU. This is a fairly old, but beefy Xeon chip on my unraid box. Might be native vs Python code on ARM?
Yup, native vs. Python would explain a lot on the Pi, but I've also seen this on my big Threadripper machine here and on my Hetzner server in Virginia.
I'd assumed it was just something intrinsic.
On the other hand: speedtest's own thing uses multiple parallel connections. So if you have low amounts of loss that prevent one TCP connection from going super fast, it'll do better on speedtest than speedtest-cli.
Thanks for the help/info. Something to spend more time understanding at some point in the future.
edit: Just noticed that the Hetzner server in VA geolocates wrong and chooses servers in Kansas.
No worries.. best of luck with that. As a total aside, fast.com is giving me 420mbps which should be impossible given my wifi setup. :/
fast.com tends to be 10-20% high for me versus what goes by at the router.
> edit: Just noticed that the Hetzner server in VA geolocates wrong and chooses servers in Kansas.
This is a common failure mode of geolocation, especially as it pertains to cloud providers. The databases can guess which country the IP address corresponds to, but not anything more (and as such, they default to something in the middle of the country).
https://en.wikipedia.org/wiki/Geographic_center_of_the_Unite...
Geolocation data tends to be worse for cloud providers for whatever reason (I believe it's a combination of differing Internet footprint characteristics, as well as IP aggregation mismatch on behalf of the geolocation database).
(Also see https://en.wikipedia.org/wiki/Null_Island for another common geolocation placeholder)
Ha! I'm currently down the rabbithole of trying to understand why when connected through nordvpn, i'm seeing ~5% faster download and ~10% lower ping latency to speedtest.net when connected to an in-country vpn endpoint.
Does not compute. Compression? I can't explain the lower ping, traffic shaping?
> I can't explain the lower ping, traffic shaping?
Better routes. Most latency on the internet is not due to c.
C being speed of light
Classic story where this is related: https://www.ibiblio.org/harris/500milemail.html
tl;dr timeout was sufficiently low and user sufficiently skilled to work out his emails could be delivered only within 500 miles
My favourite aspect of this story is how the academics, being academics, took it upon themselves to characterise the problem in detail before telling the postmaster about it. Could just as easily have said "huh, that's weird" and thrown it at them on day one.
And their explanation was probably more baffling to the admin than a simple "it is broken" report too. It would definitely have been for me.
I get this same with AWS. The routes to my country in Northern Europe from us-* are terrible (eu-* is fine), to the point where a download from S3 during peak times can be tens of kB/s. If I connect to a VPN in another country it jumps to tens of MB/s.
When I use a VPN the measurable ping might go down but the noticeable ping goes up. There's always a barely-perceptible delay when doings things like using voice typing.
Some providers provide speedtests that test (only) last-mile speed between, e.g., cable modem and head unit. Mine does that and reports 1Gb/s just fine. Of course, only to the head unit, nowhere else in the universe.
speedtest.net has a CLI version that is much more reliable than the web version.
Edit: removed due to downvoting. Original comment pointed out that transfer speed is normally measured in Mbps not MB/s.
Can't get 100 Megabits on a 10 Megabit line was the point.
> Speedtest kept reporting 100Mb/s range speeds (the tier he was paying for). Local file transfers however were stuck in the 1MB/s range
I read that speed test reported 100Mb/s and local files were receiving 8Mb/s (1MB/s). Either interpretation doesn’t change the intent much. But now I’m curious if the MB was intentional.
I don’t really care what the normal convention is, but the fact that Mbps and MB/s are sometimes used interchangeably does cause confusion, especially outside this environment.
Was the choice to use Mbps as a standard a marketing idea? Like they have 1 MB/s? Well we have 8 Mb/s.
Yes I did intentionally mix the units up. I know it's not best practice but I also know that most people that frequent this site are aware enough of the differences to not get fooled/confused. To be honest it was just lazy writing on my part.