speedtest-cli icon indicating copy to clipboard operation
speedtest-cli copied to clipboard

CLI results 2x higher RTT

Open metalefty opened this issue 5 years ago • 8 comments

Hi,

I've noticed that CLI result 2x higher RTT than web speed test.

Here's my web speed test result: https://librespeed.org/results/?id=17vfzh3

librespeedresult

I performed a speed test using cli, strangely, it shows 2x higher RTT than web test.

% librespeed-cli --server 6
Retrieving LibreSpeed.org server list
Selected server: Nuremberg, Germany (1) (Hetzner) [de1.backend.librespeed.org]
Sponsored by: Snopyta @ https://snopyta.org
You're testing from: 2405:6586:2280:1200::dead:beef - Asahi Net, JP (9080 km)
Ping: 535 ms    Jitter: 0 ms
Download rate:  5.82 Mbps
Upload rate:    2.22 Mbps

I also measured RTT using ping, the result is same as the web test.

% ping6 de1.backend.librespeed.org
PING6(56=40+8+8 bytes) 2405:6586:2280:1200::dead:beef --> 2a01:4f8:1c1c:93d6::1
16 bytes from 2a01:4f8:1c1c:93d6::1, icmp_seq=0 hlim=35 time=268.486 ms
16 bytes from 2a01:4f8:1c1c:93d6::1, icmp_seq=1 hlim=35 time=266.626 ms
16 bytes from 2a01:4f8:1c1c:93d6::1, icmp_seq=2 hlim=35 time=264.742 ms
16 bytes from 2a01:4f8:1c1c:93d6::1, icmp_seq=3 hlim=35 time=264.809 ms

I haven't dig up the code but I guess you forgot to divide some value by 2.

Best Regards,

metalefty avatar Jun 23 '20 02:06 metalefty

Thanks for your report.

The ping RTT avg. shouldn't need to divide by 2, and this is the first time I've seen this issue, so I have some doubts about this problem, would you please:

  1. Ping the server via IPv4 and see the ping times
  2. Check lsof or the likes to see if the CLI is indeed making requests via IPv6

Thanks!

maddie avatar Jun 23 '20 03:06 maddie

Hi,

I forgot to mention the client version. I'm using v1.0.6. The RTT is exactly 2x than the actual value so I guess something's miscalculated.

Same result with IPv4 and I confirmed the CLI is making IPv6 requests using wireshark.

% librespeed-cli --server 6 -4
Retrieving LibreSpeed.org server list
Selected server: Nuremberg, Germany (1) (Hetzner) [de1.backend.librespeed.org]
Sponsored by: Snopyta @ https://snopyta.org
You're testing from: 131.129.*.* - Asahi Net, JP (9070 km)
Ping: 539 ms    Jitter: 0 ms
Download rate:  4.85 Mbps
Upload rate:    2.54 Mbps
% ping de1.backend.librespeed.org
PING de1.backend.librespeed.snopyta.org (195.201.88.76): 56 data bytes
64 bytes from 195.201.88.76: icmp_seq=0 ttl=43 time=276.318 ms
64 bytes from 195.201.88.76: icmp_seq=1 ttl=43 time=271.564 ms
64 bytes from 195.201.88.76: icmp_seq=2 ttl=43 time=268.954 ms
64 bytes from 195.201.88.76: icmp_seq=3 ttl=43 time=274.501 ms
64 bytes from 195.201.88.76: icmp_seq=4 ttl=43 time=275.595 ms

metalefty avatar Jun 23 '20 03:06 metalefty

I performed further tests with the server near to me, I still have around 2x results.

IPv4

% librespeed-cli --server-json http://w.vmeta.jp/temp/inonius.json --server 0 -4
Retrieving LibreSpeed.org server list
Selected server: IPv4 inonius [ipv4.inonius.net]
You're testing from: 131.129.* * - Asahi Net, JP (880 km)
Ping: 56 ms     Jitter: 1 ms
Download rate:  82.99 Mbps
Upload rate:    86.94 Mbps
% ping ipv4.inonius.net
PING ipv4.inonius.net (210.231.212.23): 56 data bytes
64 bytes from 210.231.212.23: icmp_seq=0 ttl=49 time=22.148 ms
64 bytes from 210.231.212.23: icmp_seq=1 ttl=49 time=21.424 ms
64 bytes from 210.231.212.23: icmp_seq=2 ttl=49 time=21.553 ms

IPv6

% librespeed-cli --server-json http://w.vmeta.jp/temp/inonius.json --server 1 -6
Retrieving LibreSpeed.org server list
Selected server: IPv6 inonius [ipv6.inonius.net]
You're testing from: 2405:6586:2280:1200::dead:beef - Asahi Net, JP (860 km)
Ping: 45 ms     Jitter: 0 ms
Download rate:  90.51 Mbps
Upload rate:    87.96 Mbps
% ping6 ipv6.inonius.net
PING6(56=40+8+8 bytes) 2405:6586:2280:1200::dead:beef --> 2405:f000:202:2598::23
16 bytes from 2405:f000:202:2598::23, icmp_seq=0 hlim=47 time=23.105 ms
16 bytes from 2405:f000:202:2598::23, icmp_seq=1 hlim=47 time=26.648 ms
16 bytes from 2405:f000:202:2598::23, icmp_seq=2 hlim=47 time=25.591 ms
16 bytes from 2405:f000:202:2598::23, icmp_seq=3 hlim=47 time=28.247 ms
16 bytes from 2405:f000:202:2598::23, icmp_seq=4 hlim=47 time=25.655 ms

metalefty avatar Jun 23 '20 03:06 metalefty

I can't reproduce this issue, what system are you running on?

Here's my result:

$ librespeed-cli
Retrieving LibreSpeed.org server list
Selecting the fastest server based on ping
Selected server: Strasbourg, France (Host Europe) [sxb.bandspeed.de]
You're testing from: redacted
Ping: 194 ms	Jitter: 1 ms
Download rate:	26.34 Mbps
Upload rate:	7.97 Mbps
$ ping sxb.bandspeed.de
PING sxb.bandspeed.de (62.75.137.44): 56 data bytes
64 bytes from 62.75.137.44: icmp_seq=0 ttl=46 time=191.868 ms
64 bytes from 62.75.137.44: icmp_seq=1 ttl=46 time=192.739 ms
64 bytes from 62.75.137.44: icmp_seq=2 ttl=46 time=253.609 ms
64 bytes from 62.75.137.44: icmp_seq=3 ttl=46 time=196.641 ms
64 bytes from 62.75.137.44: icmp_seq=4 ttl=47 time=192.959 ms
64 bytes from 62.75.137.44: icmp_seq=5 ttl=46 time=192.934 ms
64 bytes from 62.75.137.44: icmp_seq=6 ttl=46 time=193.358 ms
^C
--- sxb.bandspeed.de ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 191.868/202.015/253.609/21.109 ms

maddie avatar Jun 29 '20 03:06 maddie

On FreeBSD, it 100% reproduces. I will also test it on Linux later.

metalefty avatar Jun 29 '20 05:06 metalefty

Any feedback? If not, I'll close this issue due to inactivity later.

maddie avatar Sep 01 '20 08:09 maddie

I haven't figure out the root cause of this issue but the issue is 100% reproducible. Please don't close the issue about existing bug.

metalefty avatar Sep 01 '20 14:09 metalefty

I have also experienced for high speeds (Gbit ethernet) to a self-hosted server, the throughput on cli is approximately half of what it shows on the web FE version. I would assume this is linked?

natzlob avatar Aug 30 '21 12:08 natzlob