RDP protocol improvements in Windows 10

Intro
As you might know the RDP protocol in Windows 10 consists of different type of codecs (both proprietary and standardized video compression codecs). They belong to a broader set of technologies also known as RemoteFX. There are currently 2 type of codec configurations possible in Windows 10:

  • A combination of different codecs, one optimized for text and one for moving graphics (like video content)
  • The full screen AVC video codec

You can configure them with policies and check which configuration you are using by checking Event ID 162 in the following eventlog location:

Applications and Services Logs -> Microsoft -> Windows -> RemoteDesktopServices-RdpCoreTS -> Operational

  • Initial profile 2 means you are using the codec combination
  • Initial profile 2048 means you are using the full screen AVC codec

Both configurations gives a good out-of-the-box experience with a high level of quality. The full screen AVC codec implementation is pretty neat because they managed to leverage hardware encoders that normally only supports 4:2:0 encoding to reach a 4:4:4 quality level. While 4:2:0 compression is ideal for video content, 4:4:4 quality is needed to make text and still images sharp without blurry side affects. The full screen AVC codec implementation operates best when encoding can be done in hardware (GPU), it can however work with software based encoding (emulated GPU) but that will result in increased CPU utilization. Good to know is that the new HTML5 based web client always leverages the full screen AVC codec implementation.

(v)GPU
You might have heard that RemoteFX vGPU has been deprecated in Server 2019. Times have changed and GPU virtualization technologies have matured making the API intercept based technologies (like RemoteFX vGPU was) a legacy technology.  But no need to get sad about this, because we will get something nice in return: GPU Partitioning or GPU-P for short. It’s still under development but sounds very promising. With this technology multiple virtual machines can leverage the GPU directly (even load balance across multiple GPU’s) and by leveraging the GPU directly Microsoft can move away from the man in the middle role where they needed to maintain the API intercept driver to support new graphic standards. For now we can only leverage the GPU directly by using DDA (GPU pass through) or use GPU virtualization technologies from other vendors.

Windows Virtual Desktop (WVD)
The new GPU-P technology also opens the door for Microsoft to implement this on Azure, which would be a very welcome feature for WVD (the new RDS infrastructure  and multi-session Windows 10 edition hosted on Azure). Hopefully Microsoft will not be supporting the GPU-P technology only in Azure like they do with the new multi-session Windows 10 for WVD edition, this will really isolate this technology preventing broader use cases. I don’t think they will be doing this because they pull away RemoteFX vGPU and should provide an alternative for it.

What happened in a year time with the RDP protocol
With almost every new Windows 10 build the RDP graphics stack is updated, there is not much information you can find about such improvements, but they are certainly there.

While doing some investigation on different Windows 10 builds I noticed the protocol version is matched with the client to enable support for the latest features (both client and servers side). You can find this version numbers in the same eventlog as described in the intro. They look like this:

The client supports version 0xA0400 of the RDP graphics protocol (Build 1709)
The client supports version 0xA0600 of the RDP graphics protocol (Build 1809)

Some of the improvements in the RDP protocol are:

  • Screen regions and content are better classified (to make optimal use of the right codec and compression algorithm)
  • Webcam redirection improvements leveraging H.264
  • Down-scaling for 4K resolutions
  • GPU-P technology (announced) the AVC codec will also benefit from this

Time for a test!
I decided to do a simple test using Remote Display Analyzer to look at the improvements and changes Microsoft made to the RDP protocol in a year time. To do this I used 2 different Windows 10 builds: The 1709 and 1809 build (without updates) this will give more a less an indication of the improvements in a year time frame.
Remote Display Analyzer now also supports WVD, but I did not use it in this test because the current WVD private preview only has its RD gateways in the US and it doesn’t make much sense to let traffic flow across the globe. Will do some more testing with WVD later when it’s GA. To check the differences in the RDP protocol between the Windows 10 builds I performed the following test:

  • A direct RDP connection to both builds
  • Connection over LAN using a Windows 10 1809 client
  • Used the out-of-the-box RDP configuration on both builds
  • Both builds running on the same infrastructure
  • The test consists of playing a short video (not full screen) and scrolling some text. Exactly the same has been done on both builds
  • Please note that this was a manual test and it’s always better to automate such tests (I recommend REX analytics for this)
  • This results come without warranty of any kind and are based on my own observations using my own infrastructure. This is only to give you an indication of the differences I observed while performing this test

The results are below:

