6

We have a server in US DC that is getting accessed from US and India, S Asia and SE Asia. With 128GB RAM, CPU and Cent OS 7 + GNOME desktop and it runs VNC server - the server gets access through VNC viewer or Guacamole-on-vnc. We tried Nomachine server-client pair as well.

We face slugginshness in desktop such as moving Window from one place to another, scrolling in GVIM etc. It reduces productivity. Gucamole is better than VNC ( may be nomachine as well) but it's still visible.

Below is a latency picture of one access.

In MNCs, we have seen that US server access from India or vice-e-versa is lag free. Those may not be as smooth as having server in same country, but you can work in them pretty much. Not in our case.

**Can somebody please help to find a solution here such as -

  1. A GRE Tunnel or VPN etc to create a dedicated path/remove hops from US to S/SE Asia with a landing in India etc.
  2. Any liter version of desktop/remote access mechanism.
  3. Or just better to rent a server in India ( we are thinking same).

Any suggestion will be appreciated greatly.**

enter image description here

SS891
  • 71
  • 1
  • 4
  • 12
    You can't exceed the speed of light. – Michael Hampton Mar 14 '21 at 21:13
  • @MichaelHampton Correct, but in this case the speed of light would only take 91ms to travel from India to West Coast USA (and back again!) – Cherona Mar 15 '21 at 03:31
  • 2
    @Cherona The speed of light is only 3x10^8 m/sec in a vacuum. It'd be more like 2x10^8 m/sec in fiber... – Andrew Henle Mar 15 '21 at 10:07
  • 2
    From my experience the latency itself is not a big deal. It's rather the variance of the latency India usually sees towards US networks. Not fully sure if OP is having the same problem. If so, the answers might be different. – GrzegorzOledzki Mar 15 '21 at 10:12
  • On a similar situation, switching from VNC to RDP (with xrdp server) brought us a lot of improvements in terms of delay and stability – Chirlo Mar 15 '21 at 16:59
  • This is a classic: http://www.stuartcheshire.org/rants/Latency.html – Philip Mar 15 '21 at 18:01
  • Is there a specific reason you use only VNC or other remote-desktop solutions rather than a remote UI using webservices and the like? In most cases the latter will be a lot less affected by latency or speed. Also note that VNC is affected not only by latency but also bandwidth (a Full HD 24-bit RGB uncompressed screen is 6 megabytes, compression helps, but up to a point) and of course CPU to handle the compression and decompression. – jcaron Mar 15 '21 at 18:22
  • What are "MNCs"? – jcaron Mar 15 '21 at 18:24
  • @jcaron - No VNC isn't a must. We tried Gucamole which can communicate over VNC and it's definitely better. Nomachine is still better but runs some compression algorithm which makes letter edges go blurry when you scroll up and down in gvim ( edges are high frequencies). #2 above actually is for a separate Desktop + Remoting mechanism. – SS891 Mar 15 '21 at 19:17
  • @GrzegorzOledzki - yes that might be the issue. Some times the screen will freeze for 4-5 seconds. This makes spontaneous coding/scrolling during deeper debug very difficult. – SS891 Mar 15 '21 at 19:18
  • @Chirlo - thanks will try that. – SS891 Mar 15 '21 at 19:20
  • 1
    @jcaron - Multi-Natiional Companies/Corporations :-) . They use the term around here. – SS891 Mar 15 '21 at 19:22
  • 2
    Seconding what GrzegorzOledzki said. Short of latencies approaching the 1s mark or worse, the variance in latency is _usually_ a much bigger issue than average latency. The human nervous system is _very_ good at adapting to arbitrary latencies providing they are consistent. – Austin Hemmelgarn Mar 15 '21 at 22:16
  • Or figure out a way to do your thing without VNC access to a server. Can they do it on their own computers? – user253751 Mar 16 '21 at 09:18
  • @user253751 - No, the tools are on server. You can't have them locally. – SS891 Mar 16 '21 at 12:14

5 Answers5

13

There's nothing you can do to change the underlying latency. Renting a server closer to your users would seem to be the only and best solution.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • Perhaps there is an alternative to VNC which does not transfer each pixel and therefore at least yields increased speed (if not latency)? Or is VNC already optimised in that respect? – Ned64 Mar 14 '21 at 15:22
  • There might be, but at the end of the day you're trying to adjust other factors for a problem that you can't address directly. No matter what you do, the latency is going to be a factor. Can you make adjustments that make the experience marginally better? Maybe. But what about when the latency affects even those adjustments? Better to eliminate the problem altogether by renting a server closer to your users so as to avoid the latency completely. – joeqwerty Mar 14 '21 at 15:29
  • Hi, Thanks for your comments. We will do this in worst case. What about leased line or Tunnel etc. Is there any underlying technology that we can use. I am not sure about the latency number after which humans tend to feel it but in those cases where user VPN into India DC of the company and then work in US DC servers or the reverse, the sluggishness doesn't come across hindering the work. Wondering if we can use that technology. "In MNCs, we have seen that US server access from India or vice-e-versa is lag free. " – SS891 Mar 14 '21 at 19:15
  • @Ned64 VNC can be configured to do compression to reduce bandwidth usage, which can help some. But the latency can't be fixed. I've had to use GUI interfaces cross-US, and the latency there made that tedious even with VNC optimized for that connection as much as possible. I often found myself doing my work locally then just transferring files. Using a GUI over an India-US connection seems to me to be crazy-bad idea. – Andrew Henle Mar 15 '21 at 10:03
  • @AndrewHenle - It's the common practice in this industry. As mentioned various GUI based protocols are used such as VNC/Nomachine/ETX etc. – SS891 Mar 15 '21 at 19:29
