Home » Devtech review » LangsNTechs » MS RDP » Microsoft RDP protocol – a failure

Microsoft RDP protocol – a failure

One day my cousin, who has extensive experience working as UNIX systems administrator, and is now a project manager, was sharing his frustration about Microsoft’s remote desktop RDP protocol: “It’s synchronous, – said he, – and therefore remote application is waiting for all windows and buttons to be one by one redrawn on your machine, which can be quite slow on slow connections. But it doesn’t only slow down that application which is displaying/redrawing something, it slows down practically everything on server – probably because kernel calls are somehow synchronous too and wait for each other, so everything that uses kernel also becomes slow.”

I was shocked to say the least. The situation was that administrating remotely production server, which is under load and thus connection with which is quite slow, is practically not possible without degrading that server’s performance.

I’ve shared the information with some people in local IT circles, and some MS lowers were very skeptical about this, saying this can not true because MS couldn’t make such a fail. “Didn’t fail because couldn’t fail?” – not a very sound explanation as for me. So I’ve decided to try it out myself.

The experiment to perform was relatively simple: two machines, one running windows, the other – MS remote desktop client. On server some task was set to perform – copying files on local HDD in this case. The speed of copying was checked while doing redrawings of windows on RDP connection. First with relatively fast connection, and next with slowed down network out speed on server (which will be slowed down on Servers hosting websites for example, because they serve a lot content out).

Note: I’ve been checking the speed of copying while limiting network out and watching (well, trying to watch – despite limiting only outgoing traffic it was still too slow) movie from remote PC via samba in parallel – the copying speed was fast, so the obvious difference was RDP connection, not just any network connection.

The setup I used:
Server: working licensed (not pirated or somehow damaged) Windows XP 64 bit (and 64-bit “XP” has Win 2003 Server kernel, unlike 32-bit XP).
Client: MacBook Pro running Snow Leopard. Client for Mac I was using is official MS RDP client (it comes with MS Office for Mac as far as I remember).
Network slowdown was done with NetLimiter utility.
Copying files was done using Total Commander. (If you don’t like this choice, I encourage you to repeat the experiment yourself with the tools of your choice).

So here’s the video with experiment I made:

If you watch closely, you may notice that copying of files goes faster when I don’t do window dragging/resizing or make it redraw in other way, even when network out is slowed down. So it’s particularly redrawing what’s making copying slow.

The experiment confirmed the problem.

As for causes of it, I’m a Java developer – I live in a “virtual world of Java virtual machine” – so I don’t know (or care) much about Windows innards and kernel in particular, and cannot explain why unrelated processes, as for example copying files, get affected by serving view of desktop to remote machine. So you tell me.

2 thoughts on “Microsoft RDP protocol – a failure

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s