12

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?

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 3
    62ms doesn't sound terrible, but latency is an experience killer for TS/RDS. If users start complaining about lag in things like typing then it might point to a latency issue. My client who runs a 300 user RDS farm has customers all over the globe and the biggest performance issues are related to latency. The users who are the farthest away and have the highest latency are the ones that complain about performance. Is it possible to test with just a handful of users to get a feel for their performance? – joeqwerty Dec 04 '15 at 18:13
  • 1
    I'll spin up a test VM... And perhaps try to get a subset of users connected. – ewwhite Dec 04 '15 at 18:19
  • 1
    Be sure to turn off "unnecesary animations" in Windows, which removes the need to explicitly disable it in MS Office too. Animations makes latency issues much more apparent and waste valuable bandwidth, better used for sending relevant screen updates. Office 2013 is terrible on RDS/XenApp out of the box in that respect! Also, disabling graphics HW acceleration in Office can sometimes *improve* performance and reduce issues. – abstrask Dec 08 '15 at 22:55

4 Answers4

11

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."

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
11

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.

Tim Brigham
  • 15,465
  • 7
  • 72
  • 113
  • How did you alter latency/packet loss? – ewwhite Dec 06 '15 at 11:11
  • @ewwhite I added a an old server in bridge mode between a user switch and the router and monkeyed with netem parameters. – Tim Brigham Dec 06 '15 at 14:47
  • 1
    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. http://www.tmurgent.com/appv/index.php/en/resources/tools/177-tmnetsim-quick-and-easy-network-simulation-tool – Greg Askew Dec 06 '15 at 16:11
  • 1
    +10 for experimenting on live users – Patrick Apr 12 '16 at 00:15
5

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.

sam_pan_mariusz
  • 2,053
  • 1
  • 12
  • 15
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.

the-wabbit
  • 40,319
  • 13
  • 105
  • 169
  • 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 Dec 06 '15 at 11:08
  • @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](https://en.wikipedia.org/wiki/FreeRDP#Features), 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](http://blogs.msdn.com/b/windows-embedded/archive/2012/10/23/remote-desktop-connection-8-client-update-for-wes7-and-posready7-available-on-ece.aspx) – the-wabbit Dec 09 '15 at 08:07
  • 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. – ewwhite Dec 09 '15 at 08:10
  • @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. – the-wabbit Dec 09 '15 at 09:39