When it comes to VDI and Remote Desktop Services, task workers are the easiest users to accommodate -- a small set of applications and not a lot of resources required. The
Along with task workers, it's easy to accommodate knowledge workers: Multitasking through office applications is demanding but achievable. We know how to deliver desktops to power users, too, with multiple CPUs and whatever applications they want. The only user group we don't usually try to put in the data center is that whose work doesn't involve words and numbers but revolves around still or moving pictures.
These are the CAD users, graphic artists, video editors and anyone working with 3-D applications. Even without virtual desktop infrastructure (VDI) in place, IT needs to buy them high-performance workstations with fast video cards, powerful GPUs, multiple screens and/or larger screens. You may even have to give them non-Windows desktops such as Macs.
Since graphics-intensive users are the most challenging, think it through before giving them a virtual desktop. Here are some factors to consider if you want solid application performance for these users:
Remote display protocol capabilities
One of the first things to consider is the remote display protocol -- Microsoft's Remote Desktop Protocol and RemoteFX, VMware's PC over IP (PCoIP) or Citrix's HDX -- and the network over which it is remoted. Fundamentally, you are replacing the VGA cable between the PC and the screen with an Ethernet network.
The main difference with a VDI network is that the network is shared, so you may run into contention. Plus, the network traverses a much greater distance, so it has higher latency. To keep VDI users happy, you need to keep the latency and contention as low as possible.
More on graphics-intensive applications
Citrix improves VDI performance with graphics
VMware View 5 includes accelerated graphics support
NVIDIA announces virtualized GPU
Network quality of service is a great tool to make sure VDI traffic doesn't experience high latency when there is too much demand for bandwidth. Lower-priority traffic such as file sharing and email is delivered with higher latency so the remote display protocol can be delivered with low latency. Just like the Voice over IP traffic, the VDI display traffic must arrive as soon as possible.
Bear in mind that the remote protocol doesn't need to remote a 3-D image. Computer screens are all 2-D (so far), so any 3-D image is flattened to a 2-D representation at the virtual desktop before it's sent over the network. The required bandwidth depends on what is changing on that flattened screen image. The faster the rate of change, the more work and bandwidth is required to transfer those changes over the network.
Modern display protocols are very clever. They identify different regions of the screen image as video, text or still images and use different techniques to transfer them. While text moves slowly and must be represented perfectly, video changes fast and our eyes are adapted to seeing a blur as the images change. That means that lossy compression is acceptable for graphics-intensive apps. Your VDI software will analyze the screen contents, the network and the VDI client to work out how best to get the screen contents to the client.
The type of client matters
The type of client device you use affects how much you can optimize the transfer of changing images. A cheap, low-power thin client has less capability to decompress, so the virtual desktop will not be able to compress so much, increasing the bandwidth requirement for graphics-intensive apps to get a good response time.
A powerful PC with a local operating system (that you need to manage) may provide more capabilities and require less bandwidth, but it's likely to cost more to purchase and operate. A zero client specifically engineered for only one display protocol may provide a very high performance display without the need to manage an OS -- and probably at a lower cost than a new PC.
Just like graphics and CAD users with traditional PCs, we need to give them special treatment with VDI. They will still need large screens and probably more than one. They may also need a different desktop device from other users.
Now that we've covered getting the display from the desktop to the user's device, we'll look at graphics-heavy application performance in part two.
This was first published in December 2012