At our Synergy event in San Francisco this past May 2011, Michael Schaeffer and I co-presented session SYN348 “Wow to How Part 4, Delivering a Delightful Desktop Experience”. This session focused on some key things that should be done to ensure that a virtual Windows 7 desktop performs well for end users. If you missed Synergy and were unable to make the session, I recommend you catch the recording of the session on Citrix TV at the link below (or you could catch it at Synergy in Barcelona October 26-28):
One of the topics that I discussed was properly configuring our HDX components so that graphics perform well for users connecting to virtual desktops using the ICA protocol. In the session, I discussed our Progressive Display feature and how it improves any graphics that are rendered server side. This would include applications such as Google Earth, ArcGIS, AutoCAD as well as any video that is rendered server side.
Progressive Display is not a new feature. In fact it has been available for over 4 years as it was first introduced with Presentation Server 4.5 (now XenApp) and has also been included in all editions of XenDesktop. However, one of the things that we keep seeing when getting complaints from customers about graphics performing poorly is that many people fail to turn it on. So, unless you explicitly enable this feature via a Citrix policy, you will not be able to take advantage of it.
One could argue that this is something that we should probably have enabled by default, and I would have to agree. In fact, in our next upcoming release of XenDesktop we will be introducing a new and updated version of Progressive Display that is called Adaptive Display. Adaptive Display will be a XenDesktop only feature and will be enabled by default. Stay tuned for a future blog post on Adaptive Display. However, for all XenApp implementations as well as all XenDesktop 5.0 SP1 and earlier, you must use Progressive Display and turn it on as it will continue to be off by default for those editions.
There have been plenty of previous write-ups on how Progressive Display works, so I will not go into gory detail here, but I will give a quick summary. When the graphics on the screen of a user’s desktop or session are rapidly changing, a lossy compression algorithm is engaged reducing the fidelity of the graphics so that less data needs to be transmitted over the wire. This results in huge bandwidth savings and can also make the application feel more responsive. Once the image stops moving or the pixels are no longer changing in a rapid manner, the image is drawn in full fidelity. This way, when looking at the map after it stops scrolling or looking at a picture after it stops moving, the image is shown in full fidelity without any loss of quality. Lossy compression only applies to the images or pixels that are in motion. Progressive Display works with any application that has a large number of pixels rapidly changing. Some classic examples would include scrolling a map, rotating an image in a CAD application, viewing a Power Point with heavy animations or watching a video that is rendered on the server.
Progressive Display Compression Levels
There are five levels of compression that can be configured for Progressive Display:
1. Low: Maintains the greatest image quality, but produces the smallest bandwidth savings.
2. Medium: Provides good image quality and additional bandwidth savings over Low.
3. High: Produces lower quality image and additional bandwidth savings over Medium.
4. Very High: Significantly reduces image quality, but also provides even more bandwidth savings.
5. Ultra High: Extremely reduces image quality, but also provides incredible bandwidth savings.
We often get questions as to what compression level should be selected. There is no easy answer to that question as every situation is unique and requires testing and validation. However, I do have a baseline that I typically use as a starting point and this has proved successful in almost all situations.
1. Low: Configure for all LAN connections that are 100Mb or better.
2. Medium: Configure for all WAN connections that are 10 Mb or better.
3. High: Configure for WAN connections that are 1.5 Mb – 10 Mb.
4. Very High: Configure for slow or congested WAN links that are sub T1 in speed.
5. Ultra High: Only use in the most extreme situations on a case-by-case basis.
It is important to note that these recommendations are just a starting point and can be tweaked based on individual situations. For example, you might have a WAN link with only 2Mb or less of throughput and still use only a Medium compression level if the link is not heavily used.
Bandwidth Savings of Progressive Display
How much does Progressive Display really improve performance and reduce bandwidth usage? Well, I conducted some recent testing with Google Earth over a LAN connection (1 Gb) and captured bandwidth usage. For my test I connected to a Windows 7 Virtual Desktop with 2vCPU and 2 GB RAM hosted on a XenServer. I connected to the desktop using Online Plugin 12.1 from a Windows 7 Desktop running dual monitors at a resolution of 1680×1050 in full screen mode. Google Earth was maximized for all of the tests. The workflow lasted about 80 seconds and was extremely intensive from a graphical perspective for the entire duration of the test. I ran the test with various Progressive Display compression settings as detailed below:
|Progressive Display Compression Level||Total Data Transmitted||Avg. Bandwidth||Peak Bandwidth||Bandwidth Savings|
|None||225 MB||23.9 Mbps||65 Mbps||N/A|
|Low||50 MB||5.2 Mbps||27 Mbps||78%|
|Medium||26 MB||2.5 Mbps||15 Mbps||88%|
As you can see from the results above, the bandwidth savings with Progressive Display can be tremendous! Simply setting Progressive Display to Low reduced the bandwidth consumed by 78% and setting Progressive Display to Medium reduced the bandwidth by an additional 50%.
As mentioned previously, Progressive Display not only works with graphical applications, but also works with server rendered video. Of course, it is best to enable client side rendering of video content with our HDX MediaStream technologies, but there are certain situations where this is not possible such as watching Flash video on a client that does not have a locally installed Flash Player. I decided to disable HDX MediaStream for Flash and run some tests with server rendered video and Progressive Display. For my test I used the Avatar movie web site (www.avatarmovie.com). This site loads an initial home page that has an embedded 36 second movie trailer. Total time to load the home page and watch the movie was approximately 50 seconds. The table below details the results.
|Progressive Display Compression Level||Total Data Transmitted||Avg. Bandwidth||Peak Bandwidth||Bandwidth Savings|
|None||104 MB||16.8 Mb||23 Mb||N/A|
|Low||75 MB||11.2 Mb||21 Mb||28%|
|Medium||40 MB||6.5 Mb||15 Mb||62%|
|High||30 MB||5.0 Mb||15 Mb||71%|
The bandwidth savings for the server side rendered Flash video were not as great as the savings compared with Google Earth; however, that is because Google earth was maximized and almost the entire screen had graphics in constant motion whereas the Avatar movie trailer was displayed within a frame that only consumed a small part of the screen. If the Avatar movie trailer were to be run in full screen mode, the bandwidth savings would have more closely matched the results of Google Earth. Either way, the bandwidth savings for even a small frame displaying video are significant!
So one of the questions often asked is “what about user experience?” Doesn’t the reduced image quality result in a poorer user experience? For the Google Earth scenario above, I had real users (not IT folks) use the application at the various compression levels. At a setting of Low, none of the users were able to notice that a lossy compression algorithm was used. At medium, it was barely noticeable and still provided a great user experience. For the Flash video, setting Progressive to Low resulted in almost no noticeable difference in quality and Medium still provided a good user experience when compared to the native Flash rendering. Since real users are not able to even notice a difference in quality at the setting of Low, there is absolutely no reason that Progressive Display should not be enabled and at least set to Low for all users. The bandwidth savings are just too great to ignore! It is also important to note that most users will probably not notice any difference or have any issues with Medium compression as well. For users on slower WAN links, the benefits are even greater as the graphics will appear much more responsive with Progressive display enabled as opposed to having it disabled.
When configuring the Progressive Display policy, there is also an option for applying lossy compression to still images. I recommend exercising extreme caution with this option. As a default configuration I usually select the option for “do not use lossy compression”. If you enable lossy compression of still images, all graphic images in the session will have their quality reduced. This can be extremely frustrating to users. For example, if a user opens a JPG photograph or navigates to a web site with graphical images, these still images will be of lesser quality when compared to viewing them a local desktop. Needleless to say, this would be totally unacceptable for many use cases such as a doctor looking at an x-ray or law enforcement reviewing photographic evidence. Only in circumstances where bandwidth is low and at a premium and image quality is not of great importance would you want to enable this setting.
Enabling Progressive Display
As mentioned previously, Progressive Display must be enabled through a Citrix Policy applied to the server or virtual desktop. For XenApp 5 and earlier or XenDesktop 4 and earlier, this is accomplished using the Advanced Configuration Console (the old Java CMC). A screen shot from XenDesktop 4 is below:
For XenDesktop 5, Progressive Display can be enabled via Active Directory Group Policy or the HDX Policies (stored in SQL). For XenApp 6, Progressive Display can be enabled via Active Directory Group Policy or Farm Policies (stored in SQL). The screen shot below shows how to enable Progressive Display via Group Policy.
There are several methods for applying the appropriate policy settings to users, but one way is to create a policy that sets Progressive Display to Low and apply it to all users and set it to the lowest priority. This way, all users will at the very least have Progressive Display enabled and set to Low. You can then create other policies with more appropriate settings such as Medium or High and set these policies to a higher priority. You can apply these higher compression levels to specific client IP subnets where you know the available bandwidth of the WAN links connecting those subnets and can identify proper compression level. For Internet users connecting through Access Gateway, I typically standardize on a setting of Medium or High and apply it to everyone coming through Access Gateway. Try to avoid the option for only enabling Progressive Display if the bandwidth falls below a certain threshold. Progressive Display is far too valuable and should always be enabled at a minimum of Low.
Here are a few additional reference links that I encourage you to check out.
Fine Tuning HDX 2D Graphics Experience over WAN
Dynamic Color Compression cuts bandwidth consumption by 35%
Tuning HDX MediaStream server-rendered multimedia delivery
If you have not already enabled Progressive Display, I encourage you to do so. The bandwidth savings and performance increase provided by Progressive Display are just too great to ignore!