3 ms·

Practically the same. Perhaps it's a server selection issue? Selecting best server based on ping... Hosted by iTel.com (iTel Networks Inc) (Calgary, AB) [3

Practically the same. Perhaps it's a server selection issue? Selecting best server based on ping... Hosted by iTel.com (iTel Networks Inc) (Calgary, AB) [3.20 km]: 2.275 ms Testing download speed................................................................................ Download: 931.69 Mbit/s Testing upload speed................................................................................................ Upload: 854.01 Mbit/s

mlyle 5y ago
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-- real 0m9.877s user 0m2.737s sys 0m5.595s But that doesn't explain the systemic problem.
- mmastrac 5y ago
  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?
  - mlyle 5y ago
    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.
    - mmastrac 5y ago
      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. :/
      - mlyle 5y ago
        fast.com tends to be 10-20% high for me versus what goes by at the router.
    - vitus 5y ago
      > 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_United_States#Contiguous_United_States 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 https://en.wikipedia.org/wiki/Null_Island for another common geolocation placeholder)

mlyle 5y ago

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-- real 0m9.877s user 0m2.737s sys 0m5.595s But that doesn't explain the systemic problem.

mmastrac 5y ago
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?
- mlyle 5y ago
  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.
  - mmastrac 5y ago
    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. :/
    - mlyle 5y ago
      fast.com tends to be 10-20% high for me versus what goes by at the router.
  - vitus 5y ago
    > 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_United_States#Contiguous_United_States 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 https://en.wikipedia.org/wiki/Null_Island for another common geolocation placeholder)