Citrix ThinWire HDX Graphics Modes – what is right for you?

Desktop Composition Redirecton (DCR) (Deprecated in XenApp and XenDesktop 7.12), ThinWire Legacy, ThinWire+, Framehawk (deprecated in Virtual Apps and Desktops 1811). Which HDX display mode should you be using? There’s no quick and easy answer as the real question is which mode will fit in to your infrastructure and business/user requirements.

  • Do you want to improve the user experience?
  • Stuck for bandwidth?
  • Increase user density on servers?
  • Upgrading Citrix deployments and not sure what to choose?

Note: When upgrading Sites, benchmark current performance metrics to get an idea of what experience users currently get. This will help you make decisions going forward and re-evaluate decisions with new deployments.

ThinWire is always evolving to keep up with hardware, operating systems, networks and other components that make up XenApp/XenDesktop. Citrix XenApp and XenDesktop 7.x provide by default policy settings that will fit most graphical experience use cases without the need for additional configuration. In XenApp and XenDesktop 7.6 FP3+ Use video codec for compression was made the default setting for client devices that supported it. In previous versions of XenDesktop 7.x DCR was enabled by default for Desktop OS machines but is now disabled by default in the latest versions. If clients did not support the default H.264 codec that is used with setting Use video codec for compression, then a fallback to ThinWire+ (ThinWire compatibility mode) occurred.

Let’s talk about how Citrix evolved from having one mode to the now current five different types of graphics modes:

Since the Windows XP/Server 2000 days the XDDM/XPDM (Windows XP Driver Model) display driver model was used right up until Windows Vista/Windows 7/Server 2008R2 which saw a new model called WDDM (Windows Display Driver Model) introduced. Even though WDDM was the new model, Windows Vista/Windows 7/Server 2008R2 OS could still make use of XDDM/XPDM. I guess Microsoft wanted to correctly transition towards the new model.

XDDM/XPDM was eventually excluded from Windows 8/Server 2012 and above leaving WDDM as the only available option. WDDM benefits:

  • WDDM partly runs in user mode. This means that if a WDDM driver fails at most the affected application will quit unexpectedly. Previously with XDDM/XPDM the whole system would crash with a blue screen error as it ran within the kernel.
  • Graphics command scheduling so more critical tasks can run in priority to improve user experience.
  • Better performance and more reliable than previous models.
  • Allows Windows to use features provided by Desktop Window Manager such as Aero effects like Aero Glass, Aero Peek, Aero Flip and more.

Note: Desktop Window Manager was introduced in Windows Vista. Prior to DWM (using old display model) each program was reponsible for updating it’s own window in the display mode. Now DWM is the one responsible.

WDDM version timeline:

  • WDDM 1.0 – Windows Vista
  • WDDM 1.1 – Windows 7
  • WDDM 1.2 – Windows 8
  • WDDM 1.3 – Windows 8.1
  • WDDM 2.0 – Windows 10

Specific enhancements introduced in each version are explained at https://en.wikipedia.org/wiki/Windows_Display_Driver_Model.

So with these changes to the driver stack within Windows, Citrix had to rewrite their graphics driver to be compatible with WDDM. The driver we are interested in is called CTXGFX.EXE. This user mode graphics driver works closely with WDDM and is responsible for encoding what you see with your eyes on the screen, when connected to a VDA and passing that data to Receiver which runs on your client device, which is then decoded and displayed.