7

The answer you need is as given by @joeqwerty:

There's nothing you can do to change the underlying latency. Renting a server closer to your users would seem to be the only and best solution.

Also, as @Michael Hampton commented, you can't exceed the speed of light, or you'll deserve the Nobel Physics Prize for the next year. You have to assume light speed to be 2×108 m/s or less in a fiber channel because it's not vacuum, so a practical lower limit would be some 150ms (RTT).

There may be technologies that can reduce hops (intermediate routers), like tunneling (GRE or some VPN). Tunneling will not affect the latency since it's still based on the underlying networks, or the carrier. Physically they still traverse more or less the same path, and will experience the same latency as well as packet loss rate.

Leasing a private line like IPLC and IEPL can reduce latency to come extents, but I'd doubt they'll make your remote desktop a success. IPLC is in a way similar to tunneling but with reliable bandwidth and latency, and avoids most of the congestion in the public internet. IPLC is still shared and is based on TDM. IEPL is better and more expensive but you have full control over the link. Less intermediate routers in an IEPL line (compared to IPLC) also further reduces latency, getting near the speed of light.

Getting more servers that are geographically near your users is the only solution you have.

iBug
  • 1,212
  • 2
  • 13
  • 23
  • Thank you. As somebody else on top said, even a 300-500 ms latency would have been fine, but it's variable and some times a few seconds. Will research a bit about other mechanisms that you mention here. – SS891 Mar 15 '21 at 19:26
6

We have staff in India, and their latency to the US is variable across a minute/hour/day. So I am familiar with your problems.

Another option is to provide the site a higher quality link with dedicated CIR (Committed Information Rate), and a penalty clause if those CIRs are not achieved.

Downside of this is that such links are normally significantly more expensive than a bog-standard internet link. And it is one link, if your staff are working from home then that will have to be internet-based.

What kind of host are you renting? If its a virtual machine in a cloud provider like AWS, then consider relocating the instance to a closer site, for proximity. Downside of this is that people in the US using the same service are now more remote.

So you can use their Client VPN with an endpoint nearby (Mumbai, Singapore, Japan, etc) and AWS transit to carry that data internationally. This is no-longer internet traffic.

I'm sure other cloud providers have similar offerings too, like google cloud, azure, etc.

Downside here is that every little thing costs a few cents, but there are an awful lot of little things and the bill can grow quickly.

Lastly, if you're colocating a physical host, then consider asking your DC for what they can do to help.

Criggie
  • 2,379
  • 14
  • 25
3

There can be two approaches to the problem: actually reducing the latency, or making the high-latency connection more usable.

There are probably multiple possible routes between the US and India, through any number of under-sea optical fibers and such. While you can't choose the route directly, different Internet providers or geological location will probably have different routes. Practically, you could try renting cloud servers from different providers in different locations, and see whether they have significantly different round-trip times to your US server. If you have a clear winner, and the latency between the winner and clients are also small enough, then using the winner as a proxy could potentially lower your overall latency. Another option may be trying out different commercial VPN providers, and different exits for each provider.

Different remote access protocols will deal with latency differently. SSH and VNC don't have any "smart" handling, so they typically feel the worst. For text mode access, Mosh is significantly better than SSH on high latency because it has smart local predictions. I am less familiar with graphical access protocols, but Microsoft's RDP (native on Windows) seems to have a reputation of being usable on high latency. Also look into commercial offerings like Parsec.

twisteroid ambassador
  • 181
  • 3
  • Thank you. Haven't heard about Parsec, will take a look at it. RDP can't be used as the OS is CentOS 7 Linux. – SS891 Mar 15 '21 at 19:27
1

To support the suggestions about trying RDP, known for behaving well on low-quality connections, xrdp is an implementation for Linux: http://xrdp.org/. Guacamole may support it as well: https://guacamole.apache.org/doc/gug/configuring-guacamole.html#rdp

Michael P
  • 21
  • 2
  • Thank you. Actually we tried your suggestion and went ahead with xRDP. But xRDP on Guacamole isn't rather proven difficult. There's no reply from mailing list of them as well. Have you seen/got it working actually ? – SS891 Mar 27 '21 at 19:42