Just genuinly curious what the practical effects of turning it on would be (if any).
I think this disables Nagles which I think improves throughput on high latency links.
That would be the case for
setNoDelay(true): net - The Go Programming Language
I don’t know if it’s still the case, but I think at one point we used to do several small network writes (think message header, then message). There’s no interactivity requirement here so letting the OS pack this into larger packets is generally advantageous (nodelay = false).
You’d have to ask me in 2014, and I don’t remember more than above.
Is there a specific reason why you’re concerned about this?
I was curious how syncthing deals with high latency networks, started digging in the code and found this.
Wouldn’t this slow down the transfer if syncthing sends lots of small messages on high latency networks or are our writes usually big enough not to cause any problems here?
I don’t think so, because what generally happens is that we send out a bunch of requests and process data as it comes in, trying to keep several tens of megabytes of data in flight at any given moment. I guess it’s possible that if all we need is a single 200 byte block this might get delayed a few hundred milliseconds or whatever, but I doubt this is a common scenario.
You could of course analyze it and come to another conclusion.
I’m going to run a test using a build with TCP_NODELAY turned on at the weekend.
This would also affect relay connections or am i wrong?
All connections get set the same settings.
Compiled 1.13.1 with nodelay and started up a node with it. No noteable differences so far for connections over LAN or WAN. I’ll test relay connections tomorrow.
Edit: nodelay seems to be a little bit faster if the node is the receiver(~142-149Mbps vs 148-154Mbps).