What are the five HDX display modes I mentioned?

  • Desktop Composition Redirection (DCR) – (Deprecated in XenApp and XenDesktop 7.12)

    • Anything sent to DWM (Desktop Window Manager) is instead redirected to Receiver on the users device to perform the composition. For this reason DCR will want your bandwidth and client CPU. Not suitable on low bandwidth connections.
    • Aero must be used/enabled on the VDA for DCR to work. DWM controls Aero.
    • Can increase user density per server as client device resources are used for composition rather than the VDA.
    • A PC or thin client with reasonable CPU and a user on LAN/high WAN bandwidth connection to backend XenDesktop servers is advised. Required endpoint to be DirectX capable.
    • DCR is only supported with Windows Desktop OS using Windows Vista Aero and above. Windows 10 is currently not supported even with the release of XenDesktop 7.9.
    • Server OS is not supported.
    • Receiver for Windows 3.0+ and Receiver for Mac 11.9+ needed on end-client device.
    • To enable DCR, create a policy via Citrix Studio and set Desktop Composition Redirection = Enabled.
    • DCR does not work on an HDX 3D Pro machine because DCR depends on the Citrix WDDM driver, which is disabled in favour of a third party GPU driver which will offer a better graphical experience to the end-user.
    • DCR is now disabled by default in XenApp/XenDesktop 7.6 FP3+ however note that it was enabled by default in previous versions (7.0 to 7.6 FP2) but applied to desktop VDA only as always.
    • DCR has received a slow adoption rate by XenDesktop users. Users using XenDesktop from home may well be able to support DCR as many home connections today support the bandwidth however don’t forget about the datacentre WAN bandwidth that will also take a hit.1-min
  • H.264 –
    • Also known as ThinWire Advanced and SuperCodec, labelled as DeepCompressionV2Encoder within Director etc.
    • Uses CPU on VDA and user device to encode/decode. The first version of this codec used the nVidia GPU with HDX 3D Pro.
    • The same codec that is used by many video sites to deliver high quality video across the internet which is compressed using H.264 to save on bandwidth.
    • In XenApp and XenDesktop 7.16 and earlier, H.264 either used full screen or selectively with Thinwire+ uses the 2DRLE codec for lossless encoding of simple graphics or text regions in a typical desktop session. On the client side, Citrix Receiver uses the 2DRLE decoder for session display.
      • In XenApp and XenDesktop 7.17+, a higher compression ratio MDRLE encoder that consumed less bandwidth in typical desktop sessions than the 2DRLE codec was released. This currently requires VDAs running 7.17 and Citrix Receiver for Windows 4.11. If these prerequisites cannot be satisfied then 2DRLE is used.
    • Recommended to be used for server VDAs, WAN and mobile. Not really beneficial in a LAN environment as bandwidth is generally not an issue and enabling H.264 increased CPU consumption on the VDA.
    • Video is mainly the biggest consumer of bandwidth so needs to be delivered efficiently which is why H.264 is available.
    • Provides a high definition user experience.
    • Users on LAN/high WAN bandwidth connection to backend VDAs is advised.
    • Minimum 2vCPU/4GB RAM recommended on VDA.
    • Heavy encoding means CPU is needed to compress the data to be sent over the wire.
    • The encoding and decoding procedure results in extra CPU processing on VDA and end-user device so keep this in mind as it will affect server scalability.
    • Windows 7/Server 2008R2 VDA or newer recommended.
    • Will work so long as DCR and Framehawk are not enabled.
    • Receiver 3.4 for Windows, 11.8 for Mac, 13.0 for Linux, 5.9 for iOS, 3.4 for Android and HTML5 (StoreFront 2.1) required at a minimum.
      • Note: Receiver for Mac uses FFMPEG to decode H.264 traffic, that is until Receiver for Mac 12.5 was released, which uses the Video Toolbox Hardware Accelerated H.264 decoder with fallback capabilities to Video Toolbox H.264 software decoder or FFMPEG (due to be removed in future versions).
    • This mode is currently the default mode in XenApp/XenDesktop however in v7.9 H.264 will be used when “preferred” by default meaning when it is unpreferred you will be using ThinWire+. Personally, I’ve not been able to get a scenario where H.264 is active due to being preferred. If it was me, I would either change this setting to Use video codec when available if you want H.264 or completely disable if not. If policy Desktop Composition Redirection = Disabled is set (by default it is) H.264 is used. Also Framehawk needs to be disabled so that it does not take precedence over H.264.
    • XenApp & XenDesktop 7.11 has changed the way video codec for compression operates. In 7.9 the default was “Use video codec when preferred” which meant if using video codec compression wasn’t preferred then ThinWire+ is used. Now in 7.11 this setting means that if video codec compression is not preferred use ThinWire+ with selective H.264 (adaptive display v2). When configuring the Use video codec for compression policy setting now in 7.11+ you have the following options:
      • Use when preferred – The default, the system chooses when to use codec compression based on various factors.
      • For the entire screen – Use compression for the entire screen. For situations where heavy use of server-rendered video and 3D graphics are in use.
      • Do not use video codec – Simply disable video codec compression. This will degrade sessions that use multimedia content heavily. In an environement that does not often use multimedia you can select this option to disable the use of video codec compression. Doing so will increase server density.
      • For actively changing regions – Forces the dynamic use of compression for actively changing content on the screen and not for static or slowly changing content such as text or static images. This is a best of both worlds scenario as it helps maintain server scalability whilst compressing changing content to save on bandwidth and provide a good experience to users who need it.
    • Receiver 4.5 for Windows and Receiver 13.4 for Linux is required for selective H.264. Older Receiver clients will fallback to ThinWire+.
    • XenDesktop 7.11 has introduced H.264 hardware encoding which offloads H.264 compression on to the GPU for machines using supported NVIDIA GPU with HDX 3D Pro. This is enabled by default. This frees up the CPU potentially increasing host scalability by 30% as reported by NVIDIA in a recent scalability test. This encoding is not supported on HDX 3D Pro VDAs using selective H.264. Full-screen H.264 compression should be used on HDX 3D Pro VMs when performing hardware encoding.64-min
    • The policy to control H.264 is named Use video codec for compression and the default setting is Use video codec when available in 7.6 FP3 and Use video codec when preferred in 7.9+.
    • If maximum user density is desired, Citrix recommend you disable Show window contents while dragging.
    • Visual Quality = Lossless or Build to Lossless will disable H.264 and use ThinWire+ instead.
    • DeferredUpdateMode was introduced in Receiver for Windows 3.4+. If disabled, H.264 will not work. Some customers using PS4 may have disabled this mode via the registry to fix a refresh issue. Keep this in mind if you can relate to this issue.2-min
  • ThinWire+ –
    • Also known as ThinWire compatibility mode, Enhanced ThinWire and Enhanced Compatibility Mode.
    • Fallback for endpoints that are not compatible with the H.264 SuperCodec. This method will be used if H.264/ThinWire Advanced is specifically disabled, or the end-user device is running old versions of Receiver or lacks the CPU power.
    • This mode has lighter server requirements in terms of CPU and RAM whilst still giving the user a decent graphical experience.
    • Users on LAN/good WAN bandwidth connection to backend VDAs is advised. ThinWire+ can use significant bandwidth as you will further find out down the post. For bandwidth constrained environments you may be interested in using Framehawk or H.264 depending on the situation.
    • In XenApp and XenDesktop 7.16 and earlier, ThinWire+ or ThinWire+ with selective H.264 uses the 2DRLE codec for lossless encoding of simple graphics or text regions in a typical desktop session. On the client side, Citrix Receiver uses the 2DRLE decoder for session display.
      • In XenApp and XenDesktop 7.17+, a higher compression ratio MDRLE encoder that consumed less bandwidth in typical desktop sessions than the 2DRLE codec was released. This currently requires VDAs running 7.17 and Citrix Receiver for Windows 4.11. If these prerequisites cannot be satisfied then 2DRLE is used.
    • ThinWire+ is designed to work with older endpoints and Receiver versions which could allow some companies to get an extra year or two out of their endpoint computers saving money and avoiding the urgency to recycle hardware. Also will suit in situations where Receiver cannot be upgraded for any reason on specific endpoints.
    • Works with Windows Server 2008R2/Windows 7 VDA or newer.
    • To specifically use ThinWire+ make sure Citrix policies Desktop Composition Redirecton = Disabled and Use Video Codec for compression = Do not use video codec are set. Also make sure Framehawk is not enabled.
    • Progressive Mode, new in XenApp & XenDesktop 7.18, makes it easier to support remote connections whenever you are unsure what connection type a user will be remoting over. For example, you cannot predict that a user will always be using the same high speed WAN connection each day, especially if they roam between different areas. Previously, you may have set graphics policies to reduce bandwidth consumption, or to provide users with high end graphical sessions, but it was hard to be flexible. In 7.18, by default, Progressive Mode sets ThinWire to a progressive update mode whenever the available bandwidth falls below 2Mbps, or latency exceeds 200ms. In progressive update mode, all images are heavily compressed and text quality is reduced. Video is still managed with Adaptive Display or selective H.264
      • Progressive Mode is turned off (not on standby) when the:
        • Visual Quality policy is set to Always Lossless or Build to Lossless.
        • Preferred color depth for simple graphics is set to 8 bits per pixel.
        • Use video codec for compression is set to For the entire screen.
      • A minimum of 10 seconds is spend in progressive update mode, even if the network conditions that trigger it are momentary.
      • To change progressive mode behaviour, you can set the HKLM\SOFTWARE\Citrix\Graphics\ProgressiveDisplay DWORD value to:
        • 0 = Always off
        • 1 = Automatic (the default)
        • 2 = Always on
      • You can also change the thresholds that trigger Progressive Mode to come out of standby, by setting the:
        • HKLM\SOFTWARE\Citrix\Graphics\ProgressiveDisplayBandwidthThreshold DWORD to a value such as 4096 (4Mbps), the default is 2048 (2Mbps).
        • HKLM\SOFTWARE\Citrix\Graphics\ProgressiveDisplayLatencyThreshold DWORD to a value such as 100 (100ms), the default is 200 (200ms).
  • Framehawk (deprecated in Virtual Apps and Desktops 1811) –
    • Works on Server and Desktop VDAs 7.6 FP2 and later.
    • Designed to work in locations where users have poor connections for example Wireless connections that experience frequent interference or a lossy/high latent WAN connection. Provides a good user experience over these poor connections.
    • Works with Windows 7/Server 2008 R2 VDA and later.
    • To enable Framehawk (deprecated in Virtual Apps and Desktops 1811) set Citrix policy Framehawk display channel = Enabled. There are also requirements to open UDP ports 3224/3324 as Framehawk uses UDP.
    • Default UDP ports mentioned above can be changed by Citrix policy.
    • Firewall ports should be opened from client Receiver to VDA, opening any ports on firewalls that the connection traverses.
    • Do not enable for example DCR with Framehawk as it will not work. Framehawk will take precedence over other graphics modes if for example DCR is also enabled. This precedence however relies on the VDA being version 7.6 FP2+, Receiver for Windows 4.3.100 or IOS 6.x or higher being used and connection on the required UDP ports being possible.3-min
  • Legacy Graphics Mode – (Deprecated in XenApp and XenDesktop 7.12)

    • Provides good user experience and highest endpoint compatibility at the expense of user experience.
    • Compatible with Windows 7/Server 2008R2 VDA only.
      • Note: Windows 7 and Windows Server 2008 R2 can not be install on VDA 7.16+.
    • It is advised that Legacy Graphics Mode should be your first choice when you have Windows 7/Server 2008 R2 VDAs because this mode is based on the older XPDM driver model we talked about above and is more efficient for these OS versions.
    • To enable this mode, set Citrix policy Legacy graphics mode = Enable.4-min

