Kiểm tra độ trễ Remote Desktop: Cách đo và đánh giá UX

Bạn cần điều khiển từ xa phản hồi nhanh — không bị trễ hoặc không ổn định. Nếu kéo cửa sổ, gõ phím, hoặc di chuyển chuột trong một phiên làm việc từ xa cảm thấy ì ạch, bạn đang khắc phục vấn đề độ trễ. Hướng dẫn này chỉ cách thực hiện một “remote desktop latency test” thực tế để tách các vấn đề mạng khỏi các vấn đề mã hóa/kết xuất và cung cấp các phép đo lặp lại mà bạn có thể dùng làm benchmark theo thời gian.

Tại sao phải đo độ trễ (và nên mong đợi gì)

Độ trễ trong phiên điều khiển từ xa có nhiều chiều. Có thời gian mạng đi-về thô (RTT), jitter và mất gói, độ trễ mã hóa/giải mã trên host và client, và độ trễ xử lý hiển thị/nhập trên mỗi máy. Tất cả cộng lại tạo thành độ trễ mà con người nhận thấy khi cố gắng nhấp hoặc kéo.

Các ngưỡng thực tế bạn có thể dùng như quy tắc:

• < 20 ms RTT: hầu như không nhận thấy trong phần lớn trường hợp (tốt cho công việc tương tác).
• 20–60 ms RTT: rất sử dụng được cho hầu hết công việc từ xa (chỉ có độ trễ nhỏ khi di chuyển con trỏ nhanh).
• 60–150 ms RTT: chấp nhận được nhưng có thể nhận thấy; một số tác vụ (vẽ, chơi game) sẽ bị ảnh hưởng.
• > 150–200 ms RTT: rõ ràng có thể nhận thấy, không phù hợp cho công việc giao diện yêu cầu chính xác.

Đây là các khoảng ước — độ trễ thực tế phụ thuộc vào đường ống mã hóa của phần mềm remote. Các giải pháp đóng/mã nguồn riêng (TeamViewer, AnyDesk) thường dùng codec và dự đoán tùy chỉnh để giảm cảm nhận trễ; phần mềm mã nguồn mở/tự lưu trữ (Tenvo, RustDesk) có thể hành xử khác tùy cấu hình. Nếu bạn muốn thiết lập tự lưu trữ, xem hướng dẫn self-hosted remote desktop của chúng tôi để biết ghi chú triển khai.

Tổng quan: hai bài kiểm tra bổ trợ cần chạy

Thực hiện hai bài kiểm tra này theo thứ tự. Chúng cô lập mạng so với độ trễ end-to-end mà người dùng cảm nhận.

1. Benchmark ở mức mạng: ping, traceroute/MTR, và iperf3 để đo throughput/jitter/mất gói.
2. Đo end-to-end từ nhập tới hiển thị: phương pháp benchmark trực quan dùng ô nhấp nháy và camera tốc độ khung hình cao hoặc các khung có timestamp.

Step 1 — Network-level benchmarking (nhanh, khách quan)

Bắt đầu bằng cách đo đường đi mạng giữa client và host. Điều này không nói hết mọi thứ, nhưng nhanh chóng loại trừ các vấn đề mạng rõ ràng.

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

Xem min/avg/max RTT và mất gói. Trên cùng LAN bạn nên thấy <1 ms min/avg; qua đường băng rộng gia đình đến máy chủ vùng thường vào khoảng 10–40 ms; các liên lục địa thường rơi vào 80–200 ms.

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

MTR cung cấp thông tin mất gói theo từng hop, hữu ích để phát hiện liên kết bị tắc nghẽn hoặc vấn đề nhà cung cấp dịch vụ.

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)

Số liệu mạng không phải lúc nào cũng khớp với độ trễ cảm nhận. Một stack phần mềm mà đệm khung hình, dùng bộ mã hóa phần mềm chậm, hoặc chờ V-sync có thể thêm hàng chục đến hàng trăm mili giây. Dùng phương pháp này để đo độ trễ thực từ nhập tới hiển thị theo cách bạn có thể làm benchmark.

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

Tổng quan: chạy một trang web nhỏ trên host đổi trạng thái một ô hiển thị khi bạn nhấn phím; kết nối bằng client remote, rồi dùng camera 120–240 fps (hoặc smartphone ở chế độ frame-rate cao) để quay cả màn hình host và cửa sổ client trong cùng một khung. Đếm số khung giữa khi ô trên host nhấp nháy và ô trên client nhấp nháy.

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: So sánh tính năng và giá and in our post about Remote Desktop không cần port forwarding: giải thích 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 Remote desktop tự lưu trữ: hướng dẫn trung thực 2026 explains server deployment details that affect connection mode and latency.

Wrapping up

Một "remote desktop latency test" tốt kết hợp các phép đo mạng khách quan với một bài kiểm tra end-to-end mà người dùng thấy được. Công cụ mạng (ping, traceroute/MTR, iperf3) nhanh chóng xác định vấn đề kết nối; bài kiểm tra ô nhấp nháy bằng camera đo được độ trễ thực từ nhập tới hiển thị. Dùng netem để tái tạo điều kiện gặp sự cố, và giám sát tài nguyên host/client để tìm nút thắt encoder.

Nếu bạn muốn một baseline có thể lặp lại giữa các nhà cung cấp phần mềm khác nhau, tự động hóa các bài kiểm tra mạng bằng script và lưu video ngắn của các bài test blink. So sánh nhiều lần chạy, bạn sẽ thấy phần nào của độ trễ là do mạng so với đường ống phần mềm — và điều đó cho biết cách sửa đúng.

Nếu bạn thử so sánh tùy chọn tự lưu trữ vs relay được host, bài viết của chúng tôi về Remote Desktop không cần port forwarding: giải thích thảo luận chi tiết hơn về các đánh đổi relay. Đối với so sánh nhà cung cấp (hành vi codec và đánh đổi về giá cả), xem AnyDesk vs TeamViewer 2026: So sánh tính năng và giá.

Sẵn sàng chạy thử trên một client mã nguồn mở có thể tự lưu trữ và sửa đổi? Download Tenvo at /download và theo các ghi chú triển khai trong Remote desktop tự lưu trữ: hướng dẫn trung thực 2026. Nếu bạn cần trợ giúp diễn giải kết quả benchmark, dán iperf3 output và kết quả đo bằng camera của bạn và chúng tôi sẽ phân tích các nút thắt khả dĩ.