Citrix Virtual Apps and Desktops Bandwidth

With Citrix Virtual Apps and Desktops 1912 achieved LTSR (Long Term Servicing Release).  This is the first LTSR since the 7.15 release, which was almost 3 years earlier.

In 3 years, a lot has changed. The protocol had many improvements that directly impacted the user experience and bandwidth utilization. With each release, since 7.11 (2016), I ran a standard series of LoginVSI tests to compare bandwidth utilization.

Since the 1912 release is an LTSR, it is time to reset the test scenarios. I need to update the base operating system to something more recent. I also want to apply a standard optimization policy, because that is definitely a best practice.

My goal is to continue adding on future releases like i did before. So, stay tuned each quarter for the latest numbers.

Test Details

The test scenarios are as follows:

  • Workloads: LoginVSI v4.1.39
    • Task Worker
    • Knowledge Worker
    • Power Worker
  • Operating System:
    • Windows 10 (1903)
    • Windows 2016
  • Optimizations: Citrix Optimization Tool-1903 template
  • Policies: (policy settings defined at the end)
    • Baseline
    • Bandwidth
    • User Experience
  • Test Duration: 60 minutes
  • Test Iterations: 3 cycles
  • Metric Sample Period: 5 seconds


First, we look at the bandwidth utilization for a 60 minute LoginVSI test using the default policy settings within Citrix Virtual Apps and Desktops.

Release Task
7.15 137 kbps 269 kbps 870 kbps
1912 26 kbps 88 kbps 166 kbps

In the next series of data, we use a Citrix Virtual Apps and Desktops policy that tries to reduce bandwidth utilization.

Release Task
7.15 136 kbps 268 kbps 425 kbps
1912 26 kbps 88 kbps 163 kbps

In the final series, we use a Citrix Virtual Apps and Desktops policy that tries to provide a high quality user experience.

Release Task
7.15 138 kbps 350 kbps 900 kbps
1912 64 kbps 94 kbps 166 kbps

I find it amazing that the policies have little impact on the overall bandwidth usage with the 1912 release.  But then I remember that since 7.15, the protocol includes more intelligence to apply optimizations differently based on what is being displayed. Video vs text vs graphics.

If we graph these results, you can quickly see the drastic reduction in overall bandwidth utilization across all test scenarios.


This graph shows data from tests running Windows 10.  But what about Windows 2016?


The 1912 release numbers are the same between Windows 10 and Windows 2016. Citrix Virtual Apps and Desktops uses the same implementation across both operating systems resulting in similar results.

Policy Settings 

Policy Baseline Bandwidth Experience
Audio Quality High Low High
Desktop wallpaper Allowed Disabled Allowed
Dynamic windows preview Enabled Prohibited Enabled
Limit video quality Not configured Max 480p/720kbps Not configured
HDX Adaptive Transport 7.15: Off
1912: Preferred
Preferred Preferred
Menu animation Allowed Prohibited Allowed
Preferred color depth for simple graphics 24 bits per pixel 16 bits per pixel 24 bits per pixel
Target frame rate 30 fps 16 fps 30 fps
Target minimum frame rate 10 fps 8 fps 10 fps
Use video codec for compression Use when preferred For actively changing regions Use when preferred
View window contents while dragging Allowed Prohibited Allowed
Visual quality Medium Low High

9 thoughts on “Citrix Virtual Apps and Desktops Bandwidth”

  1. I’m curious how much bandwidth is saved if EDT is disabled on 1912. Due to our QoS policies, turning on EDT produced more latency and a worse experience. We will have to work network to modify our MTU sizes to less than 1500 to see if we can get UDP/EDT to work.


  2. Excellent summary, Daniel! Thanks for sharing with the community. Question for you — was all testing performed on the internal network only? My understanding is that EDT is much more bandwidth intensive for external connections via ADC Gateway than it is for internal Storefront connections. Can you clarify for me?


  3. Hello Dan, in case of bandwidth i do see “View window contents while dragging’ is prohibited. I thought this should be allowed to achieve better performance with limited bandwidth/high latency.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.