Open zR-JB opened 1 month ago
I'll address this in a future version, but there are known limitations as outlined in https://github.com/openspeedtest/Speed-Test/issues/33. Otherwise, we'd need to overhaul the entire setup and potentially use something like webtransfer. I'll seriously consider this for the next major rewrite, which will support multiple protocols.
When looking at what is transferred during the speedtest.net test, I noticed that the downloads and uploads are also XHR, and the ping measurements are done via a websocket, so I think you are right.
So I did a bit more testing a made small POC with a simple node.js echo websocket server. And then performance.now() on the client side. Turns out Firefox does by default also only provide millisecond accuracy, even with performance.now(). Chromium based browsers, at least, have 100 μs. I think there is still a bit much overhead for extremely accurate results.
So here is what I found:
When you add browser extensions, web filters, antivirus software, and other busy tabs to the mix, you'll see a much higher RTT.
Yes, I think a websocket approach to measure latency similar to:
is probably still the best compromise
Maybe never stop the ping measurement, and let it run continuously also during the upload and download phase. And then have a simple graph, or just the average during the different load scenarios. With this, one could investigate buffer bloat issues very easy!
Even ookla with speedtest.net had this feature for quite some time now:![image](https://github.com/user-attachments/assets/22197711-4e19-4419-ae40-96c7bee267a2)