What is the latency threshold for running a Terminal Server (RDS) over the WAN?

Question

I've seen: Terminal server performance over high latency links

But I have a customer who is interested in relocating their system infrastructure to a datacenter that has ~62ms latency from their main headquarters.

The environment is comprised of a trio of Windows Server 2008 R2 RDS servers, file and print services and Microsoft Exchange 2010. It's all currently virtualized on a vSphere 5.5 cluster. There are 80 total users who currently connect locally to the RDS systems using HP thin clients.

Due to facility problems and an increase in offsite and remote users, there is a push to move the systems to a datacenter facility. The new site will feature higher-end vSphere hosts and all-flash storage.

Connectivity to the co-location facility will be established via site-to-site VPN with multiple ISPs and failover in place.

Is this a bad idea, though? I connect to this site often for maintenance work over RDP and SSH, performance is quite acceptable for my use case. The users are using the basic MS Office suite and a couple of lightweight SSH terminal-based ERP applications.

Is 62ms reasonable for this type of user load and Microsoft RDS?

Solution 1

I have several thousand folks around the globe that connect and use accounting / office software daily. As long as their response times are under 300ms we don't get complaints but ymmv.

As proof of concept I set up one of our user's switches using a linux / netem box and kept pushing up the latency / packet loss until I started having complaints. It was a heck of alot easier to replicate the network conditions locally then moving my applications twice.

Solution 2

I feel like this is sort of subjective, as some users won't be happy unless the latency is just like a local desktop experience, and other users will be happy and not complain even if latency is 300ms.

It's true that latency is a user experience-killer, though, precisely how much is a matter of individual perception.

This is a pretty good video from TechEd 2014 on user experience in scenarios similar to this (this video is about VDI, but it's a similar experience to Remote Desktop Services.)

https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be

So you might say, don't ever go beyond 300ms. 62ms is probably "OK."

Solution 3

This question cannot be answered truly universally and objectively. The results really depend on the workload type and users' demands. Nothing can be better here than UX tests.

I often work remotely over RDP from different locations, most of the time connecting via LTE (4G) network which offers latencies similar to 62 ms. At this very time I'm in a hotel with a slow ~ 1 Mbit/s connection and latencies ~ 27-28 ms - less than half of the value in your case. Even with the latter value I have a hard time with web browsing or viewing large graphics (especially without AdBlock, the graphics-rich sites can render for a few seconds in Firefox!). Also an attempt to write a simple document using Microsoft Word generated some frustration due to a below average interface responsibility (in turn LibreOffice Writer felt much better). Not to even mention any work with videos... The things I can pretty comfortably work with are MMC, Outlook mail (to some degree), file browsing and generally system administration tasks.

This value should be OK for remote system administration and similar tasks you do routinely and have an experience with. But if it's to replace the local screen completely I'd expect frustration and complains.

One thing to add - I work under Ubuntu with rdesktop 1.7.1 being my RDP client of choice. There may be some optimizations in Microsoft's original client (or others) which can improve the performance with high latency links.

Solution 4

Sub-100-ms latency is likely not going to be a problem unless your customers are gaming over this network. But you might run out of bandwidth in certain, graphics-intensive applications (especially video playbacks) which will affect the latency adversely and push it well beyond 100 ms, annoying your users.

RDP 8 (Server 2012 and later) does come with optimizations (read: lossy compression algorithms) for these scenarios. Additionally, UDP transport support will improve user experience over links with significantly varying latency or notable packet losses (>0.1%). So if you have any of these, you might want to upgrade your RD session hosts.

View more solutions

Comments

[ewwhite]

That's definitely an option. I didn't realize 2012 offered those benefits. Would those benefits still apply if the origin devices are HP Linux-based thin clients?

[ewwhite]

How did you alter latency/packet loss?

[Tim Brigham]

@ewwhite I added a an old server in bridge mode between a user switch and the router and monkeyed with netem parameters.

[Greg Askew]

I've used TMNetSim to simulate the user experience for a specific latency. Essentially you configure it using the "deployed on the client" option and point the target to 127.0.0.1. The simulator redirects it to the target after jacking with the network throughput. tmurgent.com/appv/index.php/en/resources/tools/…

[the-wabbit]

@ewwhite only if the thin clients indeed do support RDP8. Rdesktop (a popular Linux RDP client) currently does not, FreeRDP (a Rdesktop fork) is claiming to support RDP8, but a closer look at the list of features shows that it mostly is RDP7. YMMV since I do not know what HP is using in the end. Windows clients are supporting RDP8 starting with Embedded Standard 7

[ewwhite]

HP's ThinPro is rdesktop. It's a shame, because many of these clients were purchased over the years. The customer just bought whatever thin client was cheapest.

[the-wabbit]

@ewwhite I can see why - Windows Embedded clients do have major hardware requirements and licensing cost. Looking at the overall cost of purchase, you might just as well be buying low-end business Windows desktops and using them as RDP clients.

[Patrick]

+10 for experimenting on live users