Citrix HDX 3D Pro versus Microsoft RemoteFX

what ? are you kiding me ? that's the whole article ?   I thought there'de be an actual comparison of features.  I know I'm not the average enterprise user that usually posts here, but really, nothing but an overview about features everyone already knows ?  How about real world usage.  How about a small CAD/CAM enviornment that needs to leverage one super-server powering 4-6 cheap workstations.  I know it's bizarre, but how about the home "techie" trying to create a home server with 4-6 cheap workstations for general purpose stuff with the possibility of basic gaming ( all things RemoteFX at least has promised ).  I know I'm not your typical user, but some actual comparison in the real world would be nice.

Brian,

Note that PC-over-IP is not restricted to only vSphere Virtual Machines - you can use a hardware PCoIP card in a workstation (blade or otherwise) and use either a hardware or software receiver. You can also broker the connection through VMware View.

Actualy, this article does provide some more insight into the HDX vs RemoteFX story.

I'm curretly looking into what to do with a couple real cases where "remote server" solutions would probably be the best solution but can't really choose if we should go for Citrix HDX or RemoteFX. As we (as an EDU institution) we have MS licenses at a very low cost but the question is if RemoteFX is "good enough" for our users.

It would be stupid if Citrix lets HyperV be a better platform for VDI than XenServer if the "shared GPU" stays the same as today.

What surprises me is that it seems everyone seems to be running for VDI solutions, even when Terminal Services would be good enough for many cases (like ours). With RemoteFX we are more or less forced to go that way to get an optimum usage of the hardware.

The SR-IOV specification allows a single PCIe device to appear as multiple physical devices so that each VM could have a pass-through to a virtual instance of that SR-IOV device and use its native capabilities.

Currently the main usage for SR-IOV has been with high bandwidth NIC cards that allows multiple VMs to share one high performance NIC and use it with native performance (great for virtual appliances such as NetScaler VPX).

There are companies such as NextIO and nVidia that are working on GPU (Or any PCIe device for that matter) with SR-IOV abilities.

An interesting bit is that this could be combined with External PCIe connection and thus allows us to use a separate enclosure full of GPUs and share it across all of our hosts!

So maybe this is the future?

RemoteFX will never be a general purpose solution for the following reasons.

1) Lock into the Windows 7 endpoints and Hyper-V.

2) LAN and the classic MS rate of innovation.

3) No matter how much Quest continue to blow the MS team, RDP sucks period and it's a marriage to Windows no matter how many promises Quest make to extend it elsewhere. That said may be good enough for SMB which is all MS every innovates to. Never enterprise, plus Ray Ozzie wants them to be a Azure cloud company now...

4) I don't see Citrix can do much to to RemoteFX beyond what MS provides to all partners, so it will unlikely be much better than anything Quest does with all the restrictions.

PCoIP without the CUSTOM Teradici hardware is $h1t when it comes to bandwidth consumption,especially with multiple users. The PCoIP people are also stupid, because they don't use a hosted GPU and F scalability. It's obvious that more GPU functionality will be added to HW in the future. They will be f'd at that point and marginalized to a stupid niche unless they wake up now and innovate on the GPU as well.

The HDX 3Dpro stuff is also clumsy with the 1-1 hardware mapping. Clearly Citrix should add a vGPU to XenServer and win on WAN and support more diverse endpoints. The fact that HDX can't do vGPU is a major ding.

Remoting this high end stuff is a waste of time unless you have no other choice for a long time. The costs are just too high. Cheaper to buy a workstation and run it locally. The economics and performance are just not there. Reverse Seamless anybody.....

@shadowflash Brian never once said the article was a feature comparison did he? And how can you really review real world usage with a non-released product (RemoteFX) :) I thought the title was accurate enough for me. Good article too.

@AppDetective I'll comment on your post from the end up (nothing to do with bending you over a desk :P )

"Reverse Seamless anybody" PLEASE will all vendors listen to that? It would be a very good addition to your products!

MS have been very clear that RemoteFX isn't just about delivering high end apps remotely... It's also about the general user experience.

I agree PCoIP with View is BAD!

