Remote desktop sessions that "feel slow" usually fail on one of three things, and each has a different fix. Before opening a ticket about bandwidth, spend five minutes on this order.
1. Is it input latency or render latency?
Type in a local text field, then type in the remote one. If the characters appear late but arrive in a burst, the problem is the path (latency + jitter). If they appear smoothly but the screen redraws slowly, the problem is encoding or the remote GPU. These look similar on a video call and are completely different problems.
2. Measure the path, not the speed
A speed test measures throughput to a nearby server and tells you almost nothing about a cross-region session. You want round-trip time, loss and jitter to the actual destination:
mtr -rwzbc 100 <remote-host> Read it top to bottom. The first hop where loss stays flat and latency jumps is the segment to avoid. Anything under ~0.5% loss is usually absorbed by TCP; above 1% you feel it as stalls.
3. Check whether the session survives a route change
If a route switch resets the TCP connection, every switch is a visible freeze, and the client will look worse than a static path. A session-preserving switch - moving packets to a better path without tearing down the socket - is what turns an unstable link into a usable one. This is the part a cross-border network acceleration client is responsible for; the measurement is the easy half.
4. Only then look at bandwidth
Bandwidth matters for file transfer and video, not for typing. If your session is unusable at 5 Mbps but the link shows 100 Mbps idle, bandwidth was never the bottleneck.
The short version
- Input lag in bursts -> path (latency/jitter/loss) -> measure with mtr.
- Smooth input, slow redraw -> encoding/GPU -> check codec and resolution.
- Freeze on every route change -> the client, not the network.
Most "slow remote desktop" reports I see resolve at step 2, and the ones that do not are usually step 3 wearing a disguise.
