Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes - Brian Madden TV - BrianMadden.com
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.
Brian Madden TV's Blog

Past Articles

Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes

Written on Jul 09 2009 10,420 views, 9 comments


by Brian Madden

Brian and Gabe are back with Brian Madden TV #16 for July 9, 2009. In this episode:

  • Why Brian thinks this year's BriForum will be the best ever (duh!)
  • Brian's switch to RDP 7 and why USB is still troublesome
  • How RemoteScan addresses client scanning via RDP woes

Plus

And

  • We learn that Gabe also wears striped shirts on the road when Brian and Gabe visit RTO Software as their vendor of the week. RTO's Kevin Goodman and Eric Tatum show how their Virtual Profiles product works and give us a sneak peak at some upcoming features.

All this, and next week's Random Vendor of the Week, on Brian Madden TV #16!

 
 




Our Books


Comments

Jason Conomos wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Fri, Jul 10 2009 7:26 AM Link To This Comment

That WYSE demonstration was really good, but what is doing my head in is how does WYSE proxy the data when it is only going through what people call "First Run"?  If it is the first time it has seen the data, how can it cache the information and therefore "accelerate" the speed of the screen?

At the moment I am sceptical as it doesn't make sense to me.

Paul Helter wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Fri, Jul 10 2009 3:43 PM Link To This Comment

I love all of these"packet based hardware compressors" in the datapath:

a) Wyse VDA.

b) Citrix with their Repeater/Branch Repeater.

c) And a few other companies that just do packet inspection and compression.

They ALL validate what we at Teradici have been saying for several years now – You NEED hardware to be integrated into the "remoting protocol" at some point in the system to achieve the best possible user desktop experience.

One of the downsides to having the hardware compression after the 'software remoting protocol' is complete and has packed it into ip/ethernet packets is that the "packet based hardware compressor" has to:

Hardware at Host:

1) reverse all of the work of the network layer of the host - IP and Encryption.

2) parse the packet data to detect what is going on and reverse some of the functions done by the remoting protocol.

3) compress the data

4) regenerate/perform the IP header and Encryption

5) send it across the link.

Hardware at Client:

6) undo the new IP header and encryption.

7) uncompress the data.

8) put the data back into the state at which the data is parable by the 'remoting protocol'

9) regenerate/peform the IP header and Encryption for the End client.

You can't do steps 1 through 9 without adding at least a few ms of latency on each side, so you are now adding latency to the already slow link - so putting this in a WAN or LAN based situation will improve WAN performance from a bandwidth perspective, and will degrade the LAN and WAN performance from a latency perspective "Assuming the amount of data sent is never hitting bandwidth limits".  In addition, there are 2 new points of attack on the security of the end-to-end session.

With PCoIP, you also have Hardware in the datapath; however, it starts with raw data from the source of the Host system. The PCoIP hardware compresses the data natively in the 'remoting protocol' allowing a significant reduction in both bandwidth and latency over the other "hardware compression" options.  PCoIP also removes the need for both Software 'remoting protocol' compression improving latency and CPU load.  The PCoIP protocol also adaptively changes the compression mechanisms so that it maintains the bandwidth below the bandwidth available in the network, thus providing the most effective and responsive user experience (see assumption above).

I'm not saying that there isn't a need for the "packet based hardware compressors" - just that if you already have the function in the remoting protocol, there's less of a need for these types of products for remoting your desktop.

Alex Balcanquall - Microsoft RDS Team wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Mon, Jul 13 2009 10:12 PM Link To This Comment

We provided something called PnP Redirection in Windows Server 2008; unfortunately few if any device vendors have implemented it for their devices so far. blogs.msdn.com/.../default.aspx the advantage of this framework is it would support more bus types than USB - hence why we did it.

Debs wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Wed, Jul 22 2009 7:04 PM Link To This Comment

The big advantage of Wyse VDA is that it is implemented as a SW proxy that runs inside the Windows environment itself. Wyse VDA does not require any additional HW (e.g. it's not a "packet based hardware compressors"). VDA can also improve the performance significantly on "First Run" connections; it doesn't rely solely on caching.

Andre Meyer Pflug wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Thu, Jul 23 2009 9:07 PM Link To This Comment

Did you try this USBMAP solutions that map USB over rdp:

www.usb-over-network.com/usb-for-remote-desktop.html

www.incentivespro.com/rdp-usb-redirector.html

But both could not develop an solution to handle 127 devices PER SESSION of

Remote Desktop, they map USB from many users but all users on the logged

server can see all the devices.

USMCe5 wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Fri, Jul 24 2009 10:24 AM Link To This Comment

Brian,

I actually got the USB redirection to work using Leostream's Connection Broker/Client/Agent solution.  I launched my Leostream session, connected to my hosted desktop, and as soon as the connection was made my hosted desktop displayed the "found new hardware message".  After it loaded the drivers, I downloaded iTunes and successfully synced my iPhone to my hosted desktop.

Steve Saroff wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Mon, Jul 27 2009 3:31 PM Link To This Comment

Great description of RemoteScan Brian! Thanks for the succinct quote, “RemoteScan works perfectly.”

One minor point, RemoteScan actually does automatically use t RRD and/or ICA directly, but can also be configured to use IP.

 - Steve

Sharon wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Tue, Jan 12 2010 6:14 PM Link To This Comment

Great description of how VDA ( or any accelerator ) works.

BTW I am trying to setup the VDA and test its performance. However, I get this error at the VDA client software "RTT lower than Configured latency threshold, VDA will allow protocol to operate natively"

I fail to proceed further, any help will be of great help.

Sharon

Sharon wrote re: Brian Madden TV #16 - Wyse VDA video demo, RTO's kid coder, and Brian's USB over RDP 7 woes
on Wed, Jan 20 2010 1:52 PM Link To This Comment

Got VDA to run, however, I see the video performance is slower than with native RDP, does anyone have an instite on what could be wrong.

The PPT, Word, overall user experience is good with VDA, just that video is slow.

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.