[[Image(...)]] Session Info

The "Session Info" dialog is accessible in the following ways:

• Under "Session Info" in the xpra system tray menu
• Using the key shortcut Meta + Shift + F11 when an xpra window has the input focus
• Using the xpra control command "show_session_info" on the server, ie:

  xpra control :10 client show_session_info
  

It looks like this:

Software

The software pane lists the versions of the most important components of the system for both the client and server: Xpra, (Py)GTK components, (Py)GStreamer, OpenGL, etc..

It allows you to quickly verify that the system is up to date. You can get more detailed version information using xpra info or using the Bug Report Tool.

You can see a screenshot here

Features

The features pane shows more details about sound and picture encoding support and status, packet compression support, client OpenGL library version, bell, cursor, clipboard and mmap features, etc.

You can see a screenshot here

Connection

The connection pane shows information about the connection status: the endpoint location, server load, how old the session is and how long it has been connected, the number of packets and bytes received and sent, the type of connection, the encryption used (if any) and the packet compression and encoding algorithms in use, as well as the state of the sound buffers (if used).

You can see a screenshot here

Statistics

The statistics pane shows various latency and quality data from the server, it can be used to monitor how well the system is self tuning to adapt to the network conditions.

You can see a screenshot here

Server Latency

This is a measure of how long it takes for:

• the client to send a "ping" packet
• the server to receive it, process it and send the "echo" response
• the client to process the response and calculate the latency

It is very different from an ​ICMP Ping because it includes on both ends:

• the full operating system network stack
• the operating system scheduler
• the Python interpreter with its threads and locking
• TCP re-transmits

On a busy system, this value may well go up as other packets are ahead of the send queue at either end. A modern CPU should be able to keep this value below 50ms plus the TCP connection latency. TCP packet drops can cause this value to increase more dramatically.

Client Latency

Is identical to the server latency above, but it is measured by the server to the client instead.

Batch Delay

This value represents how long the server waits for window updates to accumulate before actually processing them and sending them to the client. This value changes dynamically to try to provide the best framerate without flooding the connection with compressed pixel data. The value shown here is for all the windows, but each window has its own statistics which can be accessed using xpra info for more details.

It is a function of:

• the client and server latency (as explained above)
• the client pixel processing latency (..)
• how busy the server's compression work queue is (how many regions of screen are waiting to be processed)
• how many compressed packets are waiting to be sent
• how well the network layer is performing at sending those packets
• whether the window is fullscreen or maximized, focused, the type of window, etc..

It should be explained in more detail here: batch delay factors (information is slightly out of date..)

Damage Latency

This value represents the time it takes to:

• retrieve the pixels from the window
• compress them
• submit them to the network protocol layer
• pass them on to the operating system (which still has its own network buffers - though we do set the NODELAY socket flag, so this should be fairly small)

This is the step that happens after we have waited for the batch delay above.

Encoding Quality and Speed

This value applies to the video encodings, jpeg and webp encodings. When using a video encoder, we may also send the same area again using a lossless encoding as part of the "automatic lossless refresh".

More information here: speed and quality auto tuning

Decoding Latency

This figure represents the average time it takes for the client to decompress the screen updates it receives and update the window contents with it.

Regions/s

This is the number of screen updates per second. Bear in mind that those updates may be very large or very small, and anything in between..

Pixels/region

This is the average size of the screen updates the client is receiving.

Pixels/s

The total number of pixel updates displayed per second.

Graphs

Those two graphs provide a visual representation of some of the data found on the "connection" and "statistics" panes.

Both graphs only sample the data once every second and so the lines are interpolated.

Bandwidth

Shows the amount of data sent and received by the client, as measured by the socket layer, and the number of pixels it receives.

Latency

This summarizes the latency found on the statistics pane:

• network is the sum of the client and server latencies
• batch delay is exactly as is explained above
• encode and send is the Damage Latency explained above
• decoding is the Decoding Latency explained above
• frame total is the more or less the sum of those values (using the average of the network latency, not the sum)

---

Caveats:

• this representation oversimplifies things and glosses over some important details, some (but by no means all) are documented here: wiki/WindowRefresh.
• xpra info often provides more detailed information and is the preferred way of investigating latency issues