"Lock into Windows 7 endpoints" not exactly true... MS are only releasing a windows 7 sp1 client but they have made the code available for others to use. I've already seen "zero" clients using RemoteFX as well as a POC XP client. I'm also willing to guess Quest and Citrix will cater for OS X/iPads and Linux.

We've already seen what Quest can do as a POC for WAN usage so until everything is GA I'm still hoping for goodness to come on the WAN - not counting on it though.

Don't forget it's not just about VDI... RemoteFX will offer benefits/improvements to RDS sessions and seamless Apps (from RDS). From my own testing this does work well on the WAN.

I wanted to say this before but my Wife was giving me evil eyes for being on the laptop all day and on my day off!...

This will be the first release/version of RemoteFX on non-tailored hardware so the financial economics and hardware will take some time to be optimized. Having spoken to IBM, Dell and HP they are all committed to RemoteFX but all agree it will take time (years) to put us in the position to get any true ROI. Braking even however is more realistic.

Having said that.... I work at a Uni and we're looking at RemoteFX at a large scale (400 - 500 VMs) with vWorkspace. It will allow us to deliver more resource intensive applications to any pc/device on campus (we have some pretty low spec PC's about). While we have worked out that this will cost 10 - 15% more than using physical desktops it adds flexibility. Which when we're short on teaching space adds true value to the students. We're willing to take the hit on the TCO for this very reason. Of course budgeting for SAN storage and then using local storage will give the extra £££$$$ needed for the GPUs :)

Also the enhancements to RDS will improve the user experience to a large % of staff with more basic requirements.

is RemoteFX not divided into 2 parts ?

1- the user through the Hypervisor of the GPU in a shared mode which will allow VM running on top of it to access GPU and then perform graphical calculation quicker with less resources consumption...

2- remoting graphical element down to client as an extension of RDP protocol (for Win7 desktop only)...

If this is the case (for what I understood),

- point (1) is generic and will benefit any VDI solution vendor  that can use Hyper-V as hypervisor (Citrix, Quest, MSFT...)... this is also a reason to choose Hyper-V when graphical VDI is required. In this point, HDX, RDP, PCoIP are out of consideration as this is just a "VM stuff"...

- point (2) is more a direct compareason with HDX, PCoIP, SPICE and other remote graphic protocol... but is still unrelevant as too locked down from end to end to Win7, MSFT broker and Hyper-V... Probably the joint dev that everybody will try to do is use a good remote protocole (HDX or others) to port the specific remoting protocol thing from RemoteFX to a more broader audience...

Did I missed something ?

@appdetective and @Daniel Bolton. Regarding Reverse Seamless, RES just release their Desktop Extender as a separate product.

www.ressoftware.com/.../virtual-desktop-extender

Just a quick note;

Simon Bramfitt posted an article on RES VDE. The article mentioned that RES have been granted a US patent on the Reverse Seamless technology.

"Virtual Desktop Extender was originally part of RES Workspace Manager, but in October 2010 shortly after it was confirmed that RES had been granted a US patent for the technology (Patent No. 7725527) ,RES announced that it will be decoupling Virtual Desktop Extender from workspace manager and making it available as a stand-alone product./..."

simonbramfitt.com/.../res-software-virtual-desktop-extender.html

In the article comments section Simon explains further [That] “Based on the breadth of the patent I’d have to say that it is unlikely that Citrix would be able to release a reverse-seamless implementation without infringement /…”

Hmmm. What do you guys think?

@Gaiz Cheers for that link... Looks impressive and the RRP price is pretty reasonable too. I've heard about this before but never knew about it being standalone - smart move. I wonder if it will reverse seamless a standard seamless application into a full remote desktop - if that makes sense?

@Kimmo. The Patent is a real bummer and has the potential to do hinder the uptake of desktop virtualization even if only slightly I know a lot of potential customers are interested in reverse seamless.

Maybe someone can release something similar called "always on top" :)

