Remote Desktop Latency Test: How to Measure and Benchmark UX

You need remote control to feel snappy — not laggy and unpredictable. If dragging a window, typing, or moving the mouse over a remote session feels sluggish, you’re troubleshooting latency. This guide shows how to run a practical "remote desktop latency test" that separates network issues from encoding/rendering problems and gives repeatable measurements you can benchmark over time.

Why measure latency (and what to expect)

Latency in remote desktop sessions is multi-dimensional. There’s raw network round-trip time (RTT), jitter and packet loss, encoder/decoder delay on host and client, and display/input processing delay on each machine. All of those add up into the delay a human notices when trying to click or drag.

Practical thresholds you can use as rules of thumb:

• < 20 ms RTT: imperceptible in most cases (excellent for interactive work).
• 20–60 ms RTT: very usable for most remote work (minor delay only on fast pointer motion).
• 60–150 ms RTT: acceptable but noticeable; some tasks (drawing, gaming) will suffer.
• > 150–200 ms RTT: clearly noticeable, not good for precision UI work.

Those are rough ranges — actual perceived latency depends on the remote software’s encoding pipeline. Proprietary solutions (TeamViewer, AnyDesk) often use custom codecs and prediction to reduce perceived lag; open-source/self-hosted software (Tenvo, RustDesk) may behave differently depending on configuration. If you want a self-hosted setup, see our self-hosted remote desktop guide for deployment notes.

Overview: two complimentary tests to run

Do these two tests in sequence. They isolate network vs end-to-end user-perceived latency.

1. Network-level benchmarks: ping, traceroute/MTR, and iperf3 for throughput/jitter/packet loss.
2. End-to-end input-to-display measurement: a visual-benchmark method using a blinking square and a high-framerate camera or timestamped frames.

Step 1 — Network-level benchmarking (quick, objective)

Start by measuring the network path between client and host. This won't tell you everything, but it quickly rules out obvious network problems.

Tools you’ll need

• ping (builtin on Windows/macOS/Linux)
• traceroute or MTR (mtr on Linux/macOS; WinMTR on Windows)
• iperf3 (install via package manager; commonly used for throughput, jitter, and packet loss)

Basic commands and expected numbers

Replace host.example.com or 198.51.100.10 with your remote host IP/name.

ping -c 20 host.example.com
# On Windows: ping -n 20 host.example.com

Look at the min/avg/max RTT and packet loss. On the same LAN you should see <1 ms min/avg; over a home broadband link to a regional server 10–40 ms is common; transcontinental links often land in 80–200 ms.

mtr -c 100 host.example.com
# Windows: use WinMTR with default 100 cycles

MTR gives you hop-by-hop packet loss which is useful for spotting a congested link or ISP issue.

Measure jitter and loss with iperf3 (UDP)

Start an iperf3 server on the host:

iperf3 -s

From the client run a UDP test tuned to the bandwidth you expect your remote session to use. Typical remote desktop streams are 1–10 Mbps depending on resolution and frame rate; pick 5M as a realistic test:

iperf3 -c host.example.com -u -b 5M -t 30

iperf3 will report packet loss and jitter. If you see >1% packet loss or jitter above ~10 ms, that will materially affect some remote desktop codecs.

Simulating poor networks

If you want to test how your remote software behaves under delay, jitter or packet loss, use Linux netem to add impairments on the client or host:

sudo tc qdisc add dev eth0 root netem delay 100ms 20ms loss 1%

This command adds 100 ms delay with 20 ms standard deviation and 1% packet loss. To remove the rules:

sudo tc qdisc del dev eth0 root netem

Step 2 — End-to-end input-to-display latency (user-perceived latency)

Network numbers don’t always match perceived latency. A software stack that buffers frames, uses a slow software encoder, or waits for V-sync can add tens or hundreds of milliseconds. Use this method to measure true input-to-display latency in a way you can benchmark.

Method A — High-frame-rate camera method (most reliable, hardware required)

Overview: run a small web page on the host that toggles a visible square when you press a key; connect with your remote client, then point a 120–240 fps camera (or a smartphone at high frame rate) so it records both the host display and remote client display in the same shot. Count frames between toggle visible on host and visible on client.

Steps:

1. On the host, open a simple page that changes a large on-screen square color each time you press the spacebar. Paste this HTML into a local file:

