xpra icon
Bug tracker and wiki

Latency


Minimizing latency

Everyone wants low latency screen updates, but not everyone gets it. The server should be able to self-tune adequately in most cases.

To be able to minimize latency, it is important to understand where the latency comes from in order to be able to target what can actually be lowered in the chain. (see understanding latency below). Some delays cannot be reduced: your connection latency is dictated by the laws of physics and there's no way to change them, it is usually impossible to affect the delays introduced by the operating system or the hardware.


Here are some common misconceptions:

  • setting TCP_NODELAY on the socket will reduce latency: that's not necessarily the case, and it can be counterproductive in some situations (ie: limited bandwidth, tunnelled traffic, etc - see #619)
  • disabling picture compression (ie: RGB only): if the CPU can compress faster than your network can send, then it may actually take longer to process the screen updates
  • plain TCP mode is faster than SSH: it usually is, but not always
  • bandwidth and latency does not change over time - measure it here: https://speed.cloudflare.com/

So, how do you make things go faster?

  • use a hardware encoder: NVENC
  • application content-type: making sure that xpra guesses correctly (#1952)
  • give some hints about what sacrifices to make:
    • quality: sacrifice latency, framerate and bandwidth consumption in favour of perfect screen updates
    • speed: sacrifice bandwidth consumption in favour of better latency (usually) and framerate

If that is not sufficient, you may want to report the problem so we can advise you on how best to tune your system, and fix xpra if that's what is required.

Understanding latency

From the moment the user does something using the keyboard or mouse until he can see the result of this action on screen. Here are the various steps that can introduce latency:

  • device, ie: more for wireless devices
  • operating system and drivers
  • display server and window manager
  • xpra client's UI thread (or browser)
  • client packet formatting, compressing and sending
  • client OS network layer
  • network latency
  • server OS network layer
  • xpra server receiving, uncompressing and parsing
  • the specific packet handler for the message type
  • feeding this event into the backend display server via the UI thread
  • forwarding the event to the application
  • application does something (ie: draw something on screen)
  • the display server is notified
  • xpra server is notified
  • xpra server batching
  • pixel compression
  • packet formatting, etc
  • server OS network layer
  • network latency
  • client OS network layer
  • xpra client receiving, uncompressing and parsing
  • packet handler (ie: paint) in the UI thread
  • update the screen buffer
  • present the update on screen

The latency graphs in the session-info window of the client show some of those delays.

Some related tickets: #2130, #2090, etc.

Last modified 2 months ago Last modified on 05/29/20 04:09:31