{{{#!div class="box" = [[Image(http://xpra.org/icons/statistics.png)]] 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: [[Image(session-info-small-screenshot.png)]] }}} {{{#!div class="box" = 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 [/wiki/ReportingBugs#BugReportTool Bug Report Tool]. You can see a screenshot [/attachment/wiki/SessionInfo/session-info-software.png here] }}} {{{#!div class="box" = 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 [/attachment/wiki/SessionInfo/session-info-features.png here] }}} {{{#!div class="box" = 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 [/attachment/wiki/SessionInfo/session-info-connection.png here] }}} {{{#!div class="box" = 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 [/attachment/wiki/SessionInfo/session-info-statistics.png 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 [http://en.wikipedia.org/wiki/Ping_(networking_utility) 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: [/wiki/WindowRefresh#TheBatchDelayFactors 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: [/wiki/WindowRefresh#SpeedandQualityautotuning 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. }}} {{{#!div class="box" = 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]. }}}