Still unsure what to use?

This is exactly why Citrix (with 7.6 FP3 Group Policy Management package 2.5.0.0) have created some additional Citrix Policy templates that cover most display/graphics use cases. Citrix recommend you use one of these templates based on your requirements and if you need to tweak the policy slightly you can. Making use of templates will also reduce the chance of mistake which is possible if you are creating policies yourself. Note that these templates contain other settings apart from graphics related policies which compliment each other.5-min

The new FP3 policy templates are:

  • High Server Scalability –
    • Uses ThinWire+.
    • Allows you to offer a good experience to users whilst maximizing the number of users you can host on a single server.
    • Turns off video codec compression to achieve server density.
    • Offers a good mix up between server scalability and user experience.
    • To be used on Windows 8+, Server 2012+ VDA.
    • The experience with server rendered video playback will be reduced however the majority of applications will not be affected.
    • Setting such as Windows Wallpaper and Menu animations disabled. Default printer mapping only configured.
    • Limits FPS to a maximum of 16FPS.
    • Focused towards office workers performing light workloads such as document browsing/processing. This is where CPU and bandwidth savings will be gained most.
    • Show window contents while dragging policy should continue to be allowed. ThinWire+ performs best when this setting is allowed.
    • Audio quality is set to medium which is expected to consume 60Kbps.
    • Windows Media fallback prevention is configured to play all content only on the client device. This makes sure that the VDA resources will not be used.
    • Only small flash video content will be played on the VDA in a fallback scenario.
  • High Server Scalability – Legacy OS –
    • Legacy Graphics Mode enabled including other policies set to achieve high server scalability.
    • Applies to Windows Server 2008R2/Windows 7 VDAs or earlier.
    • Provides results similar to XenApp 6.5 and XenDesktop 5.6.
    • Limits FPS to a maximum of 12FPS.
    • If you have a use case for DCR enabling this may also improve user density per server.
    • Audio quality is set to medium which is expected to consume 60Kbps.
    • Windows Media fallback prevention is configured to play all content only on the client device. This makes sure that the VDA resources will not be used.
    • Only small flash video content will be played on the VDA in a fallback scenario.
  • Optimized for WAN –
    • Uses ThinWire+ and other policies for optimized bandwidth efficiency.
    • Limits printing, audio, and other settings that tend to consume bandwidth when enabled.
    • DCR and H.264 is disabled in this policy template to reduce bandwidth consumption.
    • May reduce the user experience for users running highly graphical applications such as CAD.
    • Designed for VDAs running Server 2012 R2/Windows 8 and above.
    • Limits FPS to a maximum of 16FPS.
    • Default printer mapping only and Citrix Universal Print driver is enabled for all printers.
    • Should be used for task workers in remote locations or those sharing WAN that do not depend much on video content, rather the task worker uses more basic applications that aren’t graphically intense such as word processing applications. Reason being the frame rate in this policy template has been limited to 16FPS plus H.264 is not enabled so regular video watching is not advised.
    • Do not use this policy if users continually view multimedia. If you notice poor user experience when using this template then users may be viewing multimedia regularly. You can enable H.264 video codec compression using this template however you should conduct tests before comitting to production.
    • Settings such as Desktop Wallpaper and menu animations are disabled in this template.
    • Audio quality is set to low which is expected to consume 44Kbps.
    • Windows Media and Flash multimedia redirection are enabled by default in this policy template. This reduces bandwidth and improves the user experience.
  • Optimized for WAN – Legacy OS –
    • Policies to optimize bandwidth including Legacy Graphics Mode.
    • To be used on Windows Server 2008 R2/Windows 7 VDAs or earlier.
    • Provides similar experience to XenApp 6.5 and XenDesktop 5.6.
    • Should be applied to all sessions on a server. Exceptions to policies such as printer policies can be applied at a priority user level.
    • Audio quality is set to low which is expected to consume 44Kbps.
    • Windows Media and Flash multimedia redirection are enabled by default in this policy template. This reduces bandwidth and improves the user experience.
  • Very High Definition User Experience –
    • Uses H.264 codec and other default policies to maximize the user experience. In XenApp & XenDesktop 7.11 the Use video codec for compression policy setting is set to For the entire screen.
    • Using this policy reduces user density per server and increases bandwidth consumption.
    • To relieve VDA resources, using GPU passthrough is recommended to take load of CPU and increase user density per server.
    • Enforces most policies that are enabled by default apart from High visual quality and Best quality printing which are configured to be higher than what is set by default.
    • CPUs faster than 2GHz with H.264 support required to avoid possibility of adverse effects.
    • Receiver for Windows 4.x, Receiver for Mac 11.8 and Receiver for Linux 13 required to avoid possibility of adverse effects.
    • Uses frame rate of 30FPS.
    • Audio quality is set to high (also a default setting) which is expected to consume 128Kbps.
    • Windows Media and Flash multimedia redirection are enabled by default in this policy template. This reduces bandwidth and improves the user experience.6-min