<!doctype html>
<html>
<meta charset="utf-8">
<title>Latency Blink Test</title>
<style>body{margin:0;background:#222;color:#fff;font-family:sans-serif}#s{width:300px;height:300px;margin:50px auto;background:#fff}</style>
<script>document.addEventListener('keydown',e =>{if(e.code==='Space'){let s=document.getElementById('s');s.style.background=(s.style.background==='#fff'?'#0f0':'#fff');}});</script>
<body><div id="s"></div>
<p>Press SPACE to toggle the square</p>
</body>
</html>

2. Start a remote session and position both the host's physical monitor and the remote client window in the camera frame so the camera can see both simultaneously (this is why you need a wide field or move displays adjacent).
3. Record at high frame-rate (120 fps is fine; 240 fps better). Press SPACE and watch the frames. Later, step through the recording frame-by-frame and count how many frames elapse between the host square changing and the client square changing. Latency = frame count / camera_fps.

Example: if you counted 6 frames at 120 fps, latency ≈ 6 / 120 = 0.05 s (50 ms).

Method B — Software timestamping (no camera, less precise)

If you can run code both on host and client with synchronized clocks (NTP-synced is enough for ~10 ms alignment), you can timestamp an event on the host and have the client report the time it displays the event. This requires modification of the remote client or a test overlay, so it’s more advanced.

Pros/cons: The camera method measures the whole pipeline, including monitor persistence and camera timing errors, but is straightforward. Timestamping can be automated but requires tight clock sync (use chrony or pool.ntp.org) and a way to detect the frame update on the client.

Isolating where the delay comes from

Once you have measurements, break the problem down:

• If ping/iperf show low RTT/jitter and your end-to-end test is still high, look at encode/decode or client rendering. Monitor CPU/GPU at the host and client (Task Manager / top / nvidia-smi). High CPU or encoding queueing produces lag.
• If iperf shows significant packet loss or jitter, fix the network. Packet loss often causes codecs to stall or re-request frames.
• If throughput is the issue (e.g., remote video continuously uses more bandwidth than your link allows), throttle the remote desktop to a lower bitrate or resolution and re-test.
• Check the remote software’s settings: color depth, frame rate cap, hardware acceleration (enable NVENC or VA-API where available).

Monitoring host/client resources

Typical checks:

• Windows: Task Manager > Performance and GPU tabs. Check if the encoder is using hardware H.264/HEVC.
• Linux: top/htop for CPU; nvidia-smi to inspect GPU encoder utilization; iostat for disk-related stalls.
• macOS: Activity Monitor and look for GPU/encoder usage if supported.

Comparing different remote software and configurations

When you benchmark, keep the test consistent: same host machine, same client, same network conditions, same display resolution. Test each client version and each protocol mode (direct P2P vs relayed server). Some things to test:

• Wired LAN vs Wi‑Fi vs VPN — wired will always be lowest-latency.
• Direct connection vs relay: relays can add 20–100 ms depending on location.
• Hardware encoding enabled vs software encoding.

Honest note: vendors like AnyDesk and TeamViewer often optimize codecs for perceived interactivity and may outperform generic RDP/VNC in high-latency or low-bandwidth scenarios. If you’re comparing, run the same tests on each. We’ve covered deeper comparisons in AnyDesk vs TeamViewer 2026: Feature & Price Comparison and in our post about Remote Desktop Without Port Forwarding Explained if you’re testing relayed vs direct modes.

Practical benchmark plan and scoring

Run this plan to produce repeatable, comparable results:

1. Baseline: LAN wired test — record ping, iperf3 (5M), and camera-based blink test.
2. Home broadband: client on Wi‑Fi, host wired — run the same tests.
3. Remote over internet: client at home, host in data center (or at work) — run tests and note regions of relay servers if used.
4. Stress test: use netem to add 100 ms delay + 2% loss and re-run to see how the software behaves under impairment.

Score each run on three axes (0–10): network health (based on iperf/ping), encoder health (CPU/GPU usage and frame drops), and perceived interactivity (camera test latency). Combine them into a single score if you need a quick ranking.

Tips and quick fixes to reduce latency

• Prefer wired Ethernet over Wi‑Fi. Wi‑Fi adds variable latency and jitter.
• Enable hardware encoding on the host (NVENC/QuickSync/VA-API) and hardware decoding on client where supported.
• Lower resolution or frame rate. 720p@30 often provides a better interactive feel than 1080p@60 on constrained links.
• Use direct P2P connections where possible — relays add latency.
• Close unnecessary CPU/GPU-intensive apps on host and client to avoid encoder queueing.
• If you control network devices, prioritize remote-desktop traffic with QoS for critical sessions.

Documenting results and benchmarks

Record the test metadata: software name and version (e.g., Tenvo v0.9.x, AnyDesk 7.x, TeamViewer 15.x), OS versions, client and host hardware, network type, iperf3 output, and camera frame-rate. Store the raw camera video and the counted frames so you can reproduce the measurement later. This is especially helpful when evaluating changes like driver updates or codec settings.

For Tenvo users: our download page at /download lists current builds; if you test Tenvo, include the exact build/commit. If you plan to self-host, our Self-hosted remote desktop: the honest 2026 guide explains server deployment details that affect connection mode and latency.

Wrapping up

A good "remote desktop latency test" combines objective network measurements with a user-facing end-to-end test. The network tools (ping, traceroute/MTR, iperf3) identify connectivity problems quickly; the camera-based blink test measures the actual input-to-display delay people feel. Use netem to reproduce trouble conditions, and monitor host/client resources to find encoder bottlenecks.

If you want a baseline that’s repeatable across different software vendors, automate the network tests with scripts and keep a short video record of the blink tests. Comparing several runs, you’ll see how much of the delay is network vs software pipeline — and that tells you the right fix.

If you’re testing self-hosted options vs hosted relays, our article on Remote Desktop Without Port Forwarding Explained discusses relay tradeoffs in more depth. For vendor comparisons (codec behavior and pricing tradeoffs), see AnyDesk vs TeamViewer 2026: Feature & Price Comparison.

Ready to run tests on an open-source client you can self-host and modify? Download Tenvo at /download and follow the deployment notes in our Self-hosted remote desktop: the honest 2026 guide. If you need help interpreting your benchmark results, paste the iperf3 output and your camera measurement and we’ll walk through the likely bottlenecks.