HDX Channel from Desktop Test
As already mentioned, the key factors influencing user experience in a virtual desktop infrastructure are the latencies experienced by the user while connecting to the desktop via ICA and the bandwidth used when a user interacts with a virtual desktop. High latency and excessive bandwidth consumption can often slowdown access to desktops, thereby significantly delaying subsequent user operations. Hence, monitoring the latency and bandwidth usage of the ICA communication channel between the user terminal and the virtual desktops is essential.
The HDX Channel from Desktop test auto-discovers the virtual desktops on the Citrix Hypervisor host and the users who are currently connected to each desktop. For each such user, the test monitors the communication between a user and the virtual desktop, and reports the following:
- The latency experienced by each user session;
- The bandwidth used by the incoming and outgoing data/audio/multimedia traffic transacted by the ICA communication channel between each user and virtual desktop;
Using this test, an administrator can identify user sessions that are being impacted by high latency and abnormal bandwidth usage. In addition, the test also reveals the type of traffic that is causing excessive bandwidth usage, thereby providing pointers to how the client configuration can be fine-tuned in order to reduce bandwidth consumption and improve performance.
This test is disabled by default. To enable the test, go to the enable / disable tests page using the menu sequence: Agents -> Tests -> Enable/Disable, pick Citrix Hypervisor - VDI as the Component type, set Performance as the Test type, choose this test from the disabled tests list, and click on the >> button to move the test to the enableD tests list.
Note:
This test will report metrics only if the following conditions are fulfilled:
- The test is applicable to Windows VMs only.
- The VMs being monitored should be managed by XenDesktop Broker.
- The Virtual Desktop Agent software should have been installed on the VMs.
- The ICA Session performance object should be enabled on the VMs.
Target of the test : A Citrix Hypervisor
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for every user who is connected to a virtual desktop via ICA
| Parameter | Description |
|---|---|
|
Test period |
How often should the test be executed. |
|
Host |
The host for which the test is to be configured. |
| Port |
The port at which the specified host listens. By default, this is NULL. |
|
Xen User, Xen Password and Confirm Password |
To enable the eG agent to connect to the XenServer API for collecting statistics of interest, this test should login to the target hypervisor as a root user. Provide the name of the root user in the Xen User text box. Root user privileges are mandatory when monitoring a XenServer 5.5 (or below). However, if you are monitoring XenServer 5.6 (or above) and you prefer not to expose the credentials of the root user, then, you have the option of configuring a user with pool-admin privileges as the Xen User. If you do not want to expose the credentials of a root/pool-admin user, then you can configure the tests with the credentials of a Xen User with Read-only privileges to the XenServer. However, if this is done, then the Xen Uptime test will not run, and the Xen CPU and Xen Memory tests will not be able to report metrics for the control domain descriptor. To avoid such an outcome, do the following before attempting to configure the eG tests with a Xen User who has Read-only privileges to the Citrix Hypervisor:
Once this is done, you can configure the eG tests with the credentials of a Xen User with Read-only privileges. The password of the specified Xen User needs to be mentioned in the Xen Password text box. Then, confirm the Xen Password by retyping it in the Confirm Password text box. |
| SSL |
By default, the Citrix Hypervisor is not SSL-enabled. This indicates that by default, the eG agent communicates with the target hypervisor using HTTP. Accordingly, the SSL flag is set to No by default. If you configure the target hypervisor to use SSL, then make sure that the SSL flag is set to Yes, so that the eG agent communicates with the target hypervisor using HTTPS. Note that a default SSL certificate comes bundled with every Citrix Hypervisor installation. If you want the eG agent to use this default certificate for communicating with an SSL-enabled Citrix Hypervisor, then no additional configuration is required. However, if you do not want to use the default certificate, then you can generate a self-signed certificate for use by the target hypervisor. In such a case, you need to explicitly follow the broad steps given below to enable the eG agent to communicate with the target hypervisor via HTTPS:
For a detailed discussion on each of these steps, refer to the Troubleshooting section of this document. |
|
Inside View Using |
By default, this test obtains the “inside view” of VMs using the eG VM Agent. Accordingly, the Inside view using flag is set to eG VM Agent by default. The eG VM Agent is a piece of software, which should be installed on every VM on a hypervisor. Every time the eG agent runs this test, it uses the eG VM Agent to pull relevant 'inside view' metrics from each VM. Once the metrics are collected, the eG agent then communicates with each VM agent and pulls these metrics, without requiring administrator privileges. Refer to Configuring the Remote Agent to Obtain the Inside View of VMs for more details on the eG VM Agent. |
|
Domain, Admin User, and Admin Password, and Confirm Password |
By default, these parameters are set to none. This is because, by default, the eG agent collects 'inside view' metrics using the eG VM agent on each VM. Domain administrator privileges need not be granted to the eG agent if it uses this default approach to obtain the 'inside view' of Windows VMs. |
|
Ignore VMs Inside View |
Administrators of some high security XenServer environments might not have permissions to internally monitor one/more VMs. The eG agent can be configured to not obtain the 'inside view' of such ‘inaccessible’ VMs using the IGNORE VMS INSIDE VIEW parameter. Against this parameter, you can provide a comma-separated list of VM names, or VM name patterns, for which the inside view need not be obtained. For instance, your IGNORE VMS INSIDE VIEW specification can be: *xp,*lin*,win*,vista. Here, the * (asterisk) is used to denote leading and trailing spaces (as the case may be). By default, this parameter is set to none indicating that the eG agent obtains the inside view of all VMs on a Citrix Hypervisor host by default. Note: While performing VM discovery, the eG agent will not discover the operating system of the VMs configured in the IGNORE VMS INSIDE VIEW text box. |
|
Exclude VMs |
Administrators of some virtualized environments may not want to monitor some of their less-critical VMs - for instance, VM templates - both from 'outside' and from 'inside'. The eG agent in this case can be configured to completely exclude such VMs from its monitoring purview. To achieve this, provide a comma-separated list of VMs to be excluded from monitoring in the EXCLUDE VMS text box. Instead of VMs, VM name patterns can also be provided here in a comma-separated list. For example, your EXCLUDE VMS specification can be: *xp,*lin*,win*,vista. Here, the * (asterisk) is used to denote leading and trailing spaces (as the case may be). By default, this parameter is set to none indicating that the eG agent obtains the inside and outside views of all VMs on a virtual host by default. By providing a comma-separated list of VMs/VM name patterns in the EXCLUDE VMS text box, you can make sure the eG agent stops collecting 'inside' and 'outside' view metrics for a configured set of VMs. |
|
Ignore Winnt |
By default, the eG agent does not support the inside view for VMs executing on Windows NT operating systems. Accordingly, the IGNORE WINNT flag is set to Yes by default. |
|
Webport |
By default, in most virtualized environments, the target hypervisor listens on port 80 (if not SSL-enabled) or on port 443 (if SSL-enabled). This implies that while monitoring an SSL-enabled Citrix hypervisor, the eG agent, by default, connects to port 443 of the server to pull out metrics, and while monitoring a non-SSL-enabled Citrix hypervisor, the eG agent connects to port 80. Accordingly, the webport parameter is set to 80 or 443 depending upon the status of the ssl flag. In some environments however, the default ports 80 or 443 might not apply. In such a case, against the webport parameter, you can specify the exact port at which the target hypervisor in your environment listens so that the eG agent communicates with that port. |
|
Report by User |
While monitoring a Citrix hypervisor, the REPORT BY USER flag is set to No by default, indicating that by default, the guest operating systems on the target hypervisor are identified using the host name specified in the operating system. On the other hand, while monitoring a Citrix hypervisor-VDI, this flag is set to Yes by default; this implies that in case of the Citrix hypervisor-VDI model, by default, the desktops will be identified using the login of the user who is accessing them. In other words, in VDI environments, this test will, by default, report measures for every username_on_virtualmachinename. |
|
Report Powered OS |
This flag becomes relevant only if the report by user flag is set to ‘Yes’. If the report powered os flag is set to Yes (which is the default setting), then this test will report measures for even those VMs that do not have any users logged in currently. Such guests will be identified by their virtualmachine name and not by the username_on_virtualmachinename. On the other hand, if the report powered os flag is set to No, then this test will not report measures for those VMs to which no users are logged in currently. |
| Measurement | Description | Measurement Unit | Interpretation | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Screen refresh latency - avg: |
Indicates the average time interval measured at the client between the first step (user action) and the last step (graphical response displayed) of this user's session. This measure maps to the 'ICA RTT' measure in Citrix Director. |
Secs |
This is a measurement of the screen lag that a user experiences while interacting with a virtual desktop. Comparing the value of this measure across users will enable administrators to quickly and accurately identify users who are experiencing higher latency when interacting with a virtual desktop. |
||||||||||||||||||||
|
Screen refresh latency - deviation |
Indicates the difference between the minimum and maximum measured latency values for this user session. |
Secs |
Ideally, the deviation in latencies over a session should be minimum so as to provide a consistent experience for the user. |
||||||||||||||||||||
|
Screen refresh latency - last: |
Represents the client latency for the last request from a user. The latency is measured based on packets sent to and from each user during a session - this includes network delay plus virtual desktop side processing delays. |
Secs |
A consistently high latency may be indicative of poor user experience with the virtual desktop. Possible reasons for an increase in latency could be increased network delays, network congestion, etc. Typically, latencies will be below 5 secs. |
||||||||||||||||||||
|
Audio bandwidth input: |
Indicates the bandwidth used while transmitting sound/audio to this user. |
Kbps |
Comparing these values across users will reveal which user is sending/receiving bandwidth-intensive sound/audio files over the ICA channel. To minimize bandwidth consumption, you may want to consider disabling client audio mapping. |
||||||||||||||||||||
|
Audio bandwidth output: |
Indicates the bandwidth used while receiving sound/audio from this user. |
Kbps |
|||||||||||||||||||||
|
Bandwidth used for video encoding |
Indicates the amount of bandwidth consumed for encoding and transmitting video content in this user’s session. |
Mbps |
High values suggest video-heavy workloads that may require bandwidth optimization. |
||||||||||||||||||||
|
Frame backlog |
Indicates the amount of time required to process, transmit, or render the display frames that are currently queued for this user’s session. |
Seconds |
A high value indicates a buildup of pending frames in the Thinwire display pipeline, suggesting encoding, network, or client-side rendering delays that can lead to screen freezes, increased display latency, and poor user experience. |
||||||||||||||||||||
|
Time taken to encode a frame |
Indicates the average time taken by the server to encode a single display frame for this user’s session. |
Seconds |
Higher values may indicate CPU bottlenecks or graphics processing constraints on the host. |
||||||||||||||||||||
|
Thinwire session degradation factor |
Indicates the percentage of display session degradation experienced by this user due to Thinwire performance issues, such as latency, frame backlog, bandwidth constraints, or encoding delays. |
Percent |
A higher value for this measure indicates that the user’s Thinwire session is experiencing noticeable degradation, which can result in poor visual quality, laggy screen updates, or reduced responsiveness. Consistently high degradation factors point to network congestion, server resource contention, or suboptimal Thinwire configuration affecting the user experience. |
||||||||||||||||||||
|
Printer bandwidth input: |
Indicates the bandwidth used when this user prints to a desktop printer over the ICA channel. |
Kbps |
Comparing the values of these measures across users will reveal which user is issuing bandwidth-intensive print commands over the ICA channel. If bandwidth consumption is too high, you may want to consider disabling printing. Alternatively, you can avoid printing large documents over the ICA connection. |
||||||||||||||||||||
|
Printer bandwidth output: |
Indicates the bandwidth used when the desktop responds to print jobs issued by this user. |
Kbps |
|||||||||||||||||||||
|
Session bandwidth input: |
Indicates the bandwidth used from this user to the virtual desktop for a session |
Kbps |
Comparing the values of these measures across users will reveal which user and which virtual desktop is performing bandwidth-intensive operations for a session.
|
||||||||||||||||||||
|
Session bandwidth output: |
Indicates the bandwidth used from the virtual desktop to this user for a session. |
Kbps |
|||||||||||||||||||||
|
Session compression input: |
Indicates the compression ratio used from this user to the virtual desktop for a session. |
Number |
Compression reduces the size of the data that is transacted over the ICA channel. Comparing the values of these measures across users will reveal which client has been configured with a very low and a very high compression ratio. In the event of high bandwidth usage over an ICA channel, you can set a higher compression ratio for the corresponding client and thus reduce bandwidth consumption.
|
||||||||||||||||||||
|
Session compression output: |
Indicates the compression ratio used from the virtual desktop to this user for a session. |
Number |
|||||||||||||||||||||
|
Frames dropped |
Indicates the number of display frames dropped for this user’s session during transmission. |
Frames/sec |
Dropped frames lead to visual stutter and degraded user experience. |
||||||||||||||||||||
|
Frames sent |
Indicates the total number of display frames sent to this user’s client during the measurement period. |
Number |
Very low values for this measure may indicate idle or stalled sessions. |
||||||||||||||||||||
|
Thinwire output/input ratio |
Indicates the ratio between output frames sent and input frames received for this user’s session. |
Percent |
An unusually high ratio may suggest excessive screen redraws or inefficient rendering. |
||||||||||||||||||||
|
Thinwire input frame rate |
Indicates the rate at which input frames generated by this user’s session are sent to the server using the Thinwire protocol. |
Frames/sec |
An unusually high value can point to excessive input activity or inefficient rendering. |
||||||||||||||||||||
|
HDX media stream for flash data bandwidth input: |
Indicates the bandwidth used from this user to virtual desktop for flash data traffic. |
Kbps |
Comparing the values of these measures across users will reveal which user has been transmitting/receiving bandwidth-intensive flash data.
|
||||||||||||||||||||
|
HDX media stream for flash data bandwidth output: |
Indicates the bandwidth used from the virtual desktop to this user for flash data traffic |
Kbps |
|
||||||||||||||||||||
|
Thinwire output frame rate |
Indicates the rate at which display frames are sent from the server to this user’s client over Thinwire. |
Frames/sec |
If the value of this measure is low, it may result in choppy screen updates. |
||||||||||||||||||||
|
Thinwire estimate bandwidth |
Indicates the estimated network bandwidth consumed by Thinwire traffic for this user’s session. |
Mbps |
High bandwidth usage can impact overall network performance and may indicate graphics-intensive workloads. |
||||||||||||||||||||
|
Session line speed input: |
Indicates the average line speed of all the sessions of this user to the desktop. |
KB/Sec |
|
||||||||||||||||||||
|
Session line speed output: |
Indicates the average line speed from the desktop to this user. |
KB/Sec |
|
||||||||||||||||||||
|
Bandwidth usage of user's session: |
Indicates the percentage HDX bandwidth consumption of this user. |
Percent |
Compare the value of this measure across users to know which user is consuming the maximum HDX bandwidth. |
||||||||||||||||||||
|
Thinwire bandwidth input: |
Indicates the bandwidth used from user client to desktop for ThinWire traffic. |
Kbps |
Typically, ICA traffic is comprised of many small packets, as well as a some large packets. Large packets are commonly generated for initial session screen paints and printing jobs, whereas the ongoing user session is principally comprised of many small packets. For the most part, these small packets are the highest priority ICA data called Thinwire. Thinwire incorporates mouse movements and keystrokes. Compare the value of these measures across users to know which user’s keystrokes and mouse movements are generating bandwidth-intensive traffic. Note: This measure will report the value 0, if Framehawk is enabled for a user. |
||||||||||||||||||||
|
Thinwire bandwith output: |
Indicates the bandwidth used from desktop to user client for ThinWire traffic. |
Kbps |
Note: This measure will report the value 0, if Framehawk is enabled for a user. |
||||||||||||||||||||
|
Thinwire JPEG image quality |
Indicates the JPEG image quality level used to transmit graphics for this user’s session. |
Percent |
Lower quality may reduce bandwidth usage but degrade visual clarity. |
||||||||||||||||||||
|
Thinwire latency |
Indicates the latency experienced by this user’s session while transmitting display data using Thinwire. |
Seconds |
High latency can cause visible lag and poor user experience during screen updates. |
||||||||||||||||||||
|
Resource shares: |
Indicates the total number of resource shares used by this user. |
Number |
By comparing the value of this measure across users, you can identify the user who is hogging the resources. |
||||||||||||||||||||
|
Frame rate: |
Indicates the rate at which frames are processed during this user session. |
Frames/Sec |
FPS is how fast your graphics card can output individual frames each second. It is the most time-tested and ideal measure of performance of a GPU. Higher the value of this measure, healthier is the GPU. |
||||||||||||||||||||
|
Framehawk frame rate: |
Indicates the rate at which frames are processed by the Framehawk virtual channel, if it is enabled for this user session. |
Frames/Sec |
The Framehawk virtual channel optimizes the delivery of virtual desktops and applications to users on broadband wireless connections, when high packet loss or congestion occurs. A high value is desired for this measure, as it indicates faster delivery of applications to users, which in turn makes for a better user experience. You can compare the value of this measure with that of the Frame rate measure of a user to ascertain whether/not the Framehawk virtual channel has indeed enhanced that user’s experience with virtual desktops. If this comparison reveals that the value of this measure is higher than that of the Frame rate measure, it is a clear indicator of the effectiveness of the Framehawk virtual channel. Note: This measure will report the value 0 if Framehawk is not enabled for a user or if the device from which the user is accessing the virtual desktop does not support Framehawk. |
||||||||||||||||||||
|
Thinwire RTT |
Indicates the round-trip time experienced by Thinwire traffic for this user’s session. |
Seconds |
High RTT values indicate network latency that can negatively impact session responsiveness. |
||||||||||||||||||||
|
Framehawk latency: |
Indicates the latency experienced by this user session when the Framehawk virtual delivery channel is used. |
Secs |
To judge the effectiveness of Framehawk, compare the value of this measure with that of the Client network latency measure for a Framehawk-enabled user. If the comparison reveals a lower value for this measure, it implies that Framehawk has succeeded in minimizing the latencies over the delivery channel. Note: This measure will report the value 0 if Framehawk is not enabled for a user or if the device from which the user is accessing the virtual desktop does not support Framehawk. |
||||||||||||||||||||
|
Framehawk network loss: |
Indicates the percentage of packet loss experienced by this user session when the Framehawk virtual delivery channel is used. |
Percent |
If the value of this measure is very low, it indicates that Framehawk has been very effective in minimizing the loss of packets that typically occur when data is transmitted or received over a channel. Note: This measure will report the value 0 if Framehawk is not enabled for a user or if the device from which the user is accessing the virtual desktop does not support Framehawk. |
||||||||||||||||||||
|
Client network latency: |
Indicates the latency experienced by this user when transmitting/receiving data over the ICA channel. This measure maps to the 'Network RTT' measure in Citrix Director. |
Secs |
A low value is a sign of the good health of the ICA channel. |
||||||||||||||||||||
|
Clipboard bandwidth output |
Indicates the bandwidth used for clipboard operations performed such as cut-and-paste, from the ICA session to this user's endpoint. |
Kbps |
|
||||||||||||||||||||
|
Clipboard bandwidth input |
Indicates the bandwidth used when performing clipboard operations such as cut-and-paste, from this user's endpoint to the ICA session. |
Kbps |
|||||||||||||||||||||
|
User's connection quality indicator: |
Indicates the connectivity of this user with the Citrix environment. |
|
The values that this measure can report and their corresponding numeric values are discussed in the table above:
Note: By default, this measure reports the Measure Values listed in the table above. In the graph of this measure however, the value of this measure is represented using their numeric equivalents only. By default, Citrix recommends a standard computation of user’s connection quality indicator as mentioned in the table below:
The detailed diagnosis of this measure reports the bandwidth utilized by each user, the latency, the protocol used to establish the session, client version, client ID, Gateway IP Address, Gateway Country, Gateway region, Gateway city, Citrix cloud infra, etc. |
