speedtest-go work only in saving-mode

[kalooyan]

[g-a-c]

+1

I'm trying to use this as a library as part of Telegraf, but without --saving-mode the test takes significantly longer and the remote end appears to be hanging up on me

Saving mode completes successfully in 20 seconds

Testing From IP: x.x.x.x, (Vodafone UK) [x, x]

Target Server: [29080]    95.77km Leicester (United Kingdom) by Iomart
Latency: 32.036902ms
Download Test: ......
Upload Test: ..............

Download: 24.91 Mbit/s
Upload:  2.90 Mbit/s

Normal mode takes 75 seconds to return an error. Note that there are more .s for both download and upload, so it appears that in normal mode the client is doing more work?

Testing From IP: x.x.x.x, (Vodafone UK) [x, x]

Target Server: [29080]    95.77km Leicester (United Kingdom) by Iomart
Latency: 33.848829ms
Download Test: .......................
Upload Test: ....................................................2022/09/22 23:01:56 Post "http://speedtest-net5.rapidswitch.co.uk:8080/speedtest/upload.php": readfrom tcp 172.26.163.147:58172->78.129.209.250:8080: write tcp 172.26.163.147:58172->78.129.209.250:8080: write: connection reset by peer

[showwin]

The file size to measure bandwidth is decided by the download warming-up process here. If you have wide bandwidth for download, the large file size would be chosen to measure both download and upload speed. So if your upload bandwidth is much narrow compared to your download bandwidth, it'll take too much time.

In general, the mobile network has narrow upload bandwidth as I can see from your result. So It looks better to use --saving-mode.

The reason we didn't introduce the upload warming-up process is to reduce the total time to measure speed.

[crbertoldo]

Hi @showwin, please: would a feature request for allowing the "upload warming-up" via an argument (--upload-warming-up) make sense? We've been seeing the same issue as here, BW ~5Mbps, and --saving-mode is bringing less reliable values.

[showwin]

Hi @crbertoldo. I've just realized we have a warm-up process for the uploading test too 🙏 (here) This issue may be due to the fact that the proper file size is not selected in the download test due to the inaccuracy of the warm-up process for some range of bandwidth. I'll check the measuring algorithm later.

[crbertoldo]

Hi @crbertoldo. I've just realized we have a warm-up process for the uploading test too 🙏 (here) This issue may be due to the fact that the proper file size is not selected in the download test due to the inaccuracy of the warm-up process for some range of bandwidth. I'll check the measuring algorithm later.

Amazing @showwin. Thanks a lot.

[r3inbowari]

Through experiments, it can be found that the number of workloads should match the number of cores of the host machine, and the transfer rate is the highest at this time.

[r3inbowari]

Through experiments, it can be found that the number of workloads should match the number of cores of the host machine, and the transfer rate is the highest at this time.

In addition, the size of dlSizes and ulSizes does not affect the result. So, I think warming up is not necessary, and matching the number of cores is more important. https://github.com/showwin/speedtest-go/pull/98#issue-1588471540