One of our really experienced experts has just done a blog on some evaluation he did on Citrix’s hot new graphics mode: http://trentent.blogspot.ca/2015/09/performance-differences-in-citrix-hdx.html. Now this guy knows what he is doing but I’m a little worried others might not fully understand what has been done or the implications for the results. Trent did some tests flipping the encoder via a registry key. We do not encourage users to play with registry keys, occasionally they can prove useful to tweak a system, but really if that is being done we should be exposing the control via properly documented policies.
The 3D Pro VDA and the Std-VDA are under the covers very similar in the graphics remoting but they are configured for very different hardware and use cases. The 3D Pro VDA is usually used with high end graphics and the standard VDA (Std-VDA) with more regular 2D desktops and office like applications. As such not just the encoder but also other defaults are different, such as encoder speed, image quality settings etc. Basically it’s not just about the encoder.
The new graphics mode “Thinwire plus” (thinwire compatibility mode) is designed with an ultra-low CPU footprint and was initially targeted at 2D workloads focussing on bandwidth optimisation and the user experience around with lots of scrolling, moving windows etc. Whereas the H.264 based encoders have been targeted at high-end multimedia, video, 3D CAD applications. We’ve actually blurred the distinction with a whole raft of 3D optimisations though in “thinwire plus”. The encoder is only a small part of the VDA configuration though and we didn’t envisage just that parameter being varied, whilst it’s a data point on the underlying capabilities of the graphics encoders I’d really prefer to direct less experienced users to a more realistic benchmark where all the graphics policies are set mindful of the hardware and network constraints and the workloads. In XenDesktop/XenApp 7.6 FP3 we have tried to make this easier by adding more out of the box templates to Studio, so an admin can drop in a template (a collection of policies – that include the encode setting but also others) as a good starting point for what they are trying to achieve.
Hidden away in the product documentation for XenDesktop/XenApp 7.6 FP3, you will find documentation on new built-in templates for use cases (the documentation is here), at the time of writing the supplied built-in templates cover uses cases including:
- Very High Definition User Experience. This template enforces default settings which maximize the user experience. Use this template in scenarios where multiple policies are processed in order of precedence.
- High Server Scalability. Apply this template to economize on server resources. This template balances user experience and server scalability. It offers a good user experience while increasing the number of users you can host on a single server. This template does not use video codec for compression of graphics and prevents server side multimedia rendering.
- High Server Scalability-Legacy OS. This High Server Scalability template applies only to VDAs running Server 2008 R2 or Windows 7 and earlier. This template relies on the Legacy graphics mode which is more efficient for those operating systems.
- Optimized for WAN. This template is intended for task workers in branch offices using a shared WAN connection or remote locations with low bandwidth connections accessing applications with graphically simple user interfaces with little multimedia content. This template trades off video playback experience and some server scalability for optimized bandwidth efficiency.
- Optimized for WAN-Legacy OS. This Optimized for WAN template applies only to VDAs running Server 2008 R2 or Windows 7 and earlier. This template relies on the Legacy graphics mode which is more efficient for those operating systems.
- Security and Control. Use this template in environments with low tolerance to risk, to minimize the features enabled by default in XenApp and XenDesktop. This template includes settings which will disable access to printing, clipboard, peripheral devices, drive mapping, port redirection, and Flash acceleration on user devices. Applying this template may use more bandwidth and reduce user density per server.
There is a very good whitepaper written by Marcel Calef that goes into the details of why policies are set in these templates, which in my opinion is a must read for any Citrix System Administrator, available here: http://support.citrix.com/article/CTX202330
These templates control the encoder type (for example the optimised for WAN and high-server scalability use the new thinwire compatibility mode) but also other policies likely to interact or have dependencies. Really I’d encourage users to consider controlling their benchmarking form policies or policy templates. Unfortunately at the moment the studio interface shows all grpahics policies even if they only pertain to legacy graphics mode and in fact all our newer modes require very little configuration, with most policies applying to legacy graphics mode only, something I blogged about – here.
Along with XenDesktop/XenApp 7.6 FP3, we’ve released a CTX article linked to from the Studio Console where we are adding additional templates optimised for Cloudbridge, HTML5 and other uses – it’s really worth checking out: http://support.citrix.com/article/CTX202000
Our Framehawk and H.264 modes differ from thinwire based technologies significantly in that they are opportunistic, if bandwidth is available they will use it to raise image quality as far as they can whilst maintaining frame rates. It is possible to add in bandwidth caps but it’s a very different philosophy to the thinwire architecture (legacy mode and thinwire compatibility mode). With thinwire technologies image quality parameters are set up, upfront and bandwidth is indirectly essentially capped. Being based on completely different compression techniques it’s also a very subjective assessment for image quality, some users find artefacts of H.264 less or more acceptable than those from the thinwire technologies based on their application and usage.
I suspect Trent picked up the dodge of flipping the encoder type from another blog about a demo we tweaked that I wrote, but really it’s naughty and you shouldn’t fiddle with registry keys! Configuring a system via registry keys can be unsupported and users can get themselves into a lot of trouble, my graphics manager wasn’t best pleased with my blog and did warn me that I was leading folk astray – he had a good point!
So folks, please be really careful when benchmarking!
Want to learn more?
- Read about how to turn thinwire compatibility mode on: https://www.citrix.com/blogs/2015/10/09/a-big-leap-in-ica-protocol-innovation-for-citrix/
- Read about how to lower bandwidth further: https://www.citrix.com/blogs/2015/10/23/thinwire-compatibility-tuning-lowering-your-bandwidth-even-further/
- Read about Cloudbridge optimisations: https://www.citrix.com/blogs/2015/10/26/an-unbeatable-combo-cloudbridge-xendesktop-thinwire/
- Read more about templates and configuring thinwire compatibility and other modes, when to choose it: https://www.citrix.com/blogs/2015/10/26/how-and-more-importantly-why-should-you-care-about-the-new-hdx-thinwire/
Virtually Visual 
Leave a Reply