It is important to note that Flash redirection and Windows Media redirection will not work on all devices for example iPhone devices.

It is important to note that not all policies work with different graphics modes. For example, enabling DCR or Framehawk deems a lot of graphics related policies unnecessary. Most policies apply to Legacy Graphics Mode such as Maximum Allowed Color Depth and Image Caching. For a complete list see http://support.citrix.com/article/CTX202687.

It is also important to note that if you for example apply the High Server Scalability template to a bunch of server VDAs, you can create another policy to enable DCR, Framehawk or other graphic settings and apply it to certain users with a higher policy priority.

How do I get the new templates?

Well if you aren’t already on 7.6 FP3, only use the following if you want to upgrade to 7.6 FP3. If you are upgrading to 7.7+ etc. then there is no need to perform these steps.

  1. Download and install Group Policy Management 7.6.300 on to your DDCs and any standalone Citrix Studio console machine.
  2. Upgrade Server OS or Desktop OS VDAs to 7.6.300.

You can find all downloads over at https://www.citrix.com/downloads/.

Results:

The below tests are ones I performed and provide a rough indication of the different resources utilised when using various codecs and policy templates. These results should not be used as part of any production resource planning. When planning your own infrastructure requirements you should conduct your own testing and metric gathering.

Very High Definition User Experience

Watching a YouTube video for roughly 1 minute. H.264 enabled by default in the Very High Definition User Experience template. Audio quality high, desktop wallpaper allowed, menu animation allowed, maximum 30FPS allowed etc.

CPU usage on VDA

High – 38%

Low – 29%

Average – 33%

CPU usage on client

High – 32%

Low – 21%

Average – 25%

41-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

CPU usage on VDA

High – 25%

Low – 14%

Average 17%

CPU usage on client

High – 11%

Low – 5%

Average – 8%

42-min

High Server Scalability – Legacy OS

Watching YouTube video for roughly 1 minute. Legacy Graphics mode enabled by default in the High Server Scalability – Legacy OS template. Audio quality medium, desktop wallpaper prohibited, menu animation prohibited and FPS limited to 12FPS etc.

CPU usage on VDA

High – 11%

Low – 5%

Average – 7%

CPU usage on client

High – 22%

Low – 11%

Average – 18%43-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

CPU usage on VDA

High – 21%

Low – 3%

Average – 11%

CPU usage on client

High – 8%

Low – 6%

Average – 7%44-min

Default Settings

Watching a YouTube video for roughly 1 minute. H.264 mode enabled by default. Audio quality high, desktop wallpaper allowed, menu animation allowed and maximum of 30FPS allowed etc. Most default settings in XenApp/XenDesktop are used in the Very High Definition User Experience policy template.

CPU usage on VDA

High – 37%

Low – 33%

Average – 35%

CPU usage on client

High – 22%

Low – 12%

Average – 16%45-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

CPU usage on VDA

High – 31%

Low – 12%

Average – 20%

CPU usage on client

High – 15%

Low – 5%

Average – 9%46-min

Default settings (with DCR enabled)

Watching a YouTube video for roughly 1 minute. DCR mode enabled, audio quality high, desktop wallpaper allowed, menu animation allowed and maximum 30FPS allowed etc. Most settings in XenApp/XenDesktop are used in the Very High Definition User Experience policy template.

CPU usage on VDA

High – 20%

Low – 17%

Average – 18%

CPU usage on client

High – 32%

Low – 22%

Average – 26%47-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

CPU usage on VDA

High – 19%

Low – 9%

Average – 14%

CPU usage on client

High – 21%

Low – 10%

Average – 15%

54-min

Default settings (with ThinWire+ enabled)

Watching a YouTube video for roughly 1 minute. ThinWire Compatibility Mode enabled, audio quality high, desktop wallpaper allowed, menu animation allowed and maximum 30FPS etc. Most default settings in XenApp/XenDesktop are used in the Very High Definition User experience policy template.

CPU usage on VDA

High – 34%

Low – 29%

Average – 31%

CPU usage on client

High – 24%

Low – 18%

Average – 22%

48-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

CPU usage on VDA

High – 34%

Low – 16%

Average – 20%

CPU usage on client

High – 25%

Low – 7%

Average 13%49-min

Default Settings (with ThinWire+, DCR and H.264 enabled) – Bandwidth consumption

YouTube video playing for 1 minute at 720p.

H.264 on default settings – 259Mbit consumed.

