Xpra: Ticket #514: evaluate TCP_NODELAY

From How do I use TCP_NODELAY?: TCP_NODELAY is for a specific purpose; to disable the Nagle buffering algorithm. It should only be set for applications that send frequent small bursts of information without getting an immediate response, where timely delivery of data is required (the canonical example is mouse movements).

Some background reading: TCP/IP options for high-performance data transmission

I think that the client could benefit from this as it only sends small packets anyway, and those tend to require low latency (damage ACK, pings, etc). It should be investigated, and maybe it should be the default or at least be an option for certain usage scenarios. (like games?)

Sun, 09 Feb 2014 11:54:50 GMT - Antoine Martin: attachment set

adds the NODELAY option to the client socket connection in TCP mode

Sun, 09 Feb 2014 12:05:13 GMT - Antoine Martin: description changed

Wed, 19 Feb 2014 17:22:55 GMT - Mark Hills:

Out of curiosity (whether xpra was using these flags) I was searching on this topic and came to this ticket.

I wanted to chime in and say that if xpra isn't using nodelay/nowait then, yes, I think from previous experience (of implementing servers) that this could make a massive difference.

Also, the use of TCP_CORK as useful to temporarily disable this; for example to send a header followed by the data payload.

However, we're currently enjoying the ease of xpra over SSH. And it's here that, I presume, that a caller to SSH cannot provoke it to send data in this way. (I wonder if some terminal code or option can be used)

Mon, 24 Feb 2014 16:31:51 GMT - Mark Hills:

I tested the patch above, with xpra 0.9.8 and a TCP connection.

It did not break anything. It feels better, but I did not do a 'blind' test. It's not significantly better (in my case I have 82ms round trip, yet mouse clicks still feel to take approx 0.5 seconds to register in a QT application)

It looks to me like the patch only affects the upstream connection, and should maybe be applied to the server-side as well, but would be different given there is more data involved.

Tue, 25 Feb 2014 02:42:38 GMT - Antoine Martin: cc set

I have merged the NODELAY stuff for both client and server in r5572, defaults to on. It will make it easier to test:


I will try to run the full automated tests both with and without and see what the differences are, if any. smo: feel free to beat me to it.


I have 82ms round trip, yet mouse clicks still feel to take approx 0.5 seconds

Please post "xpra info" for your session, sounds like something is wrong.

But first the obvious: you are using an old unsupported version with known bugs... (probably stuck with the gentoo ebuilds or something like that?)

Tue, 25 Feb 2014 11:48:19 GMT - Mark Hills:

We're using an older version as this is a production system with many users, so we tend to be pretty conservative.

I'm set the wheels in motion of testing and upgrading the production system to 0.11.3.

I can still do small localised testing. I had some problems with compatibility between 0.9 and 0.10 versions.


Fri, 28 Feb 2014 00:45:41 GMT - Antoine Martin: attachment set

performance tests results

Fri, 28 Feb 2014 00:49:38 GMT - Antoine Martin:

I left the automated tests running overnight and the results are in, see attachment above and the pretty graphs here: NODELAY.

Overall, it seems to make a very noticeable difference to the client and server latency, but not much in terms of anything else. Only mmap encoding suffered slightly in some cases, and also some of the pathological tests (ie: gtkperf) though it was actually better in some cases. Some tests were discarded from the graphs because of incomplete data with some encodings (and the graphs only show averages).

Tue, 18 Mar 2014 14:27:29 GMT - Antoine Martin: status changed; resolution set

Done, closing.


I had some problems with compatibility between 0.9 and 0.10 versions.

Please report them so they can get fixed.

Mon, 28 Jan 2019 16:57:56 GMT - Antoine Martin:

Follow up: #619

Sat, 23 Jan 2021 04:57:58 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/514