What I would like to see RES do now is some form of RES Virtual Desktop Extender alliance program that allows vendors like Quest and Citrix (and maybe VMware though they wouldn't know what to do with it :P ) to incorporate it into their products/management systems.

So for every license sold a small % goes to RES. or maybe some form of optional extra?

Maybe someone could make a free open sauce equivalent?

What do you think?

Reverse Seamless has to be a free protocol feature for broad adoption. Nobody in their right mind is going to pay RES $10/user for it. I don't care if SimonBramfitt thinks that is a fair price, it is not something that will get business support and keep the feature niche. Hosted Virtual infrastructure is already expensive and the RES line item for Reverse Seamless will be met with a big NO. Simon argues that the patent is so broad X vendor can't build it. Well I'll say that broad patents can also be invalid because they are too broad and not in the spirit of innovation. It's like saying I want a patent on the concept of VDI as opposed to specific techniques that often are worked around over time. Patents are just a trading tool, because I am sure RES is also stepping on patents vs.Flex profiles, Immidio, Appsense, Sepago, RTO etc

In any case, I doubt RES is making a dime of their product and it's just a marketing stunt to get them more awareness with the likes of Simon helping them via their blogs. That's fair enough, but I doubt as Daniel suggests that will be able to use this to hold the industry hostage. If they tried, I am sure they would very quickly become irrelevant (which they mostly are today) because they would loose all ability to sell their solution on top of vendor X. All vendor X has to tell their sales teams is we don't support RES, and RES is F'd.

@Daniel. Fair point on RemoteFX clients, although I think that will take years to mean much broadly and hence it will be very niche and device specific. Kind of like thin clients all over again. I also don't buy the ability of Quest to support as many endpoints as the others. Citrix will kill them here with Receiver and out invest them. Hence in my mind there is a cost for more devices that I can't offer with Quest etc. BTW curious since you work in education why you think Quest pricing is cheaper than Citrix., MS, VMW. Don't all those guys have a campus license? I assume the discount applies only if you are all in?

I am the grunch when it comes to reverse seamless.

yes, lets develop a feature that enhances the use cases for non-virtualized resources.

I think better time would be better spent to look at the deficiencies of streaming virtual apps to the client and why the need for reverse seamless even exists to begin with.

Every non-virtualized app/os IMO is considered not managed efficiently. I firmly believe that local execution is the key to VDI success but let's manage it the same way as SBC.

Boo to reverse seamless.

@Appdetective Stop sitting on the fence and just come out with whats on your mind :)

What endpoints can Citrix support that quest can't? Android and Blackberry the only ones that spring to mind and I'm sure thats changing.

MS and Quest (and Novell to be fair) have realistic expectations on what UK HE can afford when it comes to campus agreements.  Citrix are only financially sustainable for the smaller institutions but are very disengaged from HE. Bless them they do try though. VMware are a *&*&^ joke and dispite having a more feature rich hypervisor, they will loose to Hyper-V (like it or not). We have the hardest time financially for a long time and VMware still look at UK HE as a large revanue stream.

I speak for many Universities here... Quest undercut Citrix and VMware every time.

Citrix and VMware don't take into consideration that we have affiliate institutions and businesses with users who can use our resources, we have libraries that are open to the public, etc ,etc.... Quest make that easy to license and control.

Also the one feature the others don't provide that makes Quest the winner is the ability to assign a resource based on the users physical location! This is any resource, desktop, app, printer, policy, drive mapping, shell folder, etc etc etc...

When you have over 7000 PC's 2000 laptops and god knows how many of the 26,000 users (our users) that use their own devices, the ability to assign resources based on location is critical.

I digress from RemoteFX and HDX

@Brian When will this text be larger?!! I'm not getting any younger and neither are my eyes!

@Icelus

You're joking right?

@Daniel

Not a chance!

If the user has their own OS with their own apps, then let them use the corporate apps without the OS. No need to push their own apps into the server side instance because their workspace is local.

If you have demanding corporate apps that just don't jive on the server side, stream them so they can be run locally.

In 5 years we are all going to be on client hypervisors anyway so server side OS execution will be niche and so will reverse seamless.

I encourage you to rip this comment apart so I can find the actual usefulness of reverse seamless.

Oh, and btw great article brian. RemoteFX was just created to make people weary of locking into VMware, I don't see it competing with HDX. It just adds to the featureset of XenDesktop and others.

@Icelus

"No need to push their own apps into the server side instance because their workspace is local."

Depends on what their workspace is. Reverse Seamless will only display their local app in a full screen remote session/desktop. No pushing involved. One point our users raise time and time again is the frustration with having to minimize a full screen desktop to access local apps.

An very basic example on how reverse seamless would add value to a good % of our users...

User A has basic needs (word, outlook, IE, etc) and is using an RDS session (full screen) but he/she needs to access a more resource intensive package (keeping in the context of Brian's article, a package that requires RemoteFX) which happens to be a standard seamless/remote app from a Windows 7 virtual desktop. Reverse seamless would allow that seamless application to be displayed within the full screen RDS session and that user will no longer need to minimize the full screen RDS session to access a one off package. At the end of the day it's about the users and minimizing a desktop to access one or more other applications effects user productivity in many situations.

User A also uses a Thin Client with next to no processing power and it doesn't make financial sense to provide them with a local PC.

This is just one example...

"If you have demanding corporate apps that just don't jive on the server side, stream them so they can be run locally"

This has some merit if the users device is windows,managed and has enough resources to power the app. I guess if their on the WAN or working from home it would make no sense.

@daniel, fair point in the licensing in UK HE. On location, why can't I achieve that with Access Gateway and assign policy based with Smart Access. Fair enough if it's not as granular as Quests, which is great input from you.

@Icelus. In a mixed mode i.e. remote virtual desktop, some stuff running locally because the app only works well that way or for legal reasons I don't want my users to keep switching between apps in an unnatural way. Reverse Seamless solves for that. I also am not a buyer that we all be running client hypervisors en mass for every use case. One of the big benefits of hosted desktop virtualization is centralization. Centralization of my data center resources, my apps, security, management (although that can be applied to offline as well) and most importantly the session roaming capabilities for my users. Centralization gives me a ton of benefits that distributed devices even if centrally managed can't give me in terms of more efficient and dynamic data center operations. (Cloud stuff). Therefore Reverse Seamless will be required to deal with the exception use cases and provide me with the flexibility I need. The lack of it today is holding up my deployment because there are certain apps that I just can't server centrally to my users. Today I run them locally as needed (another reason don't waste time with Thin clients) but the user experience is terrible to switch. Adding an extra monitor as a solution is too expensive and clutters real estate on the users desk.

That's not to say that streaming to local machines for better app virtualization should not also be improved. However since most people continue to use CRAP-V which is not a platform, $$$$$$$$ with MDOP lock in, it will be a replacement for MSI. Add to that the rate of innovation is too slow and many apps can't be virtualized and there is still a 3rd party support issue. Infrastructure to scale and manage it tries to up sell you to SCCM which is yet more $$$$ junk and kills the TCO. Yet despite all this, like F'ing lemmings people keep doing what MS tells them, when they should realize that App virtualization is not feasible or required for desktop virtualization. App virtualization is just another expensive software distribution tool that is not ready to replace your existing MSI scripts or deployments tools, so you end up two set's of distribution costs...... MS is just trying to suck money out of it, and hence this is a poor bet to invest in the hope that it will get there. Until it's part of the OS, it's means very little. If I have to spend money for it, I would not give it to MS, they are aholes and will not innovate with the product.

Net net, CRAP Virtualization is not ready to go mainstream. Hence we are back at square one. I need a way to deal with certain app types running locally while I enable my business users with centralization to bring organizational agility.

Icelus,

I think you've misunderstood the value of Reverse Seamless.  If an organization has decided to adopt VDI-style desktops (whether they are RDS or hosted desktops) there's always going to be certain things that you're not going to want to run on the hosted desktop tier.  Take any of these as examples:

- Video conferencing

- Possibly VoIP (especially if it involved localized CTI to a soft PBX)

- DVD burning

- Very resource rich applications (complex 3D, etc) - Just because you can run these over RDS/VDI doesn't mean you want to

- Apps that require real time priority (medical devices, etc)

Any of the above a good reasons where you'd want to keep the above applications on the local PC.  But perhaps you want the rest of it centralized for desktop agility, data backup, data security, rapid DR/BC, etc.  In those circumstances you might just put 1-2 apps on the person'a local PC.  They may not even be managed apps.  The user just might want to install their own Nero or Skype, etc.  Now it becomes and inconvenience for the user to keep minimizing their desktop to get to these apps.  If you could present the local app seamlessly into the hosted desktop, then you have the best of both worlds.

Make sense?

Shawn

@Daniel

Thanks for the response. I must keep my du-diligence in digressing from the topic of the article... sorry.

Reverse Seamless is used to display a locally hosted application inside a hosted virtual desktop. Not hosted server side to hosted server side, so thin clients could not benefit from this because nothing is running locally...

The way I see it is that if you use Reverse Seamless then you are using a PC or Laptop that isn't using a client hypervisor with a streamed desktop on it.

And if you are on the LAN with a PC or Laptop that isn't using a client hypervisor, then you have a local OS where you can just get the corporate apps delivered via XenVault.

The consumerization of client hypervisors have started with the main contribution coming from the OEMs. Windows prevail there as well.

Non Windows clients cannot be streamed to. I classify all non-windows clients where local execution cannot be done as thin clients. So we have a niche here where reverse seamless would be useful. - thin clients that have local apps.

If you are over the WAN then there are a few choices:

1. thick client (with client hypervisor) - You came from the LAN where you already received the streamed corporate OS and apps.

2. thick client (with client hypervisor) - You stream the OS and apps over the WAN to run locally, yeah right... not yet.

3. thin client - have to run it server side so you have no choice for local

Notice we are finding that the real need for reverse seamless is really for just non-windows clients that have local apps. The use case just isn't in demand...

@icelus

1) Correct it's a locally running app presented inside a hosted destkop. Therefore the local endpoint need to run Windows. AKA stop wasting time on Thin clients.

2) You can streamline that local endpoint Windows build just to run a few apps to retain flexibility.

3) Nothing stops you from using a client hypervisor on the end point or a streamed OS. But doesn't mean you want to run all apps locally for the reasons Shawn points out above.

4) RS runs on Window client OS, so not niche. It does not run on your def of thin clients which I consider niche when it comes to real world.

5) On WAN you keep missing the point that the user experience is $h1t in a mixed mode. This has nothing to do with streaming OS or client hypervisor.

As Shawn points out. It's about all the use cases that I labeled as benefits of centralization. There will however we exceptions, and there needs to be a way to deal with those with local execution and without f'ing up the user experience. Again nothing to do with client hypervisor or streamed OS.

@appdetective and @shawn

I am beginning to understand more about it.

Thanks for spending the time to explain it.

IMO, utilizing local "device centric" resources in a "user centric" environment of desktop virtualization just seems to be the place of the client hypervisor for thick PCs.

I will just have to wait and see, maybe get my hands on it and compare.

@Icelus

I agree with Shawn, I think you misunderstood the true value of reverse seamless and also my example use case for it but Appdetective and Shawn pretty much hit the nail on the head saying,

"I don't want my users to keep switching between apps in an unnatural way. Reverse Seamless solves for that".

And Shawn with.

"The user just might want to install their own Nero or Skype, etc.  Now it becomes and inconvenience for the user to keep minimizing their desktop to get to these apps.  If you could present the local app seamlessly into the hosted desktop, then you have the best of both worlds"

And to add to Shawn's... If you could present the local app and other seamless apps from other remote desktops into the host (fullscreen) desktop then you really do have the best of "all" the worlds.

I think there needs to be a new article posted (by Brian, Gabe or Guest [Appdetective]) discussing the merits of reverse seamless). We can continue this there.

Dan.

Just knocked this up:

img199.imageshack.us/.../reverseseamlessappcon1.png

Forgive my visio skills but this is how would see reverse seamless working.

Dan.

@kimmo

I've read through that patent and it doesn't look that broad to me. It doesn't cover seamless windows themselves, but rather it covers the the combination of having a server-provided interface for launching a client-side application, having the server send a message to the client telling it to launch the application and having seamless windows.

There are at least some use-cases that I can think of for reverse-seamless windows that wouldn't infringe that patent:

1. Reverse-seamless windows for a permanently-running client application, e.g. a video-conference application that integrates with a local IP phone like CISCO VT Advantage.