ThinWire+ on default settings – 569 Mbit consumed. Notice how using ThinWire+ when watching a video consumes twice as much as H.264. For this reason I do not recommend ThinWire+ at all if users regularly watch videos. This mode is enabled in the Optimized for WAN/Optimized for WAN – Legacy OS policy templates. These policy templates should not be used if users regularly view multimedia.

DCR on default settings – 226Mbit consumed.50-min

H.264 on default settings – 4.3Mbit/sec average throughput.

ThinWire+ on default settings – 9.4Mbit/sec average throughput.

DCR on default settings – 3.7 Mbit/sec average throughput.51-min

H.264 Full Screen Compression vs Actively Changing (selective) vs ThinWire+ (fallback) on VDA 7.11 and Receiver 4.5

YouTube video playing for 1 minute at 720p.

H.264 full screen compression – 222Mbit consumed.

H.264 compression on actively changing regions – 748Mbit consumed.

ThinWire+ – 1.3GB consumed.65-min

Different policy templates and modes – Bandwidth consumption

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

Using Optimized for WAN policy template (ThinWire+) – 52Mbit consumed.

Using Very High User Definition User Experience policy template (H.264) – 127Mbit consumed.

Using Very High Definition User Experience policy template with DCR enabled – 146Mbit consumed.

Notice how Optimized for WAN with all the graphical and snazzy features disabled really reduces bandwidth consumption.52-min

Using Optimized for WAN policy template (ThinWire+) – 1Mbit/second average throughput.

Using Very High Definition User Experience policy temmplate (H.264) – 1.7Mbit/second average throughput.

Using Very High Definition User Experience policy template with DCR enabled – 1.7Mbit/second average throughput.53-min

DCR Graphics Quality policy – Bandwidth consumption

There is a setting called Desktop Composition graphics quality which compliments the DCR mode. This policy determines the quality of graphics for DCR. You can set this to Low, Medium (Default), High or Lossless.

Look at the bandwidth consumption below when lossless is enabled. It takes up over 90Mbit more than when I tested with medium graphics quality.

DCR on default settings with graphics quality set to lossless – 331Mbit consumed.58-min

DCR on default settings with graphics quality set – 3.8Mbit/second average throughput.59-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

DCR on default settings with graphics quality set to lossless – 122Mbit consumed.61-min

DCR on default settings with graphics quality set – 1.5Mbit/second average throughput.62-min

DCR Graphics Quality policy – CPU consumption

Watching a YouTube video for roughly 1 minute. DCR Mode enabled with default settings. DCR graphics quality set to lossless.

CPU usage on VDA

High – 39%

Low – 32%

Average – 34%

CPU usage on client

High – 25%

Low – 21%

Average – 23%

60-min

General opening of applications, typing, saving, and navigating through menus etc. for a few minutes.

CPU usage on VDA

High – 19%

Low – 7%

Average – 13%

CPU usage on client

High – 25%

Low – 12%

Average 17%63-min

FPS

Quick note of some FPS statistics when using different modes. All using default settings apart from FPS maximum which is set to 60FPS with a minimum of 20FPS.

ThinWire+ on default settings – Maximum of 25FPS.56-min

DCR on default settings – Maximum of 30FPS.55-min

H.264 on default settings – Maximum of 29FPS.

Note: Good site to test FPS – https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/fishbowlie/

Note: FPS can be affected by machine specifications on either end. Also can be affected by components such as power management features on endpoint devices.

Note: Receiver for Mac 12.5 uses OpenGL to render video which allows for high FPS and less CPU consumption for better performance. Previous versions uses the Core Graphics API. This is only applicable currently to desktop sessions.

Framhawk over the WAN.

Whilst I have nothing to show you here, take my word that Framehawk is really impressive for WAN connnections that are latent and/or come with packet loss and jitter.

Use WANem to emulate the scenario of a highly latent link between VDA and end-client to see for yourself. WANem can be downloaded here http://wanem.sourceforge.net/ and installed as a virtual appliance on the likes of Hyper-V, XenServer and vSphere.

What HDX graphics mode am I actually using?

There are five different ways to find out:

  1. Using WMIC commands.
    1. ThinWire+ = wmic /namespace:\\root\citrix\hdx path citrix_virtualchannel_thinwire get /value
      1. Component_Encoder=CompatibilityEncoder
      2. IsActive=Active7-min
    2. ThinWire Legacy Mode = wmic /namespace:\\root\citrix\hdx path citrix_virtualchannel_graphics get /value
      1. Policy_LegacyGraphicsMode=TRUE
      2. IsActive=Active8-min
    3. H.264 = wmic /namespace:\\root\citrix\hdx path citrix_virtualchannel_thinwire get /value
      1. Component_Encoder=DeepCompressionV2Encoder
      2. IsActive=Active9-min
    4. DCR = wmic /namespace:\\root\citrix\hdx path citrix_virtualchannel_d3d get /value
      1. IsActive=Active
      2. Policy_AeroRedirection=TRUE10-min
    5. Framehawk = wmic /namespace:\\root\citrix\hdx path citrix_virtualchannel_framehawk get /value
      1. IsActive=Active
      2. IsPresent=TRUE11-min  13-min
  2. Using Citrix Director 7.6.300.2, simply view an active session and click on Details.
    1. ThinWire+15-min
    2. H.26416-min
    3. Framehawk – Note it is normal to see Virtual channel state = Idle even when the VDA is being actively used.Thinwire-min
    4. DCR57-min
  3. Using the Site Graphics Mode script.
    1. Download the script from https://citrix.sharefile.com/share?cmd=d&id=s81ffd4452d941b78#/view/s81ffd4452d941b78. The script has been updated to include FrameHawk and VDA version number to differentiate between compatibility modes uses pre and port 7.6 FP3.
    2. Copy the script over to a controller, run PowerShell ISE as an administrator.17-min
    3. Type asnp citrix.* then browse for and open the HDX_Graphics_7.6_Updated script.18-min19-min
    4. Click Run Script (F5) and enter your controller name, desktop count (how many desktops you want to query) and output filename/path in .CSV format. You need to make sure RPC communication in to the VDA machines is enabled. This is normally blocked by Windows Firewall. Open RPC Dynamic Ports to allow access.
    5. Locate and open the captured CSV file to display the results.20-min
  4. Using the Remote Display Analyser application.
    1. Download RDAnalyzer from https://www.rdanalyzer.com/downloads/. Two editions are available for dowload (Lite/Sponsored). The sponsored version has the ability to switch codecs live without any log off.
    2. Extract and run RemoteDisplayAnalyzer.exe on a desired VDA. No install is required which is a bonus. Notice how the application also displays some useful real-time information such as FPS, CPU% used by encoder, bandwidth output etc.21-min
      1. ThinWire+22-min
      2. Framehawk23-min
      3. H.264 Thinwire24-min
      4. Desktop Composition Redirection25-min
  5. Using the HDX Monitor application.
    1. Download HDX Monitor from https://cis.citrix.com/hdx/download/ select Current Version and either choose to dowload the offline installer (MSI) or online installer.26-min
    2. Double-click the .MSI or .EXE. The next few steps follow installing the online .EXE installer.27-min
    3. Click Install. Install HDX Monitor on a machine such as a management tools machine.28-min29-min
    4. Once the application launches you will be asked to specify a VDA name to query. Enter a computer name that is reachable from the machine you have installed HDX Monitor on.
      1. Prerequisite 1: For HDX Monitor to query a VDA, you must run winrm qc on the VDA if not already cofigured. WinRM configures firewall exceptions/makes sure the WinRM service is running and such. Some Operating Systems such as Windows 7 run this service automatically and WinRM is automatically configured on servers such as 2012 R2.31-min
      2. Prerequisite 2: For HDX Monitor to query the Event Log to get DCR logs etc. you need to enable Remote Event Log Management through the VDA’s firewall.32-min
    5. Enter a computer name and click Open.30-min
    6. Desktop Composition Redirection enabled and then disabled33-min 34-min
    7. Thinwire+35-min36-min
    8. Framehawk37-min
    9. Legacy Graphics Mode38-min
    10. H.26439-min 40-min

