Teradici PC-over-IP anyone?

[sgrinker]

Curious if anyone has been able to see a demo of the PC-over-IP technology from Teradici? Even more interested in anyone that may have had an opportunity to trial the solution? Pros/Cons, how it differs from standard RDP connections, etc...

http://www.teradici.com/

Thanks

Steve

[nick_couchman]

Looks to me to be very similar to some of the other "PC Sharing" products (http://www.applica.com). It doesn't look to me like they've actually developed a product, yet - it looks like they've developed a technology and a chip to support it and want other people to start building the other pieces of the puzzle.

It also looks like a totally different technology from VDI/RDP/VMware. It seems that there will be some sort of "host" system that will run an O/S and have a bunch of these chips in it with the remote stations on the other end. Doesn't seem like it's at all a "virtual machine" technology, so you don't have the isolation, independence, etc., that VDI provides by giving each user their own machine.

That's not to say that a technology like that is worthless - it has its place somewhere, but I don't think that place is the same as where VDI fits, though there may be some overlap.

Just my two bits based on a quick glance at that product...

[mreferre · Accepted solution]

Nick,

this is partially correct. Teradici does provide technology for third parties to use (http://www.teradici.com/company/partners.html) and not a product per se. This is being used in third party products like the IBM Workstation Blade (FOR EXAMPLE):

http://www-03.ibm.com/systems/bladecenter/hc10/index.html

This has nothing to do with PC sharing ..... and it actually provides a much more robust technology than VDI (in terms of performance, isolation and video experience). What happens is basically that each blade gets loaded with a native Windows instance (XP / Vista) and by mean of the teradici technology video/keyboard/mouse/USB i/o's is diverged to a remote thin client (aka brick) on the IP network. It's like extending the I/O devices above remotely but instead of using long cables you use a compress/decompress algorithm that goes over an ip wire (notice this is NOT like using RDP / ICA or a whatever high level remote protocol ..... it is pretty "native"). As a result there is no video limitations and you could insert any USB device you can think of and it will be detected by the workstation blade as if it was locally attached (scanner? card reader ? plotter ? Bar code reader ? Whatever .... you name it). It is in fact locally attached strictly speaking.

Of course this comes at a "price". On 14 blades you can support "only" 14 users concurrently in this scenario. In a VDI scenario you can support 14 x n users (where n is the number of VDI users each blade could support). N might be 15 / 20 / 30 / 40 depending on your workloads .....

You do the math and make the cost per user in both scenarios. The idea is that the workstation blade could cost slightly more than a VDI scenario ..... but VDI has a bunch of limitations today that the workstation blade doesn't have.

So yes .... VDI and this technology are different things with potentially different scopes although I can think of some overlaps.

This might give you an overview of what I am talking about (especially the first charts)

http://it20.info/files/3/documentation/entry20.aspx

Massimo.

[nick_couchman]

Thanks for the clarification on that, Massimo!

[sgrinker]

Thanks for all the information Massimo! I was hoping that someone from Teradici or possibly IBM would chime in... hmm... who do I know from IBM?

Seriously, thanks for all the good information yet again. It is definitely a very interesting take on the same idea, but as you pointed out... at a much higher cost. Wyse (and others) seems to be headed toward similar to some extent, with all of the enhancements being made to standard RDP. Granted a dedictated hardware chipset would definitely give you more bang for the buck. Regardless, hopefully either the limitations on "traditional VDI" start to wash away, or the price of solutions like Teradici start to come down. I'd be happy with both of those scenarios personally.

Thanks again

Steve

P.S. I can't believe that I actually just used the phrase "traditional VDI" already either!

[sgrinker]

Another similar solution to Teradici... anyone have any additional information to provide on either?

http://www.panologic.com/

Curious how Pano and Teradici stack up against the standard current solutions in the real world. It appears that Pano's configuration would work better with VMWare, and not necessarily need a blade solution like Teradici. Of course this is all based off what I've seen on their sites. Haven't spoken to either company yet personally.

Thanks

Steve

[kreischl]

I am looking forward to checking out all of the VDI vendors this year.

[JohnBoldon]

I am interested to know what is under the hood in the Pano device. Teradici seems straight forward in that it uses a piece of hardware at the server end to compress the video, it then gets sent over the wire, to be decompressed and displayed at the client end in a dumb device.

Pano claims to be a dumb device with no CPU, no OS, etc which would imply that it is a similar concept. However, since it is in a vmware environment there is no possibility for hardware at the server end. Surely they are not running a software compression driver for each OS instance on the server? That would dramatically cut down the performance and the number of instances that can be supported on the server. I assume that it isn't a higher level remoting protocol like RDP otherwise they would need a client with a CPU to interpret it. So what is it??

[sgrinker]

I've been wondering the same thing. From what you can see in their little diagrams (which is unfortately all you can really gleem from the web site), they have a "Pano Desktop Service" that runs at the Driver level on the OS. I guess that would mean that it would be pretty much what you described... I'll have to see it perform before I make any judgements on the device though regarding performance. I have to believe though that compressing each VM would definitely make a hit. You'd think that eventually something like this at the Hypervisor level would be the way to go.

[mreferre]

I met them at their VMworld booth and what they do is what you have outlined. Similar to Teradici but with a software implementation in the back (within each vm) for their own very thin client.

The way they described it to me is that they use their own protocol over the IP network from their "brick" all the way to the vm; at that point they sort of "plug" into the RDP service for the video redirection.

They didn't stress too much about the performance/latency advantages in doing this but they rather stressed on the fact that you gain a certain bit of flexibility in terms of local devices you can attach into the brick (as they are not RDP-dependent). So it's probably not going to be a screamer in terms of video redirection and latency in general (and perhaps because of this it will not even pose a huge tax on the vm performance itseld) but of course they have the advantage of being able to use this technology in the VDI space Versus the Teradici solution which is limited to the physical workstation blade space.

That is what I'v got so far.

Massimo.

[Nordlicht]

Has anyone seen the pano work over a VPN-DSL-Line?

Just tried a virtual desktop over DSL just with RDP and I was

not satisfied at all. The screen rendering was not fluently.

Web pages with flash are like slow motion.

Is it possibe to have a virtual desktop that feels like a normal

desktop? Maybe it is possible withe the pano?

The USB-usage is another intersing point of the pano.

Is there anyone who tried the pano?

[JohnBoldon]

What it comes down to is that Teradici and Pano appear to be screen scraping. I don't think Pano is doing anything with RDP. Teradici uses hardware to compress and hardware to decompress and is therefore limited to a non virtualised environment. If Pano works in a virtualised environment then it must be using software to compress in each VM. Pano therefore gets hit twice. Screen scraper is always going to use more bandwidth than a protocol like RDP limiting the number of users you can support on your network. The software compression is going to eat up CPU cycles on your server reducing the number of users you can support per server. Seems to me like Pano is a bit of a niche. It may work well (I don't know) but you have to contribute network bandwidth and processor power. It is therefore probably not an alternative to RDP based solutions.

By the way I don't think that using RDP excludes reasonable I/O device support. RDP does not have good native support but you can always implement something like USB over IP alongside RDP.

[mreferre]

John

a few comments on your (interesting) post:

> I don't think Pano is doing anything with RDP

They told me that they "plug into the RDP protocol when their protocol gets into the virtual machine". What does this mean? No idea. I might very well misunderstood what they told me at the booth.

> If Pano works in a virtualised environment then it must be using software to compress in each VM

That is my understanding too. Which is basically what they explained to me.

> The software compression is going to eat up CPU cycles on your server reducing the number of users you can support per server

True. So now at least we know how to (effectively) use all these many cores Intel and AMD are throwing at us ....

> By the way I don't think that using RDP excludes reasonable I/O device support. RDP does not have good native support but you can always implement something like USB over IP alongside RDP

I don't fully agree on this. Yes there are workarounds you can use (like this) but if you have 2 USB devices each users need to use you don't want to put on every end-user's desk a 4 or 5 ports USB-over-IP device ...... because you need to duplicate your cables, your IP's, not to mention the additional cost of the device itself. So I agree that there are workarounds but if you could just plug devices into your thin-client and not bother whether it's going to work or not .... it would just be better for everybody in my opinion.

Massimo.

[JohnBoldon]

Hi,

RDP or no RDP? Pano are plugging their Zero client approach - no CPU, no memory, no OS, no software, on the client. They seem to have their own protocol so it is not RDP that goes over the wires. So this is what has led me to conclude that it is a screen scraper. RDP makes no sense in that context. However, you got a different story from the horse's mouth. mmm..

"USB over IP alongside RDP". Actually I did not mean to suggest that one should use a separate box. RDP is not bad at what it does but does have some deficiencies; notably with Multi-media and I/O redirection. What I was implying was that you do not need to implement something entirely different to overcome these deficiencies (you said Pano did this to get better I/O). Therefore I could imagine a thin client vendor taking RDP as the basis for remote desktop remoting and creating extensions to cover the other areas. I think Wyse are already doing something like this in the V10L with their multimedia extensions. You could do exactly the same for proper USB device support as an additional protocol (in the box) alongside RDP.

[mreferre]

John,

the way it was explained to me (no, I would say the way I understood what they explained to me) is that there was a protocol conversion "within" the vm from their protocol into RDP. So there is no RDP whatsoever running around the net .... it's just their protocol. Whether or not they are using RDP at the VERY VERY VERY end of the chain I am still struggling to understand........ but again I might very well be wrong with that so take my words with a bit a grain of sault.

As per USBoverIP ..... there have been many attempts to do that .... Propero has done something, ProvisionNetworks has done something but yet I think there is a difference between expanding on the RDP limitations and "taking every USB device and plug it in no matter what that is" .... which is the way Teradici works (and it was my understanding that is the same way Pano works too). That is what I meant by better I/O management (not certainly about performance or things like that .......... There are tons of different USB devices out there (Scanner, Card readers, Cheque readers, Bar Code readers, DVD readers/writers, etc etc etc etc) and it is my understanding that even with the RDP protocol extensions above you need to be careful about what you can do and what you can't do.

That is at least my understanding.

Massimo.

[alypano]

The Pano is a "hardware only" client where the drivers for that hardware live in the virtual machine. So, unlike Teradici, there is no hardware on the server side to do compression. The compression is handled by the driver in the virtual machine. It is a very intelligent driver that is very aware of both what changes to the screen are occuring, and how much CPU horsepower it is using at any given time. It is not doing screen scraping, and as a result, the impact to the CPU is minimal. Regardless, in all the VDI deployments we have seen, the servers have always run out of memory or I/O way before they have run out of CPU horsepower - these quad-core CPUs are ridiculously over powered. The question of RDP vs. not RDP is actually not very relevant, and will change over time - at the moment, the RDP stack is used primarily for it's session management capabilities.

[JohnBoldon]

You are right that RDP vs. not RDP isn't very relevant. What is relevant, however, is how many desktops can be hosted by a server. I have not done the calculations but I would expect that you need to support at least 50 desktops in order to have a capital cost equation (vs corporate thick PCs) which favors VDI. If you have a solution which demands more in resources (contrary to hype I do not believe that we have more CPU power than we know what to do with), then you may well end up with a solution which cannot support the "capital cost equal" number of desktops. You then end up in the TCO argument and we know how far that will get you. Ask HP about their CCI.

I am therefore interested to know if the Pano server driver does soak up more horsepower and if the resulting number of desktops is less with this solution.