Syncthing crippling internet speeds?

Not sure how that thread is related to your issue.

I suspect the 70/20 is 70/20 in isolation, as in, even in a pure download scenario your download rate will drop, even if you are just using 10 out of the 20 upload for something else.

I always read those numbers as 70/0, 0/20.

I guess you can set rate limits on syncthing and see if that’s true/it helps.

Given you are pulling down large images, I doubt its any sort of additional per file chatter that you are referring to.

You could try disabling temp indexes, but I doubt it’s that.

There’s definitely something going on. Site reported slow download speeds as the sync has restarted, so was getting


The instant I paused the upload I get


There’s nothing in any of the network tests that show why there is so much being downloaded, however I wonder if the QUIC protocol is the cause as maybe the resource monitor only see’s TCP.

Is there an option to disable quic and have just a tcp connection?

I should add, I am only concerned with the sites download speed. Their upload is to be expected as they are send only

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.

They are quite similar in that regard. See RFC9002.

1 Like

You’re right, I misremembered. Looks like it does take up a little more space than a regular TCP connection, but shouldn’t be completely antisocial at least.

Another office started a large image transfer so has given me a chance to see if the speed issue is there, it is.


so I enabled throttling at the receiving end to 900 to see if it would slow down the requesting data…


but made no difference. So paused the sync and retested the speed…


Can anyone think of a tool I can use that will look at realtime transfer speed on the quic protocol?

I tried tcp://:22000 at both ends, same result. Very slow download speeds on a send only site

bit of a long shot, how hard would it be to obtain a custom build where quic is fully disabled for testing purposes?

Alternatively, I could go back to an earlier version where quic wasn’t so heavily used, if I know which version to look for

If you are not connected using QUIC, you’re not using QUIC. I don’t see how removing the code from the binary would change anything?

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.

This might be as well caused by your ISP. Quite a few tend to throttle filesharing which is often only equated with high UDP traffic.

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.

1 Like

I accept there is going to be request traffic, but it’s the volume of data / requests that bothers me.

A send only site should not be receiving almost 4 times the bandwidth requesting data than is actually being sent?

I wouldn’t expect that either but the only syncthing screenshot I can see when scrolling up shows nothing like that?

1 Like

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.

Without digging into the code but would a limit delay ACKs?

@terry just check which kind of connection is established. Anyway Windows properly displays TCP/UDP network usage. No magic here.

1 Like

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.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.