Impossibly high upload speeds occassionally reported

[kura]

I run a speedtest every 5 minutes and ingest the output in to InfluxDB, I'm running latest speedtest-go==1.6.10 with flags -t 64 --json

I've noticed that periodically I am getting impossible upload speeds back from speedtest-go. My Connection is 1.13Gb/s down, roughly 110Mb/s up, and most of the time this is reported correctly by speedtest-go (my upload is reported a bit higher than I've ever actually seen it with any other measuring method at ~120Mb/s but I can live with that.)

What I can't explain are results like this though, I've condensed it down to just the dl speed, ul speed and durations.

{
  "servers" = [
    {
      "dl_speed":928.2367,
      "ul_speed":6032.122,
      "test_duration": {
        "ping":2131668920,
        "download":10002077363,
        "upload":10001773170,
        "total":22135519453
      }
    }
  ]
}

There results do crop up fairly commonly, seemingly with a comsensurate drop in dl speed which may be congestion my end though I'm not sure if the drop in dl is real. This also doesn't just happen on a single speedtest server.

My fix for this for now is I just check the returned value for upload speed and if it breaches my known network capabilities I throw the result away and re-test, so it's not a biggy. But figured I'd report the issue just in case there is a wider bug in speedtest-go.

[r3inbowari]

This looks more like the io buffer is being overcrowded. Does the problem improve when you reduce the number of connections?

[kura]

I honestly haven't tried to reduce the number of connections, no. I played around with the -t option a fair bit when switching over to speedtest-go and after a bunch of trial and error I found that setting it to at least 32 gave the most accurate readings, but not always. So I just doubled it to 64 thinking my server has a bunch of cores, so may as well utilise them, and it lead to very accurate readings, excluding these massive upload outliers.

[r3inbowari]

I think we should change the algorithm to solve the overcrowded problem when using many connections.

[kura]

Sounds like a good idea, would it be possible to expose some of it as tweakable with a bit of documentation explaining how it works? Something like setting the io bufer sizes and explaining that they will be multiplied by the -t option. Or something like that, if not then I some decent defaults and a little documentation to explain what that'll mean to stop someone thinking "let's throw 300 connections at it" without realising how much memory that'll end up using.