On the left you see the results of running the test on the 1709 build and on the right the results of running the exact same test on the 1809 build. I observed the following:

  • The 1809 build used less bandwidth (almost half) while I didn’t perceived a noticeable difference in frame quality. The send frames are more or less identical
  • The reported “available bandwidth detected” is different across the builds, I’m not sure what the reason for this is, the value of this counter looks a bit inconsistent so I’m not relying to much on this one
  • Overall my perceived user experience on the 1809 build was better (more fluid and snappier screen updates)

Conclusion
While you don’t hear much about it, Microsoft still makes improvements in their remote graphics stack and they should be doing this because it’s one of the most critical success factors of the upcoming WVD platform. The 1809 build performed much better on the LAN then the 1709 build, the lower bandwidth is also great news for WAN scenarios. I’m expecting more protocol improvements inline or shortly after the WVD release, I will certainly keep an eye out on this and will write a new blog post when more information is (publicly) available. Thanks for reading!

Remote Display Analyzer 1902 released

Hi all,

Happy to announce that a new version of Remote Display Analyzer (RDA) has been released. We decided to change the format of the version number to align with new versioning standards and update cycles. The latest RDA build number is 1902.0.52.1 where 1902 is the year and month, 52 is the day of the year and 1 is the build revision. The short name is RDA version 1902. You can check the RDA version number by clicking on the about (i) button.

What’s new in Remote Display Analyzer version 1902:

  • Added new information like the Windows build number and when running on Citrix or VMware the agent version number is now also displayed
  • Next to the primary screen resolution the DPI scale has been added
  • Support for the latest VMware Horizon (7.6\7.7) versions (integration with the latest Blast API)
  • Support for the latest Citrix VDA (1811) and latest HDX updates
  • Support for Windows Virtual Desktop (WVD) and the new Windows 10 Enterprise for Virtual Desktops build (currently in private preview)
  • Added new Nvidia GPU usage information like the license type being used and the video encoder usage
  • Overall improvements and bug fixes

Below you will find some screenshots of the latest RDA version in action.

Screenshot of RDA running on Windows Virtual Desktop (private preview at the moment):

Screenshot of RDA running on the latest Citrix VDA (note the added DPI and updated Nvidia information, which is supported for all display protocols):

Screenshot of RDA running on the latest VMware Horizon agent:

All subscribers should have received a download link to the latest version, you can also download the latest version on the website by filling in the form for the community edition (free) or the subscribed edition, they point to the same executable. Thanks for reading and thanks to the community for testing, validating and providing valuable feedback!

Key considerations when designing your Windows 10 Virtual Desktop solution

Key considerations when designing your Windows 10 Virtual Desktop solution

Intro
Together with TeamRGE co-member Ryan Ververs-Bijkerk we did a short presentation at E2Evc about the performance impact of different components you will find in every Windows 10 Virtual Desktop solution. Ryan used to work for LoginVSI and is really good at performing this kind of benchmarks, you can find some of them here. We shared some benchmark results together with some key designing considerations. Because time in a presentation is always limited, this blogpost dives a bit deeper into the designing considerations around the following 5 topics:

  • Windows 10 build
  • Office build
  • Application deployment
  • Remote display protocol and (v)GPU
  • Antivirus

Please note that one of the assumptions in this blog post is that you are leveraging Windows 10 Enterprise edition.

Some design considerations also applies to other Windows 10 deployment types, so this blog post might also be worth reading when you are not designing a Windows 10 Virtual Desktop solution.

Windows 10 build

Deciding which Windows 10 build you are going to pick is one of the first design choices you are going to make. Basically you have the following 2 options:

1: Windows 10 LTSC (Long Time Servicing Channel)

This separate build of Windows 10 (also known as LTSB) is released by Microsoft for special use cases. Think of locked down and general purpose PC’s you will find for example in factories or in medical peripherals. For this use cases you might not want to leverage new features, but only stay current on security updates. A new LTSB build is released every 2 to 3 years and security updates are supported for 10 years after the release.

Please consider the following when choosing this Windows 10 build for your Virtual Desktop solution:

  • There is no Edge browser
  • There are missing features like no built-in UWP applications which your users might expect
  • You need to re-install your image when a new Windows 10 LTSB build has been released to get new features or to extend support
  • You only have to optimize your image once
2: Windows 10 SAC (Semi-Annual Channel)

This is the primary Windows 10 build which receives new features twice a year. One release around March and one around September, you can recognize the release by looking at its name, the first 2 digits are the year, the second 2 digits the month. For example the 1803 is the 2018 March release and 1809 is the 2018 September release. This may sound very obvious, but I often speak people who didn’t know this. Important to take into account is the servicing period for each release: The March release will be serviced for 18 months and the September release for 30 months. As you can see on the below print screen (source: Microsoft).

Please consider the following when choosing this Windows 10 built for your Virtual Desktop solution:

  • It includes all Windows 10 features and builtin apps
  • You don’t have to re-install your image to get new features or to extend support, you can instead just update the same image
  • Recommended is to use the September release because of its longer servicing period
  • While you can defer updates by for example using Windows Update for Business, eventually you have to go with the release waves and stay current
  • You will need to check your image optimization after each release, there might be new services or scheduled tasks that could impact your performance and server density. This was clearly noticeable on the LoginVSI benchmark across the Windows 10 builds (without optimization)

Office build

Like the Windows 10 build, you also have 2 options when it comes down to the Office build you are going to deploy in your Windows 10 Virtual Desktop solution:

1: Office365 ProPlus

The version of Office that comes with the Office365 subscription and can be downloaded and installed locally, this version is installed by a click-to-run method, which basically is a container based installation similar to App-V. This Office version is also based on a Semi-Annual update Channel (SAC), but can also be configured to receive monthly updates. The latter might not be very practical in a Virtual Desktop solution.

2: Office Stand-Alone (also known as perpetual Office)

This is the on-premises variant of Office like we used pre-cloud era. You know this Office builds by the names: Office 2013, Office 2016 and now Office 2019 has also been released. This Office build is not meant to connect to cloud services, but is intended for restricted (offline) use cases or if you have no Office365 license of course.

Deciding on which Office build you should pick depends on:

  • Licensing (which license type you are using or bound to use)
  • If you use Office365 or not
  • Application compatibility and support (add-ins, macro’s, templates, etc)

Besides above please consider and note the following when deciding the Office build for your Virtual Desktop solution:

  • When you decided to go for Windows 10 LTSC (the LTSB build), also use the Office Stand-Alone (Perpetual) build. Microsoft will stop supporting (even block) Office365 ProPlus on their Long Time Servicing Channel builds (same goes for Server 2019)
  • When you decided to go for Windows 10 SAC, you can use both Office365 ProPlus or the Office Perpetual build. You will primarily make this decision based on the current license type but also don’t forget to investigate the application landscape you need to support on your Virtual Desktop solution

The LoginVSI benchmark included Office 2013, 2016 and 2019. The results showed that Office 2016 scored better than 2013 but also better than 2019. The latter had a noticeable higher impact and it needs to be deeper investigated to check what the exact reason for this higher impact was.

Application deployment

When you are at the point of choosing a way to deploy your applications you basically have 3 options:

1: Leverage traditional application installation methods

In this option you deploy applications with MSI’s, scripts, etc. Be aware that central deployment and life cycle management can be hard to manage and when you remove applications there is often still footprint (files and registry) of the application which pollutes your image over time. Central deployment tools doesn’t solve this issue and are often not designed for Virtual Desktop solutions.

2: Leverage App-V

As you might know the App-V client is built-in Windows 10 and ready to use. You only have to enable it. App-V has a lot of great features for both VDI and non-VDI scenarios. For VDI the Shared Content Store mode is a really handy feature in combination with non-persistent images. Consider using App-V Scheduler for real-time insight, control and advanced cache management for your Virtual Desktop solution. This will make your life a lot easier. By the way App-V Scheduler is not limited to VDI and also supports RDS and Fat-client\Laptop Windows 10 deployments. App-V will be supported for a very long time, you maybe don’t hear much about it because it’s now part of the operating system and Microsoft doesn’t need to sell it as additional product any more.

3: Leverage MSIX

This application format is based on the UWP framework (also previous known as AppX format). This makes it possible to deploy applications through, for example, the Windows Store. You might want to consider if this matches your deployment strategy and if it makes sense for your VDI environment. There are similarities between App-V and MSIX, like they both run the application isolated from the OS inside a container. There will be even a way to easily convert the file format. MSIX is quite new and lacks real-time deployment and management features, good to know is that App-V Scheduler already started building support for MSIX in the product to support real-time control and management features also for MSIX. You are already a step ahead if you are managing your applications with App-V.

The LoginVSI benchmark showed that App-V and MSIX have similar application start times. This was tested with a simple PDF reader. The traditional installed instance had a lower start time, but of course that’s because there is no isolation layer that isolates the application from the OS. Also note we are talking milliseconds here and this might not even impact the perceived user experience.

Remote display protocol and (v)GPU

A Windows 10 Virtual Desktop workspace is highly secure because all information stays in the cloud or datacenter and only screen updates are sent to the client. One of the key success factors of your Virtual Desktop workspace is the configuration of your remote graphics stack. The remoting protocols from all major vendors matured over time to the point they are all very suitable for all kinds of general uses cases.

Please consider the following when designing the remote graphics stack for your Windows 10 Virtual Desktop solution:

  • Consider to apply (v)GPU power to your VDI machines, besides your applications the remoting protocol can also benefit from this. But:
  • Investigate if a (v)GPU makes sense for your workload type and if it’s really worth the investment. LoginVSI benchmark results showed us that the CPU reduction when adding a (v)GPU can be minimal for general workload types like task workers and knowledge workers. This benchmark included the latest Office versions, scrolling through data and playing a video through internet explorer
  • Don’t primarily size your VDI workspace based on (v)GPU profiles, don’t forget that a decent CPU and enough Memory is just as important. A good example are applications like AutoCAD and Revit which relies a lot on CPU also when you have a (v)GPU in place
  • Take note of the recommended memory size for (v)GPU’s: Use at least 1GB profiles for Windows 10. If you are designing your environment for heavy 3D workloads also look at the recommended GPU specs for the applications you need to support
  • Use REX Analytics to capture and analyze the perceived end user experience
  • Use Remote Display Analyzer to analyze, configure and understand your remote display protocol behavior and to verify your (v)GPU implementation

Antivirus

It goes without saying that antivirus and anti malware is an important security aspect of your Windows 10 deployment. Whether you use a virtual desktop or not, it’s important to understand the impact of your antivirus solution.
Please consider the following when designing  your Windows 10 Virtual Desktop solution:

  • Apply best practices and optimizations like: file exclusions, pre-scans, scheduled scans & the definition update interval. Especially for state-less VDI this is a very important part to invest time in
  • Consider to analyze the workspace performance before and after the antivirus solution has been implemented\enabled. In this way you know if it has an impact on your application performance or not. The pilot phase might be a good moment to verify this
  • Consider leveraging Windows Defender, it’s already build in Windows 10 and it scores really well in numerous independent virus and malware detection tests (score of 99,5%). The LoginVSI benchmark showed an performance impact when not doing any optimization at all in Defender, so please pay attention for the optimizations part (see bullet 1)
The end

Thanks for reading, hopefully this design considerations are helpful for you!

Remote Display Analyzer 3.0 released

Hi all,

We are happy to let you know that Remote Display Analyzer (RDA) 3.0 has been released!  As you might know we extended the RDA team to invest more time in building new features in RDA and to continuously add support for new remote display protocol versions and settings.

What’s new in Remote Display Analyzer 3.0:

  • Logging feature, this is a much requested feature and makes it possible to (automatically) log to an external logfile which you can use to visualize the output with for example Graphs and Power BI
  • Support for the latest Remote Display protocol configurations from all supported vendors (Microsoft, Citrix, VMware)
  • New subscriber edition (besides the free community version) to offer support and advanced features

To download RDA 3.0 and for more information visit the RDA website.

Remote Display Analyzer project update

Hi all,

With this blog post I want to update you about some changes in the RDA project.
A couple of years ago Remote Display Analyzer (RDA) was born from the idea to make the remote display protocol easy to understand and to help troubleshoot and identify remote display configuration issues. Or just to confirm that everything is configured and working properly. It’s been really amazing how much great feedback RDA received from the community and how it became a standard tool in the toolbox of virtualization engineers & consultants.

I didn’t calculate the time spend on developing RDA, but I can say a lot of time went into this project. It started small with only support for Citrix, and now it supports all 3 major display protocols (Microsoft, Citrix & VMware) and also new functionality has been added like support for NVidia to analyze the entire chain in regard to the remote display configuration.

As you might know RDA has a free community edition and extra functionality can be unlocked by becoming a member of the sponsor program. The sponsor program really helps to balance the amount of time spent into this project, so a big thanks to all the sponsors of the RDA project and also for the great feedback from the community that provides new energy to work on this project, it’s because of you that RDA is where it is today.

To solve some challenges in the current state of the RDA project a couple of things are changing, please read the below announcement on the RDA site for more information:

https://www.rdanalyzer.com/remote-display-analyzer-announcements/

Thanks for reading!

App-V Scheduler 2.6 Released

Very excited to announce the latest release of App-V Scheduler, version 2.6!

This release contains a lot of new features and improvements based on customer feedback. App-V Scheduler, started in 2014, has a large install base at customers ranging from small to large Enterprises. App-V Scheduler is a proven application life cycle management solution for Government, Finance and Healthcare organisations. Since the App-V client is embedded in the operating system we have seen a fast growth in the adoption of the App-V Scheduler solution. We also see a very high success rate in the deployment of applications with App-V 5, this is also due to the simplified architecture of the App-V client, basically the client consists of a couple of filter drivers that redirects reads and writes making the application run isolated and portable. It’s easy to adopt and learn how this technology works and because it’s already part of the operating system it’s very easy to enable and use!

App-V Scheduler 2.6 new features:

  • The Central View Console has been redesigned from the ground up and build on the latest industry standards
  • Central View now includes advanced filtering, performance improvements and new features
  • The agent is thinner and faster
  • The agent doesn’t need a service account anymore and can be configured to use impersonation
  • Machine groups based on Active Directory OU’s are now supported and it’s possible to provide friendly names for machine groups
  • Multiple content shares can now be configured for a single machine group
  • New feature to disable logons on machine startup until the cache is up to date
  • New package and connection group drain mechanism
  • You can now edit an existing connection group and easily redeploy it
  • Simplified installation and configuration
  • Control all App-V client settings directly from the agent (single point of configuration)
  • Overall improvement and bug fixes

Below you can find a print screen of the new Central View console:

And below a print screen of the new Central View console in action in a production environment:

You can also configure a different theme depending on your preference:

New machine group options:

Furthermore the Agent is even thinner and faster then before, also the installation and configuration has been simplified:

Please click here for more print screens and here for the full App-V Scheduler 2.6 release blog about all the new features!

MSIX: The platform for all Windows applications

MSIX: The platform for all Windows applications

Intro
As you might know Windows 10 includes an application platform called the Universal Windows Platform (UWP), UWP applications run inside a container and as the term universal implies the goal is to make them run on every Windows platform\device available and to distribute them by using the Windows Store. UWP also comes with a set of API’s to integrate with functionality like live tiles. The file format used by UWP is APPX and software vendors can adopt this format directly or convert their applications to the APPX format by making use of the Desktop Bridge conversion tool.

Sounds clear right? For consumer applications it does but the reality is that there are a huge amount of traditional applications out there and they all have their own unique configuration and requirements. With configuration I mean integrations with the OS, integrations with Office, their own update mechanisms, etc. They often release their software by using MSI files to modify this properties. While software vendors often develop against the latest frameworks they don’t necessarily have UWP and Windows Store integration high on their list.

For a lot of vendors this will not change any time soon and luckily Microsoft is aware of that. That’s why they came up with a new application format called MSIX.

MSIX
MSIX is the successor of the APPX format and the MSI format, MSIX will close the gap between traditional applications and UWP applications by making them both part of the same platform. Clever idea, because when software vendors are leveraging the latest frameworks but don’t use the UWP integrations that doesn’t make them legacy or obsolete. Far from that, they are often the most sophisticated applications with years of development inside. So at the end they are all Windows applications and now fall under one umbrella called the MSIX platform.

Traditional applications are often installed by using MSI files provided by the software vendor, this file format contains the application files and installation properties. This properties can be modified depending on specific needs. While MSIX is different, it has some of the same characteristics as MSI like a method to do customizations.

MSIX facts

    • MSIX is the successor of APPX and inherits all of its features
    • MSIX is the successor of MSI and it inherits features like custom customizations
    • Customizations are separated in a different layer. This makes updates easier.
    • It builds further on the container functionality inside the UWP platform, providing more security options to be compatible with more applications
    • MSIX applications can be deployed from anywhere (when they are signed) not just the Windows Store
    • MSIX will support all Windows applications
    • MSIX is open source (GitHub link)

App-V
When you are using App-V 5 to deploy and manage traditional applications you are already ahead of the game, there are even similarities in the way the applications are running in their own sandbox. A smooth transition from the APPV format to MSIX will be very easy.

We are also looking to integrate the MSIX format in a future release of App-V Scheduler to accommodate a real-time delivery and management solution for both App-V and MSIX for both RDS and physical deployments.

Remote Display Analyzer 2.0 released

Hi all,

I want to begin with a big thank you for all the positive feedback about Remote Display Analyzer (RDA) and also a very big thanks to the members in the sponsor program, this really helps to drive RDA forward and to help balance the amount of time spend in this project by giving something back to the family. So thank you very much for becoming a sponsor!

If you are new to Remote Display Analyzer (RDA), this tool will help you understand your remote display configuration and it’s behavior, it will only show you relevant information and help you decide which setting is the best for your specific use case. It’s also very handy for troubleshooting remote display configurations. RDA is just a portable executable without any installation needed, just run it in your remote session and you will get all relevant statistics and settings right away.

There is a lot of new functionality in RDA 2.0, both under the hood as on the outside. I don’t want to make this a long article so I will just give you a short summary of the new features together with some print screens.

What’s new in version 2.0

  • Support for VMware Blast and PCoIP with also the possibility to change settings on the fly (please note that support for Blast and PCoIP is experimental in this release and not yet tested on different OS and VMware View versions)
  • GPU addon for all protocols: This addon will show basic GPU information and when Nvidia is detected RDA will show GPU usage and (v)GPU information
  • Support for the latest Citrix HDX features like H.265, also the RTT counter has been added and RDA will show you the YUV mode for the active video codec
  • RDA is now multi threaded which means that settings and real-time counters are retrieved on different threads making the tool more snappy and more real-time
  • Counter that indicates the run time of RDA with the option to reset the counter and the total statistics collected during  a specific run time. This is handy for analyzing and comparing workloads
  • Print screen option to easily generate a print screen of the RDA window
  • Multiple improvements for RDP & new statistics information
  • Transparent mode, this option makes the RDA window transparent as you can see in the below print screen

Below you will find some print screens of RDA 2.0

RDA running in transparent mode

RDA support for VMware

GPU addon (available for all protocols) and extended support for HDX

Remote Display Analyzer 2.0 is now available for free on the website where you can also find more information about the sponsor program. Existing sponsors should have received an automatic e-mail about this new release. If you didn’t receive the mail please send an e-mail to support at rdanalyzer.com. Thanks again for your support!

A comparison between display protocols and codecs

Please note this article has been updated.

Intro

18 November I did a presentation on E2Evc in Barcelona with Rasmus Raun-Nielsen (co-member of TeamRGE) about the differences between remote display protocols and codecs. The session was late in the afternoon so there was already some beers involved which made it a very fun presentation. We summarized the major remote display protocols available in the market. Rasmus then explained what NVENC is (a way to offload the display encoder process to the GPU) and which Nvidia cards supports this technology. I continued with an overview of the available codecs for each protocol and showed the latest Remote Display Analyzer (RDA) 2.0 version (which will be released soon!).

Before the presentation I performed some comparisons with RDA 2.0 in combination with the video codecs found in Microsoft RDP, Citrix HDX and VMware Blast. This blogpost is a small recap of the presentation. Please note that this comparison is an independent view and that conclusions are based on my own observations.

Before I continue: there is some fast progress being made in this space, so it’s important to include the version numbers which are used in this blogpost (I prefer to post updated blogs later instead of updating the same one). The versions used are in the table below:

Codecs used by this protocols

Basically all of the above display protocols consists of 2 types of codecs:

  • Bitmap codecs (JPG\PNG\BMP)
  • Video codecs (H.264\AVC & H.265)

While the bitmap codecs are great for text and static content, the video codecs are more efficient for the more graphic intense workloads. The video codec is based on the industry standard H.264 codec (which we also find in video streaming services like Netflix and YouTube). The use of this codec brings 2 other great advantages:

  • The fast majority of clients have video codec decoding capabilities
  • GPU can be used to accelerate and optimize the encoding process (like Nvidia NVENC)

This results in a very bandwidth efficient way to deliver remote display content to the client, but it comes with a down side: The video codec is by default not optimized for text, because it uses a 4:2:0 chroma subsampling algorithm. This breaks down the quality of text and users often perceive this as blurry (this depends on the user and type of workload, I have seen users working with it every day without complaining). But for text to become really sharp an optimization technique on top of 4:2:0 is needed or a codec operating in pure 4:4:4 mode. This is where the display protocols differentiate from each other like you can see in the below table:

RDP
With RDP you basically have one option when it comes down to the video codec and that is the AVC codec in 4:4:4 mode. It’s enabled by default in the latest Windows versions and you can switch back to the previous codec combination with policies. You can’t really configure this AVC 4:4:4 codec, for example you can’t switch to 4:2:0 mode or change quality levels manually. I must say that the latest RDP versions improved a lot compared to the older RDP versions found in previous Windows versions. While the protocol is still quite bandwidth intense, it offers a very good remote experience. The AVC 4:4:4 mode really delivers a very sharp (near local) experience. RDP has it’s own hardware and software encoding technology and don’t support encoding capabilities like NVENC for their video codec implementation, hopefully they will leverage capabilities offered by mainstream GPU manufactures like Nvidia in the near future. RDP together with RDSH (and the upcoming modern infrastructure) is a very cost effective remote display solution, especially with the latest RDP improvements.

Blast
Blast is a fairly new protocol compared to the others and it’s impressive to see how quick they are making progress with it. As you can see in the above table they do not yet offer a technique to achieve 4:4:4 quality for their video codec. They might be waiting for GPU’s to natively support 4:4:4 so they don’t have to build a software based optimization mechanism for this. They also have a bitmap encoder which you can switch on (Blast uses H.264 by default), but a combination of this codecs is not yet possible. Time will tell if they are focusing on a combination of codecs or optimizing their video codec for 4:4:4 quality. I think the latter makes more sense because currently their bitmap encoder isn’t that optimized compared to the others. Nevertheless I was impressed by the performance of their H.264 codec, as you can see in the comparison below.

HDX
As you can see in the above table HDX has 2 combinations available to address the H.264 4:2:0 limitation. 1: The video codec with a text optimization technique (which is software based and done in CPU). 2: A combination of the bitmap and video codec, this is also known as the “Use Video codec for active regions” setting. For Citrix this makes sense because their bitmap encoder is really optimized throughout the years. In this combination of codecs the video codec is only used for parts of the screen that are changing rapidly, like playing a video for example. I wrote about the differences between the display modes available in HDX here. But there are some limitations, for example you can’t use NVENC in combination with this optimization techniques as of today. I hope to see expanded support for this in the near future. In version 7.16 Citrix has added support for the H.265 codec, this codec is so awesome in many ways as it can massively reduce bandwidth consumption by leveraging a new intra prediction mechanism. This first implementation of H.265 is 4:2:0 only for now (and only when you have a supported GPU), but hope to see more available options in the near future.

All 3 protocols have ways to handle network congestion’s and changes in available bandwidth, they often refer to this with the term “adaptive transport”. They all standardized on UDP by now as the primary transport protocol for sending remote graphics down the wire.

Video codec comparison between RDP, HDX & Blast

Ok let’s continue with the comparison. As you might understand by reading the above it’s not easy to perform direct comparisons. You can just compare the default settings to each other and say how good one is and the other not or vice versa. But in my opinion a comparison only makes sense when you compare apples with apples. Because this comparison will only focus on the video codec I decided to compare the AVC\H.264 codecs to each other. In this comparison the H.264 codec is used for the entire screen and offloaded to the GPU (NVENC). There is one exception and that’s for RDP because we can’t turn off the AVC 4:4:4 mode. Please find the video codecs that are compared in the below table:

Important aspects of the test environment:

  • Agents on Windows 10 with identical specs running on the same hardware placed in a Datacenter in The Netherlands
  • Connection over internet directly to the agent (no connection brokers or gateways)
  • Connection from the same client with same internet conditions and latest client versions
  • All 3 protocols are UDP enabled
  • HDX and Blast use NVENC (Entire screen H.264)
  • Default encoder quality levels are used
  • Test is performed multiple times to verify results
  • Remote Display Analyzer is used to verify display settings and behavior

I separated the RDP comparison movie from the others to highlight even more that the operating mode is different between the video codecs (HDX\Blast operates in 4:2:0 mode in this comparison and RDP operates in 4:4:4 mode).

Please note that this video codec comparison was made for indication purposes only, it’s not reality that users play full screen videos often (while they can do this from time to time). The comparison is based on a manual testing approach while using screen recording software which will also do it’s own compression on the end result. This will affect the frame quality of the resulting movie. This is not comparable with a professional way of benchmarking with for example frame grabbers. For this type of benchmarks I recommend using REX Analytics (developed by co-members of TeamRGE). REX Analytics also leverages Remote Display Analyzer for remote display protocol insights.

The results of the above comparison is displayed below (please note that the Nvidia GPU utilization counter was turned off in this build of RDA, so that’s the reason it shows 0%. The total CPU time consumed is a cumulative of the %CPU usage of the encoder process).

 

My observations and conclusions from the HDX and Blast (pure H.264) video codec comparison:

  • The available bandwidth detected varies between the display protocols. It seems they use a different mechanism of calculating the available bandwidth. It’s interesting to dive deeper into this. This also made me think to add an average available bandwidth counter in RDA so there is an overall indication of the average available bandwidth during a specific run time
  • Observed higher frame compression while playing a full screen movie with HDX compared to Blast, this might be one of the reasons the lower bandwidth usage compared to Blast and the higher amount of frames send to the client (although the difference is not really shocking over a 1:30 minute during full screen movie)
  • With the default encoder quality settings, I observed a sharper frame quality with Blast. But at the cost of more bandwidth and CPU resources compared to HDX
  • Based on the above observations it’s key to compare frame quality to each other and also compare this with a local situation!

Below is an indication movie of the RDP AVC Video codec operating in 4:4:4 mode:

You can find the result below:

My observations and conclusions from the RDP video codec in the above test:

  • RDP can’t really be compared with the others in this video codec comparison because it operates in 4:4:4 mode by default. Perceived quality was very good but high bandwidth usage and some lagging was observed as you can see in the above movie
  • Really sharp images and text, perceived a near local experience with this video codec implementation. Great for office work with a lot of text reading
  • RDP leverages as much bandwidth as needed to achieve the best quality. Not sure what is best: A protocol that’s from itself as low on bandwidth as possible to give the user the best experience or a protocol that uses as much bandwidth needed to achieve the best experience. There should be some form of bandwidth limit or throttling per RDP session to prevent pipe exhaustion or noisy neighbors.  Scalability tests should point out, interesting topic for future testing

Overall conclusion

The above remote protocols aren’t build for remote streaming and remote gaming scenarios (while video and graphical content is increasing). They are build to accommodate a mix of different type of user profiles. That’s why I think it’s very important to have options based on this different type of users, because ones size doesn’t fit all. The display protocol is becoming more intelligent, it can switch codecs and settings by itself based on different content, it would be interesting to see if this will also happen based on the user type or even per application. Because this is not the case for now it’s good to have options!

For now I would say HDX has an advantage over the others because it has the most options available to accommodate a lot of different remote display scenarios. As you can see in the above results the difference between HDX and Blast is not that big when you compare the pure H.264 codec implementations to each other. They both performed really well in this test. The video codec implementation in RDP didn’t disappoint me either, well the bandwidth usage does but the experience was really good.

It’s very interesting to see how they all keep progressing in the near future, expecting to do more 4:4:4 mode comparisons in the future when this is becoming more mainstream. Remote Display protocols are still awesome technology with a lot of advantages, possibilities and use cases.

This blogpost comes without warranty of any kind and observations are based on my own interpretation. Always test and analyze by yourself with a workload that is similar to reality for your environment!

Comparison between display settings in Citrix HDX

Hi everybody,

Last Citrix Synergy (2017) in Orlando, Benny Tritsch and Ruben Spruijt presented the following session:

SYN303: Independent Citrix experts deep dive on Remote Graphics, user experience and GPUs.
This session was among the top 10 of most popular sessions of Synergy 2017, if you didn’t see the presentation you can watch it on-demand here.

In this presentation the new Remote Display Analyzer (RDA) version 1.6 was announced which will be released soon. This version includes numerous new features like a screen capture button and a GPU add-on (available for all display protocols Remote Display Analyzer supports). More about this new RDA version soon.

Also shown in this presentation where the results of a short comparison between 3 major display settings currently available in Citrix HDX. In this blogpost I will show you how this comparison was made together with some key findings. The display settings where evaluated in real-time by playing the exact same video three times while live switching between the following settings:

  • Video codec not in use
  • Video codec for the Entire screen
  • Video codec for Actively changing regions

You can watch the comparison here:

(Test video source: Aswanth Mohan (www.youtube.com/watch?v=668nUCeBHyY))

The result of each setting is shown below:

Some key findings from this short comparison:

  • The total send frames where nearly the same
  • During the test I noticed no big difference in user experience while playing this short 720p HD video
  • Video codec not in use has the lowest impact on CPU but as you can see the bandwidth consumption is higher then the other two
  • Video codec used for the entire screen (with text optimization) gives the best result on bandwidth consumption, but this comes with a higher CPU usage
  • Video codec used for Actively changing regions results in a very good balance between both CPU and bandwidth consumption

Disclaimer:
Please note that this results come without warranty of any kind and are my own interpretation based on above test. The results may vary based on factors like workload, bandwidth and the infrastructure you are using. Please always test settings in your own environment to decide which configuration fits best in your scenario.