[SOLVED] Speedtest-cli vs Iperf3 results differ markedly

[devNull]

Recently upgraded to Bookworm (running headless), and all seemed fine. Yesterday I ran speedtest-cli, and the download results are 30Mbps (other devices report 300Mbps).

When I run Iperf3, all looks fine at 940Mbps.

I reinstalled speedtest-cli after remove/purge, but its result is the same.

So I am puzzled. Is there an alternate test for internet download that can clear this up.

I'm a bit of a noobie so please be easy on me. Thanks for your help!

[Aki]

Hello,

Recently upgraded to Bookworm (running headless), and all seemed fine. Yesterday I ran speedtest-cli, and the download results are 30Mbps (other devices report 300Mbps).

You need to use the same benchmark and the same connection type (wired or wireless) on all devices to compare the results.

When I run Iperf3, all looks fine at 940Mbps.

As reported before, you need to use the same benchmark to compare results.

So I am puzzled. Is there an alternate test for internet download that can clear this up.

I would suggest to focus on the type of measurement you want to achieve. Are you interested in the download speed of your internet service provider or something else ?

[devNull]

You need to use the same benchmark and the same connection type (wired or wireless) on all devices to compare the results.

Agree. I ran speedtest-cli also on a Raspberry Pi running Bookworm, and it yielded 300Mbps

When I run Iperf3, all looks fine at 940Mbps.

As reported before, you need to use the same benchmark to compare results.

Iperf3 was run across all network devices, and all consistently showed "full" bandwidth (~940Mkps). To me, this infers all cables are working to the limit of the network cards within the LAN.

So I am puzzled. Is there an alternate test for internet download that can clear this up.

I would suggest to focus on the type of measurement you want to achieve. Are you interested in the download speed of your internet service provider or something else ?

With all other devices reporting 10x the download rate of the Debian NUC (including cable switching), My concern is that I am somehow rate limited, when pulling down files, isos etc. This suggests something isn't properly set. Thank you for your reply.

[Aki]

Hello,

With all other devices reporting 10x the download rate of the Debian NUC (including cable switching), My concern is that I am somehow rate limited, when pulling down files, isos etc. This suggests something isn't properly set. Thank you for your reply.

If this difference is consistent with the same benchmark using the same hardware connection on different computers, you can check the network configuration of your NUC hardware.

For example, you can start checking the network speed negotiated by your NUC's network adapter with your modem/router by using the ethtool command.

Then, you can compare it to:

• the declared download speed of your internet provider

• the local network speed of your internet modem/router/switch declared by manufacturer

[devNull]

If this difference is consistent with the same benchmark using the same hardware connection on different computers, you can check the network configuration of your NUC hardware.

For example, you can start checking the network speed negotiated by your NUC's network adapter with your modem/router by using the ethtool command.

Then, you can compare it to:

• the declared download speed of your internet provider

• the local network speed of your internet modem/router/switch declared by manufacturer

Thank you. Here's what I have found:

Code: Select all

sudo ethtool enp89s0 | grep Speed
Speed: 1000Mb/s

sudo ethtool enp89s0
Settings for enp89s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

cat /sys/class/net/enp89s0/speed
1000

This is consistent with my modem/router/switch spec, and 3x what my ISP provides.

FWIW, some time ago (maybe a year) when I first installed and ran speedtest-cli (on Bullseye at that time), the speedtest showed the expected download value from my ISP (typically 330Mbps download), as opposed to day's 30-50Mbps. This still puzzles me.

[Aki]

Hello,

What is the result of the test using the online version of speedtest ? You can find it at the following URL:

• https://www.speedtest.net

Note the remark from the package's home page at:

• https://packages.debian.org/bookworm/speedtest-cli

  This utility allows you to use the Speedtest.net service from the command line.
  
  Note: This tool accesses speedtest.net over http, while the web-based client uses websockets. This tool has shown to become increasingly inacurate with high-speed connections. For more information, see the readme on: https://github.com/sivel/speedtest-cli

[Aki]

Hello @devNull,
Have you made any progress ?

[devNull]

Sorry for the late reply. I've determined that executable is somewhat broken. I've since switched to Speedtest-Tracker (docker container) and the results are in line with expectations.

[Aki]

Hello,

Sorry for the late reply. I've determined that executable is somewhat broken. I've since switched to Speedtest-Tracker (docker container) and the results are in line with expectations.

Thank you for your feedback.

Please, mark the discussion as "solved" manually adding the text tag "[Solved]" at the beginning of the subject of the first message.