I think you may have bytes for bits on the download.

[TJ-C]

I only have a 1Gbit port and 900mbit fibre link service; however, the plot is showing much higher readings. Is it possible you are mixing up bytes with bits, as 1Gbit = 125Mbytes, which would explain the higher reading on the download, as the upload looks correct?

[wpresident]

i agree and have same, >1000mbps on 1gbps link is strange

[ansemjo]

Hey, thanks for the issue. I'm pretty sure I'm not mixing bits and bytes anywhere .. but I suspect that there is either some Megabits (1000) vs. Mebibits (1024) confusion or just plain measurement inaccuracy at this point.

(Sidenote: another issue #207 also mentioned that the Ping remains at zero. That appears to be an issue with picking a specific server at all instead of letting SpeedTest++ choose one automatically.)

---

I'm on a DSL 100 plan right now and my Fritz!Box lists the connection as 113.31 Mbit/s down and 43.04 Mbit/s up right now. When I run SpeedTest --output verbose manually, I get Download: 109.20 Mbit/s and Upload: 37.34 Mbit/s, so that seems to match more or less, though upload is notably slower just like in your example.

The taganaka/SpeedTest++ tool runs a short preflight download and selects a "profile" based on that initial speed. In your case it would probably use the "Fiber" profile: https://github.com/taganaka/SpeedTest/blob/b743996d617e63c065b8552165954dfd2b1f2918/TestConfigTemplate.h#L82, which still assumes an asynchronous connection and uses more concurrent threads and larger maximum sizes for the download.

Then SpeedTest::execute is called, once for the download measurement and once for the upload: https://github.com/taganaka/SpeedTest/blob/b743996d617e63c065b8552165954dfd2b1f2918/SpeedTest.cpp#L174
That functions spawns the number of configured threads, which try to up/download increasingly larger sizes until they either a) hit the maximum slice max_size or b) the min_test_time_ms of 20 seconds elapsed.

The individual metric is calculated from curr_size (in bytes) * 8 (for bits) divided by op_time / 1000 (which I think converts elapsed milliseconds to seconds). The metrics are averaged and summed together. Finally they are divided by 1_000_000, so the output value is definitely in the correct Mbit/s unit. The plotscript uses a factor of 1_000_000 as well to determine the ytics placement and the output format uses Gnuplot's builtin %c format specifier to add the appropriate magnitude prefix, which would be in thousands and not powers of 1024.

What bothers me about this calculation though, is that it just blindly sums up overall_speed (which is already in Mbit/s) instead of summing up the total number of bytes and using the longest time difference from start to end of the last measurement. Since the threads are not "killed" when the time limit elapses, it might happen that most download threads already break after 20 seconds and then you have a few stragglers which can suddenly download much faster with less contention. If you just blindly add up their speed, assuming they all ran concurrently in the same time interval, you could possibly get these heightened results.

---

So, yeah. I'd probably need to patch in some more debug logging or tracing in taganaka/SpeedTest++ to really see what's happening. Or I could look into switching to librespeed's alternative client, as has been suggested in another issue. As I am not really using this project myself anymore though, I can't promise any timeframes.

[ansemjo]

Could you both switch to the ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go image for testing?

That image is built from the use-speedtest-go branch I just pushed, which uses showwin/speedtest-go to take measurements. It is both quicker and seems to produce more accurate results in my local testing.

Note: if you're currently using the TESTSERVER variable with a host:port server, you'll need to switch to the server ID instead. Or leave it blank to use automatic selection for now ...

[TJ-C]

Thanks for looking into this and updating, however I am now experiencing less speed than when I run a speedtest, here are my results:

running using the original image:
/opt/speedtest-plotter # measure
{
'Server ID': 'speedtestmera.vs.mythic-beasts.com:8080',
'Sponsor': '',
'Server Name': '',
'Timestamp': '2025-08-11T19:32:25+00:00',
'Distance': '',
'Ping': '0',
'Download': '1079364641.549667',
'Upload': '961824546.531281',
'Share': '',
'IP Address':
'194.233.156.42'
}
/opt/speedtest-plotter #

running using the new image:
/opt/speedtest-plotter # measure
{
'Server ID': '32806',
'Sponsor': 'Mythic Beasts Ltd',
'Server Name': 'London',
'Timestamp': '2025-08-11T19:27:50+00:00',
'Distance': 99.70637301702155,
'Ping': 5.045183,
'Download': 808091533.5352727,
'Upload': 637799782.9335272,
'Share': '',
'IP Address': '194.233.156.42'
}
/opt/speedtest-plotter #

Speedtest:

[ansemjo]

Could you try executing the following command with different values for -t, to see if more concurrent threads improve your measured speed?

docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 1
docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 8
docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 32

[TJ-C]

Here are results:
These are run on an old intel core 2 duo running ubuntu, which I use to monitor my network.
docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 1
✓ Test Server: [57318] 32.79km Slough (United Kingdom) by Zzoomm Plc
✓ Latency: 3.56247ms Jitter: 328.502µs Min: 2.877034ms Max: 3.992074ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 661.14 Mbps (Used: 848.57MB) (Latency: 5ms Jitter: 2ms Min: 3ms Max: 9ms)
✓ Upload: 123.65 Mbps (Used: 154.86MB) (Latency: 3ms Jitter: 0ms Min: 3ms Max: 4ms)
✓ Packet Loss: 0.00% (Sent: 268/Dup: 0/Max: 267)

docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 8

