3 ms·

I'm seeing gigabit(-ish) via speedtest-cli: Speedtest by Ookla Server: TELUS Mobility - Calgary, AB (id = 17555) ISP: TELUS Latency: 0

I'm seeing gigabit(-ish) via speedtest-cli: Speedtest by Ookla Server: TELUS Mobility - Calgary, AB (id = 17555) ISP: TELUS Latency: 0.50 ms (0.12 ms jitter) Download: 938.58 Mbps (data used: 422.8 MB) Upload: 919.90 Mbps (data used: 959.8 MB) Packet Loss: Not available. 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.

mlyle 5y ago
> 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
- mmastrac 5y ago
  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

> 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

mmastrac 5y ago
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)