You can disable QUIC by setting the listening address on both sides to tcp://:22000, then there is no QUIC to talk to. I can see QUIC connections being somewhat aggressive about filling the upstream, and that in turn choking downloads as well. QUIC isn’t made to back off from congestion like TCP is.
I’m leaning towards quic being the cause simply because I see a whole load of bandwidth being used but the resource monitor doesn’t show that same amount of data passing though the network card. I am assuming that quic is invisible to the resource monitor.
It’s also possible that quic is fine and there’s something going on in St where the requests are four times the bandwidth than the download. I admit, this is also very unlikely.
It’s never been an issue until maybe the last month? I know that various offices had complained of speeds, but at the time I never thought it was St. It’s only in the last week or so that I have tuned into the issue.
So started experimenting on the Send Only end. Setting any limits to the incoming rate makes no difference to the incoming internet speed. However, if I add values to the outgoing rate limit, I get the following internet incoming speeds
900 = 68.9Mbps
1800 = 66.4
1900 = 43.1
1950 = 11.4
So what I am seeing, the outgoing St transfer speed is having an effect on the incoming internet speed. So if I throttle it hard, so say 7.37Mbps limit, the office has full internet. But increase the limit, the incoming internet speed reduces. So by setting 1950, that’s a limit of 16 Mbps which is close to the offices maximum outgoing internet (they are on 70/20), it almost wipes out all the incoming internet.
This is feeling like a St bug as I can now demonstrate St is having a direct impact on incoming traffic.
I will leave the site on 1800 Outgoing rate limit as that feels like a good balance.
Again, you can’t get incoming traffic without a corresponding outgoing stream of requests and ACKs. It is unsurprising that incoming rates are reduced when you have lots of outgoing traffic. I’m not sure what the bug on our side would even theoretically be, there isn’t a special kind of internet-speed crippling traffic we could be using by mistake.
The screen shots show a before and after speed tests. So in both sets, the office download speed was very low, eg., 6.25 of 70Mbps (As I was uploading, the upload speeds are to be expected). But pause a folder, and the download speeds raise to around 69.
The second test was 13.7, and went up to 57.1Mbps
Windows resource monitor / networking tab doesn’t show why there’s was heavy bandwidth which is why I wondered if it was something to do with QUIC, given it’s UDP based. Syncthing doesn’t show at either end the amount of traffic being generated, only what’s actually being transferred.
So the basis of this thread is that St on ultra fast internet and maybe on lan to lan syncing is generating far more request or hidden traffic than would be reasonably expected.
So you say, but I see nothing that indicates this. You seem to be assuming that because your download rate is reduced by 43 Mbps that means Syncthing is downloading 43 Mbps. That’s not the case, because a much smaller amount of uploads can reduce your downloads significantly, just by blocking outgoing ACKs etc., especially on asymmetric internet connections and tech like DSL or cable.
Also there is no “hidden” traffic here. What Syncthing generates is visible in the UI: those counters cover all protocol transmissions and receives. Similarly you’ll see correct (but different, because they look at a different layer) measurements in task manager / activity monitor.
That you’re not seeing traffic in these places doesn’t mean the traffic is somehow magically hidden, it means the traffic isn’t there to begin with.