Follow up on bandwidth from Zdnet and HP response.
NOTE: The good folks at HP pointed out that I had used an old version of my document and some factual errors crept into my post. This is a revised version of the post with those errors removed (and quite possibly new ones inserted).
On September 16th, a member of the ZDnet audience sent me a note asking for some hard data about HP’s thin clients. I just finished a very enlightening discussion with some of HP’s best including David Bryant, Master Technologist, Desktop Solutions Organization of HP’s personal systems group (PSG);Tom Flynn, Chief Technologist, Desktop Solutions Organization for PSG; and Jimmy Johnson, Analyst Relations for HP’s PSG.
As a reminder, here are the questions the HP customer asked:
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.
Discussion with HP
The HP folks and I spent some time discussing the fact that a complete analysis of bandwidth requirements really isn’t possible with just the information provided in those simple questions. They did share some rules of thumb that were extrapolations from their testing. The best way, of course, would be for the customer to try a pilot test with HP’s systems and learn what their bandwidth requirements were in their own environment, using their own applications.
Here are the things that we don’t really know about the customer’s environment:
Whether printers will be attached to each Thin Client or each office will have a single shared printer.
HP’s Broad rules of thumb
With all of those unknowns on the table, the best HP’s folks could do is present broad rules of thumb that have come from running extensive tests. This data is interesting, but, of course, might not be indicative of this customer’s actual requirements.
This site is produced by