Update: The ThinWire Advanced encoder will show as “deprecated” now when using WMIC, HDX Monitor etc. as shown below on a 7.11 VDA.66-min WMIC has some new bits of information such as the Policy_UseVideoCodec=. Notice how it reports the policy setting as set within Studio (Actively Changing Regions). 68-min

Tips:

If you can’t get one of the graphics modes to apply, restart the affected VDA.

DCR will still be enabled by default if you have upgraded XenDesktop to 7.6 FP3 but the VDAs on your XenDesktop machines have not been upgraded to FP3. In this case you need to specifically disable DCR via policy until you upgrade VDAs to 7.6 FP3 at which stage the policy can be left unselected.

If you are having issues with DCR starting or notice it is not active when you log on, open Event Logs on the VDA and navigate to Applications and Service Logs -> Citrix -> Graphics -> Vd3d -> Admin.

When trying to launch a VDA from another VM, probably not going to work..14-min

Now that looks better!12-min

As explained in https://www.citrix.com/blogs/2015/10/23/thinwire-compatibility-tuning-lowering-your-bandwidth-even-further/ lowering the color depth when using ThinWire+ will reduce your bandwidth consumption and may not even look any different to your end user. Keep in mind that whilst many applications are more graphic intensive today, some still aren’t. Because some still aren’t, you could make use of lowering the Preferred color depth for simple graphics policy. Think of applications that aren’t graphically hungry such as word processing applications or applications you don’t want to waste too much bandwidth on even if they are capable of being graphical. If users only generally use such applications this policy may be of interest. This policy works on 7.6 FP3 VDAs+ and will work as long as H.264 is disabled.


