Thank You for Multiple Connections

Development
1

@calmh I just wanted to thank you for your work on all: Support multiple device connections (fixes #141) by calmh · Pull Request #8918 · syncthing/syncthing · GitHub.

Story time:

I’ve been trying to get as much out of Syncthing as I can over this one WAN link with high latency. Ultimately, I diagnosed the problem of slow transfers to packet loss (< 5%, but still impactful to a high latency connection) and recorded packets along the way. Every time a packet was lost or was reordered, TCP congestion control would slow down the connection. Switching to BBR helped a lot, given it doesn’t use packet loss for back pressure detection - but I was only able to get half of my link’s bandwidth due to the high latency. No ISP traffic shaping or throttling - just a bad hop somewhere out of my control.

With multiple connections I see double or even triple the bandwidth over the same. In my testing, this is caused by each TCP stream being independently controlled by congestion control - so when one of the links slows due to congestion control, other streams can compensate.

7 Likes
2

Same for us, massive improvement.

We’re using 4 connections as default at present; have you noticed any advantage in more than this?

Thanks

1 Like
3

I haven’t in my testing, so I’ve defaulted mostly to 4 connections now.

That said, I am trying to track down some instability with 4 connections (1 metadata + 3 data) - things just randomly stall with no errors or loss in connections. Reducing down to 3 was stable, but of course, slower.

Interestingly, it appears that increasing copiers helps - although, further testing is needed. I suspect Syncthing might be having some issues with keeping the data links saturated given a lot of smaller files (e.g. 200MB) and much faster transfers. I also suspect the pulling side might be IO bottlenecked too, during my tests (SAN’s are fun) - so again, more testing is needed.

Either way, this new feature in Syncthing is exciting!

1 Like