✓ Test Server: [70950] 1.26km London (United Kingdom) by SIGNALX CLOUD COMMUNICATIONS
✓ Latency: 4.363441ms Jitter: 427.52µs Min: 3.967419ms Max: 5.483776ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 836.98 Mbps (Used: 1059.16MB) (Latency: 17ms Jitter: 17ms Min: 4ms Max: 63ms)
✓ Upload: 218.02 Mbps (Used: 266.04MB) (Latency: 19ms Jitter: 11ms Min: 3ms Max: 38ms)
✓ Packet Loss: 1.06% (Sent: 280/Dup: 0/Max: 282)

docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 32

✓ Test Server: [70950] 1.26km London (United Kingdom) by SIGNALX CLOUD COMMUNICATIONS
✓ Latency: 4.617096ms Jitter: 422.296µs Min: 3.973775ms Max: 5.305328ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 808.82 Mbps (Used: 1037.37MB) (Latency: 14ms Jitter: 9ms Min: 6ms Max: 41ms)
✓ Upload: 380.49 Mbps (Used: 478.74MB) (Latency: 25ms Jitter: 28ms Min: 3ms Max: 86ms)
✓ Packet Loss: 2.83% (Sent: 275/Dup: 0/Max: 282)

However, running on my M1 Max under Docker desktop in translation mode the -t 8 & 32 does make a difference

docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 1

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

speedtest-go v1.7.10 (git-dev) @showwin

✓ Test Server: [70950] 1.26km London (United Kingdom) by SIGNALX CLOUD COMMUNICATIONS
✓ Latency: 5.412841ms Jitter: 898.485µs Min: 3.785667ms Max: 6.834ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 619.49 Mbps (Used: 866.51MB) (Latency: 4ms Jitter: 0ms Min: 3ms Max: 5ms)
✓ Upload: 398.10 Mbps (Used: 711.64MB) (Latency: 11ms Jitter: 27ms Min: 3ms Max: 113ms)
✓ Packet Loss: 0.80% (Sent: 370/Dup: 0/Max: 372)
(base) tjc@TheosMacStudio Speedtest % docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 1
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

speedtest-go v1.7.10 (git-dev) @showwin

✓ Test Server: [70950] 1.26km London (United Kingdom) by SIGNALX CLOUD COMMUNICATIONS
✓ Latency: 10.463058ms Jitter: 9.62231ms Min: 5.112334ms Max: 38.429792ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 629.91 Mbps (Used: 836.11MB) (Latency: 4ms Jitter: 0ms Min: 3ms Max: 4ms)
✓ Upload: 361.55 Mbps (Used: 770.61MB) (Latency: 5ms Jitter: 1ms Min: 3ms Max: 9ms)
✓ Packet Loss: 1.17% (Sent: 339/Dup: 0/Max: 342)

docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 8

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

speedtest-go v1.7.10 (git-dev) @showwin

✓ Test Server: [70950] 1.26km London (United Kingdom) by SIGNALX CLOUD COMMUNICATIONS
✓ Latency: 31.406804ms Jitter: 75.044791ms Min: 4.434792ms Max: 256.521792ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 859.40 Mbps (Used: 1099.21MB) (Latency: 6ms Jitter: 1ms Min: 4ms Max: 8ms)
✓ Upload: 847.20 Mbps (Used: 1093.44MB) (Latency: 22ms Jitter: 18ms Min: 4ms Max: 74ms)
✓ Packet Loss: 2.61% (Sent: 261/Dup: 0/Max: 267)

docker run --rm -it --entrypoint speedtest-go ghcr.io/ansemjo/speedtest:2025-08-10-speedtest-go -t 32

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

speedtest-go v1.7.10 (git-dev) @showwin

✓ Test Server: [14679] 1.28km London (United Kingdom) by Hyperoptic Limited
✓ Latency: 6.257916ms Jitter: 450.019µs Min: 5.718208ms Max: 7.054208ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 896.32 Mbps (Used: 1143.92MB) (Latency: 40ms Jitter: 29ms Min: 4ms Max: 86ms)
✓ Upload: 924.26 Mbps (Used: 1187.39MB) (Latency: 31ms Jitter: 10ms Min: 11ms Max: 45ms)
✓ Packet Loss: N/A

Is the code expecting a relatively newish cpu as I have:
description: CPU
product: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
vendor: Intel Corp.
physical id: 0
bus info: cpu@0
version: 6.15.11
slot: U2E1
size: 1197MHz
capacity: 2200MHz
width: 64 bits
clock: 200MHz
capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm cpufreq

*-network
description: Ethernet interface
product: 88E8058 PCI-E Gigabit Ethernet Controller
vendor: Marvell Technology Group Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: ens5
version: 13
serial: 00:1e:c2:11:fe:1b
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=sky2 driverversion=1.30 duplex=full ip=192.168.1.1 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:27 memory:d0400000-d0403fff ioport:2000(size=256) memory:d0420000-d043ffff

[ansemjo]

Is the code expecting a relatively newish cpu as I have ...

I'm not sure, I haven't used speedtest-go before that either. It does by default set the number of threads according to the number of CPU cores you have, so it should run with two threads on your Core2 Duo. Which is weird because the upload speeds you last measured are waaay off from what you measured in the previous comment. I would expect some overhead from using Go compared to C++ but it should still be able to saturate a Gigabit.

The results on your M1 can probably be explained by running the wrong architecture? This comment makes me believe that you might be running the image with Rosetta translation? "The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested"

[ansemjo]

It's pretty accurate for me (on my laptop and only with a 100/40 connection):