Thin Client

Source

In the post HP Thin Client Questions I presented a number of questions that a potential HP Thin Client customer asked on September 15th and 16th. I forwarded the questions to HP’s analyst relations team to get the definitive answers. Since the questions were pretty basic (see below), I thought I’d get a quick answer and could help HP. Nearly two weeks later, I still don’t have a response from them.

Just for fun, I contacted Wyse and a few other suppliers of thin client and PC blade hardware to see what they would answer. Wyse responded nearly immediately, engaged in a dialog to discover what I needed and put together a response in less than six hours. Their answer was clear, concise and really useful. I’ve taken the liberty of reproducing their answer below. Thanks for your help Tarkan Maner, Tim Smith, Ricardo Recardo , Param Desai, Daniel Barreto and, of course, Jeff McNaught.

As the others respond, I’ll post their comments here on Virtually Speaking.

Potential HP Thin Client Customer’s Questions

“Do you happen to know what the bandwidth requirements are for the HP Thin clients? We are considering deploying them (30) at each of 5 locations and just having one central thin client server. These remote sites are joined to the main site by T1s.”

“If it’s like Remote Desktop at 64Kbps then we have 24 workstations 64*24 =1536. That’s practically a T1 right there.”

“I heard that this will tend to spike when people do printing, I was wondering how much extra bandwidth would be consumed adding in printing.”

Here’s how Wyse answered those questions

While we cannot comment on HP thin client performance, we can share what we see in the Wyse environments. When using a Wyse thin client in a similar situation average RDP 5.2 protocol per session bandwidth usage is around 0 - 150Kbps to 0 - 200 Kbps for basic desktop use cases (normal office worker running 2D graphics presentation apps, email, simple web browsing). The amount of bandwidth needed is very dependant on the actual changes on the user screen. When the user is reading a Word doc, there is very little data crossing the network (often 0 Kbps), versus when a complete Word screen is being painted, where it can spike to 200Kbps. Printing, depending on the complexity of the document can use over 200Kbps for short periods of time. If you can use Citrix’s ICA/HDX protocol, results can be better (lower bandwidth usage and better screen display), but you mentioned RDP, so we’ll stick with that for now.

At a high level, our customers have found two things:

RDP traffic is bursty, so when user’s screens are not updating, network bandwidth is available for those whose screens are updating. This tends to average to 100 – 200 Kbps, but can be lower in simpler text-only applications.
Multimedia, which is becoming more common, is a big swing here. RDP 5.2 does not render video well, so a 100Kbps video can use 1Mbps of network bandwidth, and still display poorly under RDP. Wyse solved this with virtualization software we call Wyse TCX. It’s been hugely successful, and is even licensed by VMware for their View client. It adds the ability to display video under RDP (and ICA) using less server CPU, less network bandwidth (typically uses only the authoring rate of the video file), and displays that video in very high quality to the user. More on this below.
The OS in the thin client plays a role in bandwidth utilization as well. The RDP client implementation on Wyse ThinOS (Wyse’s market-leading ultra-thin and ultra-green firmware) based thin clients achieves this by intelligently caching bitmaps and on-the-fly compression on the wire. Not all of the 64Kbps screen data is sent across the wire, effectively reducing bandwidth needs.

On a LAN deployment, along with bandwidth usage, two additional parameters that administrators need to be concerned about are server scalability (number of concurrent users on the server) and end user experience. As the nature of the use case gets more complex (requiring media playback, Flash content, VOIP based soft phones), basic RDP may not suffice. The bandwidth usage in such situations tends to be very high and the end user experience is compromised (choppiness, loss of audio-video sync). Wyse’s industry-leading virtualization and user experience optimization software solution, Wyse TCX Suite (built using the Collaborative Processing Architecture) intelligently balances the bandwidth usage, server scalability and end user experience angles by implementing multimedia and audio redirecting technologies thus enhancing RDP protocol for best of the breed deployments. More on this at http://www.wyse.com/products/software/tcx/index.asp

On a WAN deployment, mobility (access to applications on the road) and latency on the network also become important factors for diverse enterprise deployments. Wyse introduced a rich RDP client for the iPhone called PocketCloud which is on the app store now. Check it out at http://www.wyse.com/iphone.

If the network connection is affected by latency and packet loss, this will cause the user experience to degrade significantly. Wyse has a solution for this too, with the new Virtual Desktop Accelerator software product – it effectively improves protocol performance an average of 3-5X or more. It’s free to eval on the net at http://www.wyse.com/products/software/vda/index.asp

These Wyse products are available on Wyse thin clients and supported PCs.

Bottom line: Budget 100Kbps per user. 64kbps is light unless your application is text based, and screen paints occur infrequently, like in call center applications. If there is any multimedia, you’ll need more bandwidth than 64KBps for sure, and should budget to add the bitrate of any planned multimedia content to the overall equation, If you plan to use some 384Kbps multimedia, and 30 users, I’d suggest:

30 x 100Kbps - 3,000Kbps

+ 384Kbps

——————————

= 3,384Kbps

Hope this helps. Feel free to contact us and we’ll connect you to the right individuals in your area, who can provide additional guidance.

Snapshot analysis

An IT-based solution is far more than hardware and software. It this case, it is clear that responsiveness and offering clear information is just as important. If my experience could serve as a guide, Wyse is clearly more responsive than HP was in answering these simple questions. While it may not be true that they would be this responsive in all circumstances, their response was to the point, concise and very helpful.

Unasked for, shoot-from-the-hip advice

HP, you need to consider how to better support your customers who have technical questions about your products. The glowing marketing messages posted on your website rarely offer the detail an IT decision maker would like to have. While I know that you offer very responsive, helpful service to the largest of your customers I’ve often heard that support for smaller organizations is no where near as good.

Daniel Kusnetzky is a member of the senior management team of The 451 Group. He is responsible for research and publications on a broad array of technology topics. He examines emerging technology trends, vendor strategies, research and development issues, and end-user integration requirements. You can follow Dan on Twitter. See his full profile and disclosure of his industry affiliations. If you're going to be in Boston November 3 & 4, you can see him at the The 451 Group 4th Annual Client Conference
Email Dan Kusnetzky