Latency discrepancy with real / Ookla's tool levering "bad" target server election #112
Comments
|
Hi, @crbertoldo, Thanks for pointing out. Actually, we briefly changed the calculation method of the latency to I think it's(down/up) caused by inappropriate number of concurrency. Have you tried to increase the number of connections using |
|
Ookla and speedtest-go currently have the same method of selecting the main server (the lowest latency is the main server), so I think the issue of automatic server selection is greatly affected by the latency measurement method. |
|
Thanks a lot, @r3inbowari. With Regarding the privileged method for ICMP, could it be somehow an option for those with root, and the current (1.5.0) latency measurement be the default method, for non-root? |
|
Yes, I will add a flag |
|
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. |
|
Hi, @crbertoldo, I don't have a corresponding test environment to verify the impact of burst bandwidth on average bandwidth result. Could you help me test this version of speedtest-go with adding speedtest-go_v1.5.1 |
|
Because there is always a high-speed burst bandwidth greater than 2-3 seconds on my machine. Measurement unit: bytes per 100ms [DBG]2023/03/03 01:27:25 Raw Sequence len: 100 |
|
Hi @r3inbowari, sorry for the late reply. 1.5.1 doesn't give us latency. However, 1.6.0 gives it: Find below the output for 1.6.0. If you need with 1.5.1, please let me know. Results from Oookla, towards the same test server, show idle latency of ~3ms. |
|
Thank you very much! As your log shows, speedtest-go uses http-ping to measure peer latency (Ookla's ping runs at the Transport Layer, instead we at the Application Layer). So there must be some deviation from Ookla. |
|
Thank you, @r3inbowari. Do you think it's feasible changing to the transport instead of the application layer's ping? If not, at least changing it to ICMP, with the |
|
@crbertoldo In fact, speedtest-go will automatically use it only if icmp is available now. Incidentally, ICMP should belong to the Network Layer. --icmp makes sense and we need to fall back to http-ping if we don't have privilege. But my question is whether this option conflicts with auto select? |
|
@r3inbowari I haven't followed 100% your answer, sorry. By |
Yes, that's right. |
|
I think it's better to add |
Meaning that icmp keeps as auto-selected, and http-ping as the icmp fall-back, but it can also be forced with |
Yes,
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. icmp is fully available. // We force back to http even if icmp is available. Maybe |
Awesome. Thanks for clarifying and working on that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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:
But when we let speedtest-go choosing the target server, the discrepancy in the results is bigger:
Also, not sure if relevant here, but the list speedtest-go servers list is bigger, despite of somehow similar to the top ones.
The point: is the latency calculation an issue and/or somehow can we automatically select what Ookla does so as the target server?
The text was updated successfully, but these errors were encountered: