How to Optimize HDX Bandwidth Utilization

At Citrix Consulting, we often times get asked how the bandwidth consumption can be optimized for low bandwidth connections. Since there have been a lot of improvements in our product in the past couple of updates (check out this great blog post by Sasa Petrovic on the topic), I wanted to give you an idea in actual numbers on how big of a difference it makes which HDX modes and settings are used.

So, what are the right settings? Well, it really depends on the use-case at hand. To demonstrate the difference between different use-cases, I wrote three fully automated test use-cases to get reproduceable results every time:

Office User
Open up a bunch of websites in Google Chrome, switch in between the tabs and scroll through the webpages. Open up a business-report PDF (with lots of fancy graphs, pictures and text), and scroll through it.

Multimedia Light
Open up the same business-report PDF and scroll through it. Open up Google Chrome and play a YouTube video in windowed mode for 60 seconds.

Multimedia Heavy
Open up the same YouTube video in Google Chrome, go to Fullscreen and play for 90 seconds.

To measure the bandwidth- and CPU-utilization, the scripts automatically started a PerfMon Data Collector Set that logged “\ICA Session\Output ThinWire Bandwidth” as well as “\Processor Information\%Processor Utility” during the test.

I tested the following three modes: Thinwire Plus (Use video codec for compression: Do not use video codec), Fullscreen H.264 (use video codec for compression: for the entire screen) and Selective H.264 (use video codec for compression: for actively changing regions).

To keep things simple, all other settings were left at default (at first) and no hardware encoding was used. These tests were done on a Server 2016 VDA Version 7.17 with Receiver 4.9 CU1 LTSR and Adaptive Transport/EDT was disabled.

Generally, these results should only be used as a guideline for which settings may be ideal. These numbers were collected while stress testing and do not represent your average bandwidth utilization. Please do not take these numbers and expect to get the exact same results in your environment. I encourage you to do your own tests and see which mode is best for your specific use case.

Office User

Multimedia Light

Multimedia Heavy

Right off the bat, we can see that there is a difference of around 22% between the different modes. We can also see that depending on the use-case, a different mode produces the least amount of bandwidth.

For regular Office Users, Selective H.264 makes the most sense as it produces a very good user experience at the lowest bandwidth.

For Multimedia Light Users, it gets a little trickier. The lowest bandwidth can be achieved with Fullscreen H.264, however the Processor Utilization is considerably higher than with Thinwire Plus. There is no right or wrong answer here, it really comes down to your personal requirements.

In fact, when we do see this use case with our customers, depending on what the customer wants to achieve they’ll go down different roads. If you opt for the lowest bandwidth consumption, Fullscreen H.264 may be right (at a considerable cost in user density). Or if user density per server is more important, Thinwire Plus may be right for you. Or if you may choose the middle ground and go for Selective H.264 as it produces an equally good user experience as Fullscreen H.264 with less Processor Utilization (but at the expense of bandwidth).

For Multimedia Heavy Users, Fullscreen H.264 is probably the right choice. It produces the best user experience at the lowest bandwidth utilization. However, you may want to think about offloading the H.264 encoding to a GPU to lower the hit you take on the Processor Utilization. Keep in mind also, that your client hardware needs to be able to handle the H.264 decoding as well.

Once you have decided which mode is best for you, there are numerous ways to further tweak the different modes and the HDX protocol in general. To keep this article (somewhat) short, I will demonstrate some of these tweaks on the Office User test-case with Selective H.264. It is the default mode after all and probably the mode you want to give with if it`s unclear what use-case(s) you will encounter in your environment.

Adaptive Transport
Since XenDesktop / XenApp 7.16, Adaptive Transport is now enabled by default (you can read all about it in the blog posts below):

• HDX Adaptive Transport and EDT: ICA’s New Default Transport Protocol (Part I)
• HDX Adaptive Transport and EDT: ICA’s New Default Transport Protocol (Part II)
• Adaptive Transport for Video, Apps and Data: The Difference is Clear
• Overcoming Latency to Serve a Global User Population

And as UDP should use the available bandwidth more efficiently, it could theoretically have an impact on the bandwidth used. Well, let’s find out:

Office User

And indeed, we do see an increased bandwidth utilization of around 7%. Keep in mind that this improved utilization comes with a much better user experience over high latency connections. So well worth the price.

MDRLE
With Citrix Receiver 4.11 and XenDesktop / XenApp 7.17 (along with StoreFront 3.14) we`ve introduced a new lossless compression coded called MDRLE. (In fact, you can read the idea behind MDRLE in a blog-article by its inventor Muhammad Dawood from 2016 here.) MDRLE will use a better compression for simple graphics and text, and I did indeed see a 7% decrease of utilized bandwidth.

And if we enable Adaptive Transport again, the decrease is even greater:

So not only did MDRLE make up for the increase that comes with Adaptive Transport, it decreased the bandwidth required even further! Pretty cool as it requires no additional configuration once you have the minimum required software versions installed.

Extra Color Compression
You can read all about what Extra Color Compression (ECC) does here. We at CCS recommend using it in bandwidth-restricted scenarios. During my tests, I’ve been able to decrease the bandwidth by 3.3%:

Preferred Color Depth for simple graphics
While decreasing the color depth may bring great improvements to the bandwidth required, it also comes at a cost. 16bit may be acceptable to most users, 8bit will probably only be an option extraordinary circumstances such as POS terminals for example. With 16bit a good 7.1% decrease can be achieved. while 8bit has brought a whopping 44.3% improvement:

16bit

8bit

Visual Quality

Setting the Visual Quality to Low will further increase the compression used and resulted in an additional 18.8% decrease in bandwidth utilization. For comparison, I also tested Visual Quality set to High:

Conclusion
If we enable all the mentioned settings above (with 16bit color depth), what improvements can we actually achieve?

That’s 39.3% (43.4% when compared to Adaptive Transport) decrease on an already very optimized protocol. I would consider this a success!
Again, please do not take these numbers and expect to get the same results in your environment. The results may highly vary on the use-case, your requirements and your environment. I highly recommend to run your own tests and I would love to hear your results in the comments!

A big thanks to Sasa Petrovic and Martin Latteier for helping me writing this article!

Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more TechBytes and subscribe.

Want specific TechBytes? Let us know! tech-content-feedback@citrix.com