speedtest-go: Latency discrepancy with real / Ookla's tool levering "bad" target server election

Hi,

Comparing Ookla’s tool and speedtest-go, due to the latency calculation mismatches for the target server, we get a significant difference in the up/down results. For a given client and at nearly the same time, many rounds were run to test it, and the Ooklas’s target election always brings better results (close to the real 1Gbps in this example). That still ignores another issue referred to below and that seems not solved.

support@host:~$ speedtest --selection-details

   Speedtest by Ookla

Selecting server:
      10162:  24.78 ms; CenturyLink - Portland, OR
      29938:  26.25 ms; FIBERFI - Portland, OR
      16252:  26.25 ms; allstream - Portland, OR
       6215:  30.11 ms; LS Networks - Portland, OR
      45243:  18.55 ms; OHSU - Portland, OR
       6531:  20.86 ms; SilverStarTelecom - Portland, OR
       1780:  19.48 ms; Comcast - Portland, OR
      53972:  23.44 ms; Dish Wireless - Portland, OR
      33992:  29.45 ms; Sherwood Broadband - Sherwood, OR
      49788:  47.15 ms; Mimo Connect Ltd - Hillsboro, OR
      Server: OHSU - Portland, OR (id: 45243)
         ISP: Comcast Cable
Idle Latency:    34.50 ms   (jitter: 6.83ms, low: 27.61ms, high: 42.97ms)
    Download:   838.22 Mbps (data used: 880.4 MB)                                                   
                 20.74 ms   (jitter: 4.59ms, low: 9.34ms, high: 70.42ms)
      Upload:    23.81 Mbps (data used: 12.5 MB)                                                   
                 43.22 ms   (jitter: 17.59ms, low: 20.63ms, high: 190.23ms)
 Packet Loss: Not available.
  Result URL: https://www.speedtest.net/result/c/***

Except for latency (let’s ignore it here once its “wrong” value may be the root cause), comparing the output above vs. the below (both server 45243), the down/up results are not so close (maybe due to the other issue told above), but “acceptable” ones for this discussion:

support@host:~$ ./speedtest-go --version
1.5.0

support@host:~$ ./speedtest-go -s 45243
Testing From IP: ****

Target Server: [45243]     7.36km Portland, OR (United States) by OHSU
Latency: 302.542824ms
Jitter: 750.463579ms
Min: 37.912272ms
Max: 2.553466356s
Download Test: ...........
Upload Test: ...........
 
Download: 742.60 Mbit/s
Upload: 24.32 Mbit/s

But when we let speedtest-go choosing the target server, the discrepancy in the results is bigger:

support@host:~$ ./speedtest-go         
Testing From IP: ***

Target Server: [6531]     7.36km Portland, OR (United States) by SilverStarTelecom
Latency: 39.594061ms
Jitter: 7.799145ms
Min: 29.288382ms
Max: 54.47793ms
Download Test: ...........
Upload Test: ............
 
Download: 583.41 Mbit/s
Upload: 23.82 Mbit/s

Also, not sure if relevant here, but the list speedtest-go servers list is bigger, despite of somehow similar to the top ones.

support@host:~$ ./speedtest-go -l       
***
[ 6531]      7.36km 27ms 	Portland, OR (United States) by SilverStarTelecom 
[10162]      7.36km 60ms 	Portland, OR (United States) by CenturyLink 
[29938]      7.36km 88ms 	Portland, OR (United States) by FIBERFI 
[16252]      7.36km 62ms 	Portland, OR (United States) by allstream 
[ 6215]      7.36km 69ms 	Portland, OR (United States) by LS Networks 
[45243]      7.36km 66ms 	Portland, OR (United States) by OHSU 
[53972]      7.36km 113ms 	Portland, OR (United States) by Dish Wireless 
[ 1780]      7.36km 96ms 	Portland, OR (United States) by Comcast 
[33992]     16.57km 78ms 	Sherwood, OR (United States) by Sherwood Broadband 
[13314]     22.14km 53ms 	Canby, OR (United States) by DirectLink 
[49788]     23.25km 141ms 	Hillsboro, OR (United States) by Mimo Connect Ltd 
[37289]     23.25km 80ms 	Hillsboro, OR (United States) by City of Hillsboro 
[51770]     35.00km 66ms 	Sandy, OR (United States) by SandyNet 
[18533]     37.23km 92ms 	Woodburn, OR (United States) by Wave 
[33171]     38.38km 104ms 	Colton, OR (United States) by COLTON.COM 
[ 3652]     47.57km 54ms 	McMinnville, OR (United States) by Hunter Communications 
[ 1744]     57.33km 136ms 	Estacada, OR (United States) by Reliance Connects 
[25011]     71.47km 123ms 	Turner, OR (United States) by ViserFiber 
[11976]     73.84km 108ms 	Stayton, OR (United States) by Stayton Telephone 
[25719]     79.83km 101ms 	Monmouth, OR (United States) by Minet Fiber 
support@host:~$ speedtest -L
Closest servers:

    ID  Name                           Location             Country
==============================================================================
 10162  CenturyLink                    Portland, OR         United States
 29938  FIBERFI                        Portland, OR         United States
 16252  allstream                      Portland, OR         United States
  6215  LS Networks                    Portland, OR         United States
 45243  OHSU                           Portland, OR         United States
  6531  SilverStarTelecom              Portland, OR         United States
  1780  Comcast                        Portland, OR         United States
 53972  Dish Wireless                  Portland, OR         United States
 33992  Sherwood Broadband             Sherwood, OR         United States
 49788  Mimo Connect Ltd               Hillsboro, OR        United States

The point: is the latency calculation an issue and/or somehow can we automatically select what Ookla does so as the target server?

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 18

Most upvoted comments

Meaning that icmp keeps as auto-selected, and http-ping as the icmp fall-back

Yes, --http-ping as force http-ping.

but it can also be forced with --http-ping when the use case is the wish of root + http-ping?

auto-seleled will be used as default, because users may not know when icmp is available. And http-ping is always available.

eg: // The program will automatically select the protocol, In this case, icmp may be available. ./speedtest-go => “http” or “icmp”

// The program will automatically select the protocol. icmp is fully available. // In general, when auto-seleled is in effect, icmp has the highest priority. sudo ./speedtest-go => “icmp”

// We force back to http even if icmp is available. sudo ./speedtest-go --http-ping => “http”

Maybe --force-http-ping is more clear.

Awesome. Thanks for clarifying and working on that.

@r3inbowari I haven’t followed 100% your answer, sorry. By if icmp is available now, do you mean that we already have it, just running 1.6.0 with sudo? If so, is this the auto-select feature you meant?

Yes, that’s right.

I’m trying to add a feature: Dynamic Workload Adaptation, I think it will be more friendly to automatically match the number of connections.

Awesome @r3inbowari. Thanks again.