Reducing Latency Between US and India/South Asia or Desktop Access on CentOS 7+ GNOME

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

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.

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×10⁸ 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.