SpeedTest GO Result divergent with the SpeedTest Ookla.
alledpaiva opened this issue · 23 comments
Hi, I was testing the speed of one network and I can see a huge difference between the test using the Speedtest go and the official Speedtest to the same server...
Test with Official Speedtest:
support@host:~$ speedtest -s 15869
Speedtest by Ookla
Server: US Internet - Minneapolis, MN (id: 15869)
ISP: Comcast Cable
Idle Latency: 28.74 ms (jitter: 1.20ms, low: 27.62ms, high: 29.86ms)
Download: 729.82 Mbps (data used: 1.3 GB)
101.70 ms (jitter: 25.78ms, low: 27.06ms, high: 279.96ms)
Upload: 38.96 Mbps (data used: 40.3 MB)
34.53 ms (jitter: 6.21ms, low: 23.25ms, high: 365.48ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/a1d28179-d892-4d84-976f-71fe560f9eca
support@host:$$
support@host:
Test with speedtest-go 1.4.1 version:
support@host:~$ sudo ./speedtest-go --server 15869
Testing From IP: ..., (Comcast Cable) [**, **]
Target Server: [15869] 16.96km Minneapolis, MN (United States) by US Internet
Latency: 30.170765ms
Jitter: 3.393959ms
Min: 24.588512ms
Max: 37.256226ms
Download Test: ...........
Upload Test: ............
Download: 124.09 Mbit/s
Upload: 32.41 Mbit/s
support@host:$$
support@host:
Thank you for your feedback. @alledpaiva You can try the old version of 1.3.0 to confirm whether the result is 100-150Mbps.
I think this is caused by single-server speed measurement.
Sure! here are the results:
I had already tested with some older version, but I thought that will be better to send the results using the latest version, that actually was the one which I got the best result.
support@host:~$ ./speedtest-go -l
Testing From IP: x.x.x.x, (Comcast Cable) [**, **]
[53966] 15.38km Minneapolis, MN (United States) by Dish Wireless
[15869] 16.96km Minneapolis, MN (United States) by US Internet
[12924] 35.62km Eden Prairie, MN (United States) by vRad
[27499] 36.29km Minneapolis, MN (United States) by Hennepin Healthcare
[24581] 36.29km Minneapolis, MN (United States) by fdcservers.net
[41398] 36.29km Minneapolis, MN (United States) by Implex.net
[38862] 36.29km Minneapolis, MN (United States) by Paul Bunyan Communications
[40738] 36.29km Minneapolis, MN (United States) by Park Region Telephone
[30955] 36.29km Minneapolis, MN (United States) by NetINS powered by Aureon
[1776] 556.56km Chicago, IL (United States) by Comcast
Test with the Default server:
support@host:~$ ./speedtest-go
Testing From IP: x.x.x.x, (Comcast Cable) [**, **]
Target Server: [53966] 15.38km Minneapolis, MN (United States) by Dish Wireless
Latency: 41.07402ms
Download Test: .................................
Upload Test: ..............
Download: 96.50 Mbit/s
Upload: 39.28 Mbit/s
Version:
support@host:~$ ./speedtest-go --version
1.3.0
Test with the Same server as before.
support@host:~$ ./speedtest-go --server 15869
Testing From IP: x.x.x.x, (Comcast Cable) [**, **]
Target Server: [15869] 16.96km Minneapolis, MN (United States) by US Internet
Latency: 46.807818ms
Download Test: .......
Upload Test: ...............
Download: 82.76 Mbit/s
Upload: 36.95 Mbit/s
support@host:~$
Yes, this is caused by single-server measurement. @alledpaiva we will add multi server support in the next version.
Ok! Great! good to know! thank you for the feedback.
Do you have some forecast when this next version will be released ? Just an idea...
Ok! Great! good to know! thank you for the feedback.
Do you have some forecast when this next version will be released ? Just an idea...
As soon as this weekend.
Perfect! Thank you.
Hi, @alledpaiva. v1.5.0 has been released. You can use the following commands:
./speedtest -m
./speedtest -m --server 3333 with specifying the main server.
./speedtest -m -t 8 with adjusting the number of connections = 8.
SpeedTest Ookla Result：
SpeedTest GO Result：
SpeedTest Ookla Result：
SpeedTest GO Result：
@Astro-Lee Could you provide more details using --debug？
Thanks, have you tried the -t flag?
Could you use nload to check the general situation of the bandwidth?
It's a pity that I don't have a device with > 2.5Gbps 🤣
./speedtest-go -t 16
nload
It seems that for the upload scheduling is not aggressive. maybe -t 32 is better.
I found that you are looking for oracle keep alive. Have you tried NeverIdle? Maybe it can help you!
I have used NeverIdle, thanks!
Totally incorrect and impossible result
2023-03-18.01-11-56.mp4
Hi, @Devocub I noticed you used -t 255, But I think t=255 is obviously not a reasonable value.
The buffer size should be moderate, too large buffer space will affect the forwarding speed of data packets in the normal communication state. Because the outbound bandwidth of the network card is not enough, a large amount of request data is accumulated on the cache.
I think that's the problem:
==================
2024-03-16T16:37:14.377286919Z WARNING: DATA RACE
2024-03-16T16:37:14.377292636Z Write at 0x00c001286cd8 by goroutine 4073:
2024-03-16T16:37:14.377296511Z github.com/showwin/speedtest-go/speedtest.(*funcGroup).Start.func1()
2024-03-16T16:37:14.377341642Z /go/pkg/mod/github.com/showwin/speedtest-go@v1.6.10/speedtest/data_manager.go:187 +0x84
2024-03-16T16:37:14.377346649Z
2024-03-16T16:37:14.377350127Z Previous read at 0x00c001286cd8 by goroutine 4051:
2024-03-16T16:37:14.377357198Z github.com/showwin/speedtest-go/speedtest.(*DataChunk).Read()
2024-03-16T16:37:14.377372437Z /go/pkg/mod/github.com/showwin/speedtest-go@v1.6.10/speedtest/data_manager.go:419 +0x64
2024-03-16T16:37:14.377902222Z io.(*nopCloser).Read()
2024-03-16T16:37:14.377913283Z :1 +0x6c
2024-03-16T16:37:14.378182239Z io.discard.ReadFrom()
2024-03-16T16:37:14.378281834Z /usr/local/go/src/io/io.go:666 +0x91
2024-03-16T16:37:14.378364234Z io.(*discard).ReadFrom()
2024-03-16T16:37:14.378393658Z :1 +0x4c
2024-03-16T16:37:14.378444230Z io.copyBuffer()
2024-03-16T16:37:14.378503792Z /usr/local/go/src/io/io.go:415 +0x22e
2024-03-16T16:37:14.378508834Z io.CopyBuffer()
2024-03-16T16:37:14.378581700Z /usr/local/go/src/io/io.go:402 +0x8f
2024-03-16T16:37:14.378625180Z net/http.(*transferWriter).doBodyCopy()
2024-03-16T16:37:14.378692162Z /usr/local/go/src/net/http/transfer.go:416 +0x144
2024-03-16T16:37:14.378798878Z net/http.(*transferWriter).writeBody()
2024-03-16T16:37:14.379000531Z /usr/local/go/src/net/http/transfer.go:376 +0x7ac
2024-03-16T16:37:14.379092736Z net/http.(*Request).write()
2024-03-16T16:37:14.379346074Z /usr/local/go/src/net/http/request.go:755 +0x1413
2024-03-16T16:37:14.379413452Z net/http.(*persistConn).writeLoop()
2024-03-16T16:37:14.379567173Z /usr/local/go/src/net/http/transport.go:2447 +0x379
2024-03-16T16:37:14.379806832Z net/http.(*Transport).dialConn.gowrap3()
2024-03-16T16:37:14.380044511Z /usr/local/go/src/net/http/transport.go:1800 +0x33
2024-03-16T16:37:14.380088272Z
2024-03-16T16:37:14.380167921Z Goroutine 4073 (running) created at:
2024-03-16T16:37:14.380380462Z time.goFunc()
2024-03-16T16:37:14.380413906Z /usr/local/go/src/time/sleep.go:177 +0x44
2024-03-16T16:37:14.380451920Z
2024-03-16T16:37:14.380550421Z Goroutine 4051 (finished) created at:
2024-03-16T16:37:14.380688560Z net/http.(*Transport).dialConn()
2024-03-16T16:37:14.380786547Z /usr/local/go/src/net/http/transport.go:1800 +0x27fe
2024-03-16T16:37:14.381044459Z net/http.(*Transport).dialConnFor()
2024-03-16T16:37:14.381088382Z /usr/local/go/src/net/http/transport.go:1485 +0x124
2024-03-16T16:37:14.381213658Z net/http.(*Transport).queueForDial.gowrap1()
2024-03-16T16:37:14.381420812Z /usr/local/go/src/net/http/transport.go:1449 +0x44
2024-03-16T16:37:14.381578181Z ==================
Hi, @kei969777, I have tried fixing these data races, could you experiment with the performance difference between it and 1.6.10? Thank you for your help.
I provide fixed builds for linux/amd64 and windows/amd64 here:
speedtest-go_1.6.11_fix_data_race.zip