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

 – Thinwire Plus Fullscreen H.264 Selective H.264
Average Bandwidth Out.  500’449  622’111  485’195
Average Processor Util.  8.33%  8.46%  7.87%

Multimedia Light

 – Thinwire Plus Fullscreen H.264 Selective H.264
Average Bandwidth Out.  4’863’994  4’316’935  5’366’103
Average Processor Util.  11.64%  14.40%  11.67%

Multimedia Heavy

 – Thinwire Plus Fullscreen H.264 Selective H.264
Average Bandwidth Out.  18’117’499.33  14’050’696  15’065’041
Average Processor Util.  8.34%  36.35%  40.35%

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):

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

 – Selective H.264 without Adaptive Transport Selective H.264 with
Adaptive Transport
Average Bandwidth Out 485’195 519’401 (+7%)
Average Processor Util. 7.87% 8.52%

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.

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.

 – Selective H.264 with 2DRLE Selective H.264 with MDRLE
Average Bandwidth Out 485’195 450’844 (-7.1%)
Average Processor Util. 7.87% 8.81%

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

 – Selective H.264 with 2DRLE and Adaptive Transport Selective H.264 with MDRLE and Adaptive Transport
Average Bandwidth Out 519’401 460’271 (-11.4%)
Average Processor Util. 8.52% 8.65%

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%:

 – Selective H.264 without ECC Selective H.264 with ECC
Average Bandwidth Out 485’195 469’111 (-3.3%)
Average Processor Util. 7.87% 8.65%

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:


 – Selective H.264 with 24bit Selective H.264 with 16bit
Average Bandwidth Out 485’195 450’844 (-7.1%)
Average Processor Util. 7.87% 8.81%


 – Selective H.264 with 24bit Selective H.264 with 8bit
Average Bandwidth Out 485’195 270’105 (-44.3%)
Average Processor Util. 7.87% 9.05%

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:

 – Selective H.264 with VQ High Selective H.264 with VQ Medium (Default) Selective H.264 with VQ Low
Average Bandwidth Out 712’471 (+46.8%) 485’195 394’147 (-18.8%)
Average Processor Util. 9.79% 7.87% 8.51%

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

 – Selective H.264  Selective H.264 optimized
Average Bandwidth Out 485’195 294’748 (-39.3%)
Average Processor Util. 7.87% 7.92%

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!