44 Comments

  • Trentent Tye

    July 23, 2016

    Awesome, informative article!

    I did some perf differences between the 3 thinwire advanced encoders (CompatibilityMode, DeepCompressionEncoder and DeepCompressionV2Encoder) for some more info:

    https://theorypc.ca/2015/09/04/performance-differences-in-citrix-hdx-thinwire-encoders/

    Reply
  • Jasper

    July 23, 2016

    Wow. Great round-up. Very thorough. I would add that it’s probably best to avoid Framehawk at this point though – Citrix have stopped developing it and are dropping support for it in the near future.

    Reply
  • Samuël

    September 6, 2016

    Impressive and very useful article. Thanks!

    One question: I’ve configured to use Thinwire+ on 2012R2 VDA’s. However it seems that when starting a session all or most of the session are using the CompatibilityEncoder, but after a couple of time many sessions are switched to DeepCompressionv2Encoder.

    ThinWire+ is configured in a user GPO that applies to all users that log on into the 2012R2 VDA. Any idea?

    Reply
    • Samuël

      September 28, 2016

      Update: the issue above was with 7.6 FP3 VDA’s. After upgrading to 7.9, all sessions keeps using the CompatibilityEncoder.

      Reply
  • George Spiers

    September 6, 2016

    What version of XenApp/XenDesktop are you using? In version 7.9 H.264 is preferred by default. If clients do not support H.264 or the scenario doesn’t prefer H.264 then ThinWire+ will be used. If you don’t want to use DeepCompressionV2Encoder aka H.264 at all, disable it completely using a policy applied to the 2012R2 VDAs.

    Reply
  • Samuël

    September 28, 2016

    Today I saw that tools as RDAnalyzer, HDX monitor and so on doesn’t display correct/meaningful data when being used for VDA 7.11 sessions. It seems that the WMI data between 7.11 and 7,6FP3-7.9 VDA’s differ.

    Is that also your experience?

    Reply
    • George Spiers

      September 29, 2016

      Sort of yes the ThinWire Advanced encoder is showing as deprecated however Legacy Graphics Mode, DCR etc. will remain the same and can be viewed as normal using the likes of WMI/HDX Monitor.

      Reply
  • Rasmus Raun-Nielsen

    October 10, 2016

    Great article, I enjoyed reading it – very thorough!

    A minor question, though: Is the screenshot for the ThinWire+-mode in Director correct? It seems to be taken from the Legacy Graphics (“Graphics – Thinwire”) instead

    Reply
    • George Spiers

      October 10, 2016

      Well spotted 🙂 I have updated.

      Reply
  • Chris Calaf

    October 31, 2016

    Great post!

    When query WMI in XD7.11, If the policy is set to set to UseVideoCodecIfPreferred but Component_VideoCodecUse = FullScreen does that tell me the policy is not being applied correctly?

    Reply
    • George Spiers

      November 3, 2016

      Yes I would expect it to say Component_VideoCodecUse=ForActivelyChangingRegions.
      Also check that Policy_UseVideoCodec=UseVideoCodecIfPreferred

      Restart the VDA and try again.

      Reply
  • Smithf780

    December 6, 2016

    Valuable information. Fortunate me I discovered your web site by chance, and I am surprised why this coincidence didn’t happened in advance! I bookmarked it.

    Reply
  • Agouram

    July 29, 2017

    Thank you very much indeed for this insight about HDX!
    This is really becoming confusing and challenging to keep up to date with the successive releases.
    Any other article about “modern OSs” Windows 10 and Windows Server 2016.

    Reply
    • George Spiers

      July 29, 2017

      What sort of articles? Windows 10 and Windows Server 2016 make use of H.264 and ThinWire+ in the lastest versions of XenApp and XenDesktop. A common policy to implement is “ThinWire+ with Selective H.264” which gives a balance of good user experience and server density. You should also be aware that Citrix released “HDX Adaptive Transport” which uses UDP instead of traditional TCP to transport ICA/HDX traffic. The result is lower bandwidth and a better experience over latent connections. See https://jgspiers.com/hdx-enlightened-data-transport/

      Reply
  • Viktor

    September 11, 2017

    We have an 7.9 environment with ThinWire+. After an update to 7.15 we see
    “Component_Encoder=Deprecated” if we use the WMI command.

    But you wrote that ThinWire Advanced is “deprecated”.

    Is this a display bug?

    Reply
    • George Spiers

      September 11, 2017

      Thinwire Advanced aka H.264 compression is not deprecated in any way. What I meant is the WMIC value beside “Component_Encoder” shows as deprecated in later releases from 7.11 onwards. In 7.11 Citrix released Adaptive Transport v2 which allows you to enable H.264 compression on certain parts of the screen and ThinWire+ on the remainder. I think this is why Component_Encoder now shows as “Deprecated”. You simply do not use that value to detect if ThinWire+/H.264 is in use. Have a look at the value beside “Policy_UseVideoCodec”. It will show as “ActivelyChangingRegion” or “DoNotUseVideoCodec” for example depending on what you have set under Citrix policy “Use video codec compression”. Basically, ThinWire+ is the default all round for W8/WS2012 VDAs and you have the option to apply some H.264 compression into the mix if you wish.

      Reply
  • edu-mailbox

    November 3, 2017

    Citrix Receiver You can utilise the latest or older Citrix Receiver s including the HTML5 Receiver with Thinwire Compatible Mode encoder.

    Reply
  • Matheen

    November 13, 2017

    Hi George, Nice article. I have XD 7.15 LTSR on 2008 R2 VDA (7.15 VDA). I have Framehawk disabled and has “use video codec for full screen” policy enabled for testing.
    I have users connecting from LAN and also from VPN latency connections. one or two users complaining on graphic performance. When I run HDX monitor, I see my graphics only as “ThinWire” not thinwire+ or H264. I have below policies enabled (from HDX monitor)
    Pol_movingimagecomp = True
    Pol_usevideocodec – usevideocodecifavailable
    Pol_visualquality – Medium
    Is_active = True

    I have two questions
    * Which display mode is being currently used?
    * Is this display mode good for high latency (~250ms) connections?

    Reply
    • George Spiers

      November 13, 2017

      Hi Matheen.
      That looks like a normal value for “Pol_usevideocodec”. What you want to lookk for is – “Component_VideoCodecUse = FullScreen”.
      Also, I would suggest reading up on Adaptive Transport, which is going to help you with those highly latent connections.
      https://jgspiers.com/hdx-enlightened-data-transport/

      Reply
  • Matheen

    November 14, 2017

    Thanks George for the reply. I checked and it is showing as FullScreen. I have also seen your article on Adaptive Transport; looks promising. As my users are coming through NetScaler, is it possible to turn on Adaptive transport selectively for small set of users? If yes, does it through Citrix policy for adaptive transport and assigning to group of users and assign higher priority? Thanks

    Reply
    • George Spiers

      November 14, 2017

      Adaptive Transport is controlled by Citrix policies but can only be applied to VDAs and not individual/groups of users.

      Reply
      • Matheen

        November 15, 2017

        Does it mean that it is either for all or for none? I understand it has fallback feature to TCP. But are you saying that it is not possible to separate set of users (unless you create separate delivery group and apply policies to that VDAs and request users to test?)

        Reply
        • George Spiers

          November 15, 2017

          That’s right, or you could use tags so that only certain VDAs from a single Delivery Group receive the policy. You can also use tags so only certain users connect to those VDAs. That said, you should apply it to all users, even if they have no latency, I don’t see a benefit of not doing that!

          Reply
  • Matheen

    November 15, 2017

    Thanks. I will give it a try. I need to upgrade my NetScaler from 11.1 to 12 to use the Adaptive transport I believe (as my connections are through NetScaler).
    In my NetScaler, I had xa_xd profile attached to my access gateway vserver. After performance issues, I changed it to WAN profile. Will this be ok?
    Finally Can you point me to your article which explains about tags?

    Reply
  • George Spiers

    November 15, 2017

    Tags are here: https://jgspiers.com/desktop-application-restrictions-tags/
    And yes, you should upgrade to the latest 11.1 version of NetScaler (build 55.13) or 12.0 build 53.13. Also, the XA_XD Profile was specifically configured to handle ICA traffic (I use it myself on all NSG builds) so it is recommended to use this profile, but if you are seeing better performance through another profile then go for that.

    Reply
  • ArnaudLabiche

    June 7, 2018

    Hi, interesting article.
    But not sure this is true:
    Windows 7 and Server 2008 R2 are not supported as VDAs in XenApp and XenDesktop 7.12+.

    VDA 7.16+ will not be supported on 2008R2/W7 but you can still have VDA 7.15 on these legacy OS even with core servers on 7.17.

    Reply
    • George Spiers

      June 7, 2018

      Yes that is right, I tidied the wording up to make it more understandable. You can run W7/2008R2 on 7.15 VDA, and Legacy graphics mode was removed in a 7.16 Site.

      Reply
  • Ray

    July 1, 2018

    Wow amazing article.
    I am wondering what tool are you using to get the stats?
    Login VSI?

    Reply
    • George Spiers

      July 1, 2018

      Thanks, I used a mixture of WireShark, perfmon, Director etc.

      Reply
  • Rikesh

    September 13, 2018

    Hi Amazing article

    for 7.15 Vda with Hdx 3d pro vgpu, what policies are best practice using windows 7.

    for non gpu vda using windows 7, is it ok to use legacy graphic mode and disable dsr for 7.15?

    Reply
    • George Spiers

      September 14, 2018

      Citrix recommend using Legacy Graphics mode for Windows 7 VDAs. In terms of HDX 3D Pro, I usually up the target frame rate to 60fps, and increase the minimum image quality. Citrix have a “Very High Definition User Experience” template you can use to create a policy from, then tweak to your needs.

      Reply
  • Rikesh

    September 14, 2018

    thanks jg, im assuming legacy graphics doesnt apply for windows 7 with gpu? as the template for high def user experience has it disabled…

    Reply
    • George Spiers

      September 14, 2018

      It does apply to W7, maybe Citrix did not want to it include it in the template as it is not supported on WS2012 R2, W10 etc.

      Reply
  • Rikesh

    September 14, 2018

    Thank you, does Thinwire work with Windows 7 VDA 7.15, what is better to use Framehawk or Thinwire?

    Reply
    • George Spiers

      September 14, 2018

      Citrix recommend using Legacy graphics mode for Windows 7. Framehawk is designed for remote users, who may experience high latency and packet loss. ThinWire+ should be used for WS2012/W10+

      Reply
  • Manoj

    February 9, 2019

    Hi George,
    Firstly, thank you so much for detailing the information surrounding the plethora of settings that Citrix seems to have been adding..

    I am using XD 7.15CU2 on Win7 VDA and users are complaining about slow response when using scroll lists in applications. I have used the WAN Optimized Policy Template for configuring the Graphics etc settings.

    Am I right to think I must use the Legacy OS Template instead to improve the user experience which enables the legacy graphics mode?

    Best,
    Manoj

    Reply
    • George Spiers

      February 11, 2019

      Hi Manoj. Yes enable the “Legacy Graphics Mode” policy setting and see how that goes for you. It is advised to use with on W7 VDAs.

      Reply
  • Manoj

    February 12, 2019

    Thanks for your reply. I enabled “Legacy Graphics Mode” in the computer policy. Actually talking to the user the complaint was actually to do with tabbing the fields and typing or deleting characters in a text box. So I am not sure if this related to Legacy mode?

    in Director I am seeing Legacy Mode is enabled but some how Graphics – Framehawk shows as enabled and Graphics – Thinwire is disabled. Shouldn’t it be the other way round.

    Reply
    • George Spiers

      February 12, 2019

      Use the HDX Monitor tool, it’s easier to interpret: https://support.citrix.com/article/CTX135817
      It should show Legacy Graphics Mode as being active.
      Framehawk is being deprecated by Citrix so the “Framehawk display channel” policy should be disabled, unless you have a need for it to support remote connections.

      Reply
      • Manoj

        February 13, 2019

        I got the HDX Tool and also got the RDA Tool and set down to understand what was happening. In light of the user pain, I decided to use the Very High Definition User Experience template and configured the policy and released it to a couple of users for testing. We have a remote office site with a 1Gbps link and it is hardly used so the aim is to provide the best experience to users who connect to a Call Center Win7 VDI session and use an application which the users do heavy tabbing of fields and enter text and use keystrokes to move around different menus. The initial feedback was they have seen an improvement.

        While monitor the session latency in Director and also in RNA tool they are matched and I have the Thinwire active but one thing I am observing is although the latency is under 4ms, the ICA RTT tends to hover between 15-70ms. The Endpoint is a Win10 and doesn’t see utilization beyond 15-20% CPU and lost of RAM and the same is true on the VMware hosts they are only hosting the VDI no other workloads.

        Any light you can shed on how to find out where the ICA RTT latency could be stemming from? Could it be just the sheer amount of keystrokes the user is continuously sending along with the screen updates are getting delayed on the return path? Any way to investigate this?

        Reply
        • George Spiers

          February 13, 2019

          ICA RTT typically is affected by client processing time of ICA traffic, VDA processing time, and the network latency.
          The Very High Deinition policy template disables Legacy graphics mode. It enables full screen H.264 compression which will probably affect your ICA RTT times. Given you have already deployed a policy from this template, you should edit it and again enable Legacy graphics mode and disable “Use video codec for compression”. See how users find that. If there is no difference or the experience is worse, disable “Legacy graphics mode” and then enable “Use video codec for compression”, setting it to “Use when preferred”. Also as a test try lowering the “Visual quality” setting to Medium or Low. Since it appears that data entry is the main function, your users may not notice any visual difference and it will reduce bandwidth requirements.

          Reply
  • Tore Skaara

    February 22, 2019

    Great article George 🙂 Do you know if there is there any way of “forcing” the ctxgfx.exe to use less cpu and more gpu? We are seeing high cpu usage from the cfxgfx.exe process on some customer systems with GPU enabled XenApp servers (on-prem XenApp, XenServer, NVIDIA M10 cards). The users are given XenApp sessions with GPU to improve the multimedia experience (they are using a lot of YouTube, Google Chrome etc. for eLearning purposes). As they are primarily using thin clients (T530), they will not be able to benefit from the BCR (Browser Content Redirection) feature in the same way as a local workstation/laptop. Even though the GPU is utilized, the high CPU usage is limiting the user density and affecting performance. Any tips to get me in the right direction?

    Reply
    • George Spiers

      February 22, 2019

      Have you investigated the policy “Use hardware encoding for video codec”/NVENC? I assume you are running H.264 selectively or full screen.

      Reply
  • Rahul Gupta

    April 3, 2020

    I have set the High density policy via GPO , where FPS is set to 16.
    Is there a way I can actually locate this value in the registry, to be sure its set to this value?

    I have been unable to locate the registry key for this, any help is appreciated.

    Reply

Leave a Reply to George Spiers Cancel reply