xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#514 closed task (fixed)

evaluate TCP_NODELAY

Reported by: Antoine Martin Owned by: Smo
Priority: minor Milestone: 0.12
Component: client Version:
Keywords: Cc: Mark Hills

Description (last modified by Antoine Martin)

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?)

Attachments (2)

socket-NODELAY.patch (542 bytes) - added by Antoine Martin 3 years ago.
adds the NODELAY option to the client socket connection in TCP mode
delay-vs-nodelay.csv (65.7 KB) - added by Antoine Martin 3 years ago.
performance tests results

Download all attachments as: .zip

Change History (9)

Changed 3 years ago by Antoine Martin

Attachment: socket-NODELAY.patch added

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

comment:1 Changed 3 years ago by Antoine Martin

Description: modified (diff)

comment:2 Changed 3 years ago by 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)

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by Antoine Martin

Cc: Mark Hills added

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

XPRA_TCP_NODELAY=0 xpra ...

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.


markh:

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?)

comment:5 Changed 3 years ago by 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.

Thanks

Changed 3 years ago by Antoine Martin

Attachment: delay-vs-nodelay.csv added

performance tests results

comment:6 Changed 3 years ago by 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).

comment:7 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Done, closing.

markh:

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

Please report them so they can get fixed.

Note: See TracTickets for help on using tickets.