Pano Logic Blog

Networks and Keeping Users Happy

Posted on August 1, 2011, 7:06 PM

View from the CTO

Networks and Keeping Users Happy

Aly Orady - Chief Technology Officer and Co-founder

Lately we've been looking at exactly what you need to ensure a satisfying user experience from virtual desktops. And we haven't just been looking at our Pano Zero Clients - we've looked at the Wyse P20 and the Wyse Xenith clients - both of which have gotten a lot of press lately as being end-points targeted at VMware and Citrix based VDI deployments. To make sure we had unbiased results we even sponsored an independent analyst to run the tests and publish the results. The results surprised even us as on a completely dedicated LAN and server these competitors were barely able to play back full-screen video. Please take a look at the results - you can download the full User Experience Performance Testing Competitive Analysis by the Sarrel Group.

We started this both because we were releasing some great network performance enhancements in 4.5 and because we get asked a lot by customers and partners about how much of a network they really need. We know a typically 100 Mbit Ethernet LAN is plenty. And we know that a consumer-level DSL connection over the Internet isn't enough (which is why we developed Pano Remote). But where is the middle ground? How much is just enough?

The short answer is, like every vendor and industry expert will tell you - it depends. It depends on what applications you run. It depends on how graphically rich those applications are. It even depends on what sort of desktop background you use.

The long answer is, well, long. The Pano Direct Protocol (PDP) used by Pano Zero Clients is highly optimized for LANs, and make the best use of any available bandwidth. PDP sessions running typical office application workloads will use an average bandwidth of around 200-500 Kbps per session (depends on the workload). However you can't size and deploy just for average loads - peak usage will have much more impact on user experience. Every time the user does something, they want the screen repainted as quickly as possible. This causes a burst, or a large but short peak in bandwidth use. The more available bandwidth, the faster the screen updates. Hence, it’s always important to not only size for average use, but to leave room on the link for these bursts. Ideally you should do some testing once you start deployments to measure peak and average loads for *your* workload. That’s the only way to know for sure.

Latency is a bit simpler as there is less likely to be contention with other users unless the network is heavily congested. When a user clicks on a button, they typically need to see a response within 100ms in order to feel like the system is responsive. This 100ms is the end-to-end budget, and includes everything from the amount of time it takes to physically push the mouse button, to round-trip flight time on the network to scheduling and execution time on the server. So, when sizing your network, budget accordingly. You can’t blow your entire latency budget on the just the network piece!

Latencies on certain WANs can climb to several hundred milliseconds, networks where our Pano Remote product is ideal - because of this we've used Microsoft's Remote Desktop Protocol (RDP) with Pano Remote which is intended for use over these types of WANs. RDP doesn't offer anywhere near the user experience or rich multimedia support as PDP but is designed to tolerate much lower bandwidths and much higher latencies.

Most important is knowing the limits of your network and selecting the right users and applications given your constraints. After all, you wouldn’t use a corvette to move furniture or a moving van to win a race.