Anyone who’s ever used Adobe Acrobat Reader, or any other PDF reader on Windows Terminal Services or via Remote Desktop knows that it’s painfully slow over RDP.  Most of the videos we’ve posted demonstrating Quest’s EOP Graphics Acceleration have shown web content, as it’s usually the biggest pain point for Terminal Services & VDI users. 

It’s important to note that Quest EOP accelerates all graphical elements of the Terminal Services or VDI display, and in the video below I demonstrate, side-by-side, the difference between Microsoft RDP and Quest EOP when viewing a PDF with Acrobat Reader 9.0 over a WAN connection.  The connection was from my notebook computer in San Diego, CA to two virtual desktops in Reston, VA, via my Verizon wireless cellular card.  This connection was also tunneled thru Quest’s Secure-IT SSL Gateway.  The bandwidth of this connection is approximately 384Kbps and the latency of the connection is approximately 175ms.

quest_eop_vs_rdp_pdf_wan

So VMworld starts on Monday, and we’re getting ready to make a big splash with our new enhancements for VDI and Windows Terminal Services.  One of our new enhancements is something that I don’t think anyone thought could be done (make RDP perform well across the WAN, or display animation and complex graphics).  It used to be a foregone conclusion that RDP just could not perform well across a latent or low bandwidth connection, or one that is displaying complex graphics or animation.

This is no longer the case, as is shown in the video below.  This video is two mintues long, and during that two minutes I am working with two virtualized remote desktops via SSL Secure Gateway, from the same client computer, connected to the public Internet via a Verizon Wireless card, from the Southwest Coast of the United States to the Northeast Coast of the United States. I typically have about 384Kbps download speed, and the latency to the remote site is about 150 milliseconds.

So anyways, during this two minutes I load the exact same webpage on the two remote desktops.  On one desktop, the webpage never even finishes rendering the alpha-blended splash screen during the entire two minutes, whereas on the desktop running Quest’s EOP (Experience Optimized Protocol)  the page loads instantly and you can see me clicking around, flipping from page to page,  while the other one seems frozen. 

If you look closely, the desktop on the left that is using the standard RDP protocol, that is offered with products like VMware VDM, Leostream, 2x, Ericom, nSuite, Desktone [insert every other VDI and Terminal Services vendor that utilizes the Microsoft RDP Protocol] is drawing block by block, layer by layer and it is completely unusable.  It’s not just a matter of that one is more responsive than the other, but that one is using so much bandwidth that it’s completely saturating my Internet connection.  When this happens the only way interact with the frozen remote desktop is to wait for it to finish loading (no telling how long that would take), or to have an administrator reset the session.

Yesterday I visited a client that was ready to deploy VMware VDM, but they had to support several remote sites, some connected over DSL and others over T1 with MPLS. Users were complaining that they couldn’t use some websites that they use on their PCs every day (some for leisurely Internet browsing, and some to do actual work). We tested connecting to one of the Remote Desktops with the VDM client and launching their default webpage www.live.com.  This page took more than 30 seconds to load with the Vmware VDM client, and less than 2 seconds to load with Quest’s EOP.  In addition to that, the system integrator asked me how much less bandwidth we were consuming with the Provision Networks Client.  We measured it with NetLimiter Pro, and the Vmware VDM client used 18 times more bandwidth to load this one webpage than the Provision Networks client did.  This was way better than I expected, and the video below is even more impressive than what I just described.

If this sounds interesting to you, come see it in person at VMworld Booth #1039 from September 15-18, 2008.  If you’re not going to VMworld, just ping me and we can come to you.

rdp61_eop_live

QuestEOP