2. Having an application that is permanently running locally which sits in the system tray of the session via a reverse seamless window and allows the user to launch other reverse-seamless applications as required.

Even so, the fact that there is a patent at all might be enough deterrent that other vendors don't bother developing this capability.

@martin

I also read the patent, or rather eyed through as it's worded in such a funky way;)

I would agree to your statement that mearly the fact that there is a patent would be deterrent enough for any other alternatve to surface.

For those interested here's a direct link to the patent:

patft.uspto.gov/.../nph-Parser

Better late than never here are my 2 cents.

One of the things that are difficult about supporting 3D acceleration is that there is a technology version (OpenGL or DirectX) dependence dictated by the software vendors that cannot be neglected.

Example1: RemoteFX supports OpenGL 1.2 (I guess exactly the same OpenGL extensions MS used for software rendering with RDP 5 to 7). Problem is that we, as software vendor, can't use version lower than 2.0 as it is simply missing the extensions necessary for the right 3D representation.. So for us that means: RemoteFX = no OpenGL support.

Example2: According to the Caps Logs RemoteFX implements more or less Direct3D Feature level 9 with shader model 2.0 for the “Microsoft RemoteFX Graphics Device – WDDM”, but not all features are supported. While for the “Windows Advanced Rasterization Platform (WARP)” actually the feature level 10.1 is supported with shader model 4.0.

For Terminal Services (RDS) instead is detected Feature level 10.0 for the card Quadro FX1800. While for the “Windows Advanced Rasterization Platform (WARP)” it goes up to 10.1. Both with shader model 4.0! So TS seems to win as far as the following aspects are concerned:

- RDS shares the same GPU concurrently over all sessions (when running Direct3D applications!). Did you guys know? I was pleased to find it out, and this was one of the triggers that made us start the migration to Direct3D.

- It supports a bigger Direct3D feature set

Challenge: is there a card that is server compatible and enough scalable to support all concurrent user sessions? (5 in our case)

Example3: Citrix HDX 3D Pro supporting OpenGL and DirectX makes me wonder again exactly what version we are talking about? The combination with RemoteFX makes me fear HDX 3D Pro will just inherit RemoteFX limitations....

Anybody who knows what version of OpenGL is actually HDX 3D Pro supporting?

Pietro

PS Brian article was actually rather useful. Thanks.

Better late than never here are my 2 cents.

One of the things that are difficult about supporting 3D acceleration is that there is a technology version (OpenGL or DirectX) dependence dictated by the software vendors that cannot be neglected.

Example1: RemoteFX supports OpenGL 1.2 (I guess exactly the same OpenGL extensions MS used for software rendering with RDP 5 to 7). Problem is that we, as software vendor, can't use version lower than 2.0 as it is simply missing the extensions necessary for the right 3D representation.. So for us that means: RemoteFX = no OpenGL support.

Example2: According to the Caps Logs RemoteFX implements more or less Direct3D Feature level 9 with shader model 2.0 for the “Microsoft RemoteFX Graphics Device – WDDM”, but not all features are supported. While for the “Windows Advanced Rasterization Platform (WARP)” actually the feature level 10.1 is supported with shader model 4.0.

For Terminal Services (RDS) instead is detected Feature level 10.0 for the card Quadro FX1800. While for the “Windows Advanced Rasterization Platform (WARP)” it goes up to 10.1. Both with shader model 4.0! So TS seems to win as far as the following aspects are concerned:

- RDS shares the same GPU concurrently over all sessions (when running Direct3D applications!). Did you guys know? I was pleased to find it out, and this was one of the triggers that made us start the migration to Direct3D.

- It supports a bigger Direct3D feature set

Challenge: is there a card that is server compatible and enough scalable to support all concurrent user sessions? (5 in our case)

Example3: Citrix HDX 3D Pro supporting OpenGL and DirectX makes me wonder again exactly what version we are talking about? The combination with RemoteFX makes me fear HDX 3D Pro will just inherit RemoteFX limitations....

Anybody who knows what version of OpenGL is actually HDX 3D Pro supporting?

Pietro

PS Brian article was actually rather useful. Thanks.

How powerful a thin client needs to be for hdx 3d?