I have two Syncthing instances that are located half a world apart from each other. Tests regarding the number of connections revealed that there is a substantial increase in transfer speed to be gained by maxing the number of parallel connections.
Is there a way to raise the cap of 128 connections?
Am I the only one that notices this performance boost? I guess it helps to overcome the throughput limitations of single TCP streams caused by high latency over large distances.
Are there other Syncthing settings I can use to optimize the transfer speed?
Syncthing A is connected via Starlink, Syncthing B has a public IP. Like I said the two instances are 20000km apart so a lot of intercontinental cables and servers in between. The link is over TCP WAN. I use the link to sync archived files (200MB) one-by-one.
Number of connections
Average transfer speed [Mbps]
24
12
24
11
32
13
32
16
48
21
64
20
80
29
128
40
128
47
It is clear that a plateau has not been reached yet.
There are definitely optimization possibilities for extremely high latency connections. My longest distance between nodes is about 16,000 km “as the crow flies.” I didn’t trace the actual distance the data traveled from hop to hop but it’s probably considerably longer.
The key is the connection latency and to a lesser extent packet drop rate and connection bandwidth.
We have found QUIC to be a little faster than TCP but your experience may be different. We used 16 connections because it was “enough” for us. I do believe there are optimizations that can be done to improve raw transfer rate. I guess QUIC would imply that syncthing has a lot more control over things like packets in flight. For high latency connections more packets in flight with a longer period before retries could help I would think.
Our latency from New York to Singapore is ~300ms at best. Not bad given the distance traveled.
I’m definitely interested to hear others thoughts about optimizing for high latency connections.
pullerMaxPendingKib, maxConcurrentIncomingRequestKiB and maxConcurrentWrites
There was no clear indication that these parameters significantly increase the transfer speed.
The number of connections stays the most sensitive parameter for optimising the transfer speed (in this particular case). QUIC is not really an option for this setup. It seems like the performance bottleneck is caused by high network latency (RTT) limiting the throughput of individual TCP streams, rather than application-layer buffer limits.
