> 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"
mlyle@brazen:~ $ ./speedtest
Speedtest by Ookla
Server: Cloudflare - San Jose, CA (id = 44932)
ISP: Frontier Communications
Latency: 12.10 ms (1.29 ms jitter)
Download: 953.32 Mbps (data used: 1.0 GB )
Upload: 891.89 Mbps (data used: 1.1 GB )
Packet Loss: Not available.
vs.
mlyle@brazen:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Frontier Communications (47.155.215.132)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Nitel (Los Angeles, CA) [446.50 km]: 49.103 ms
Testing download speed................................................................................
Download: 323.09 Mbit/s
Upload: 300.49 Mbit/s
speedtest-cli is a python program, vs. the native speedtest:
mlyle@brazen:~ $ file /home/mlyle/.local/bin/speedtest-cli
/home/mlyle/.local/bin/speedtest-cli: Python script, ASCII text executable
mlyle@brazen:~ $ file speedtest
speedtest: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
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)