Teste de latência em desktop remoto: medir e benchmark

Você precisa que o controle remoto seja responsivo — não com atraso e imprevisível. Se arrastar uma janela, digitar ou mover o mouse em uma sessão remota parece lento, você está lidando com latência. Este guia mostra como executar um "teste de latência em área de trabalho remota" prático que separa problemas de rede de problemas de codificação/renderização e fornece medições repetíveis que você pode comparar ao longo do tempo.

Por que medir a latência (e o que esperar)

A latência em sessões de área de trabalho remota é multidimensional. Há o tempo de ida e volta bruto da rede (RTT), jitter e perda de pacotes, atraso do codificador/decodificador no host e no cliente, e atraso de processamento de exibição/entrada em cada máquina. Tudo isso se soma ao atraso que um humano percebe ao tentar clicar ou arrastar.

Limiares práticos que você pode usar como regra geral:

• < 20 ms RTT: imperceptível na maioria dos casos (excelente para trabalho interativo).
• 20–60 ms RTT: muito utilizável para a maioria do trabalho remoto (apenas atraso mínimo em movimentos rápidos do cursor).
• 60–150 ms RTT: aceitável, mas perceptível; algumas tarefas (desenho, jogos) sofrerão.
• > 150–200 ms RTT: claramente perceptível, não bom para trabalho de UI de precisão.

Isto são faixas aproximadas — a latência percebida real depende do pipeline de codificação do software remoto. Soluções proprietárias (TeamViewer, AnyDesk) frequentemente usam codecs personalizados e predição para reduzir a sensação de lag; software open-source/self-hosted (Tenvo, RustDesk) pode se comportar de forma diferente dependendo da configuração. Se você quer uma instalação self-hosted, veja nosso guia Desktop remoto auto-hospedado: o guia honesto de 2026 para notas de implantação.

Visão geral: dois testes complementares a executar

Faça estes dois testes em sequência. Eles isolam rede vs latência de ponta a ponta percebida pelo usuário.

1. Benchmarks ao nível de rede: ping, traceroute/MTR e iperf3 para throughput/jitter/perda de pacotes.
2. Medição de entrada-para-exibição ponta a ponta: um método de benchmark visual usando um quadrado piscante e uma câmera de alta taxa de quadros ou quadros com carimbo de tempo.

Passo 1 — Benchmarking ao nível de rede (rápido, objetivo)

Comece medindo o caminho de rede entre cliente e host. Isso não vai dizer tudo, mas rapidamente elimina problemas óbvios de rede.

Ferramentas que você vai precisar

• ping (nativo no Windows/macOS/Linux)
• traceroute ou MTR (mtr no Linux/macOS; WinMTR no Windows)
• iperf3 (instale via gerenciador de pacotes; comumente usado para throughput, jitter e perda de pacotes)

Comandos básicos e números esperados

Substitua host.example.com ou 198.51.100.10 pelo IP/nome do seu host remoto.

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

Observe o RTT min/avg/max e perda de pacotes. Na mesma LAN você deve ver <1 ms min/avg; em um link doméstico para um servidor regional 10–40 ms é comum; links transcontinentais frequentemente ficam em 80–200 ms.

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

MTR fornece perda de pacotes por hop, o que é útil para identificar um link congestionado ou problema com o ISP.

Meça jitter e perda com iperf3 (UDP)

Inicie um servidor iperf3 no host:

iperf3 -s

Do cliente execute um teste UDP ajustado para a largura de banda que você espera que sua sessão remota use. Fluxos de desktop remoto típicos são de 1–10 Mbps dependendo da resolução e da taxa de quadros; escolha 5M como teste realista:

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

iperf3 reportará perda de pacotes e jitter. Se você ver >1% de perda de pacotes ou jitter acima de ~10 ms, isso afetará materialmente alguns codecs de desktop remoto.

Simulando redes ruins

Se você quer testar como seu software remoto se comporta sob atraso, jitter ou perda de pacotes, use o netem do Linux para adicionar degradações no cliente ou host:

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

Este comando adiciona 100 ms de atraso com desvio padrão de 20 ms e 1% de perda de pacotes. Para remover as regras:

sudo tc qdisc del dev eth0 root netem

Passo 2 — Latência ponta a ponta entrada-para-exibição (latência percebida pelo usuário)

Os números de rede nem sempre correspondem à latência percebida. Uma pilha de software que faz buffer de quadros, usa um codificador lento em software, ou espera pelo V-sync pode adicionar dezenas ou centenas de milissegundos. Use este método para medir a verdadeira latência entrada-para-exibição de forma que você possa fazer benchmark.

Método A — Método da câmera de alta taxa de quadros (mais confiável, requer hardware)

Visão geral: execute uma pequena página no host que alterna um quadrado visível quando você pressiona uma tecla; conecte-se com seu cliente remoto e aponte uma câmera de 120–240 fps (ou um smartphone em alta taxa de quadros) para que ela grave tanto o monitor do host quanto a janela cliente na mesma cena. Conte os quadros entre a alternância visível no host e no cliente.

Passos:

1. No host, abra uma página simples que muda a cor de um grande quadrado na tela cada vez que você pressiona a tecla de espaço. Cole este HTML em um arquivo local:

<!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. Inicie uma sessão remota e posicione tanto o monitor físico do host quanto a janela cliente remota no enquadramento da câmera para que a câmera consiga ver ambos simultaneamente (é por isso que você precisa de um campo de visão amplo ou de mover as telas adjacentes).
3. Grave em alta taxa de quadros (120 fps é suficiente; 240 fps é melhor). Pressione SPACE e observe os quadros. Depois, percorra a gravação quadro a quadro e conte quantos quadros decorrem entre a mudança do quadrado no host e a mudança no cliente. Latência = contagem de quadros / camera_fps.

Exemplo: se você contou 6 quadros a 120 fps, latência ≈ 6 / 120 = 0,05 s (50 ms).

Método B — Timestamping por software (sem câmera, menos preciso)

Se você conseguir rodar código tanto no host quanto no cliente com relógios sincronizados (sincronização por NTP é suficiente para alinhamento ~10 ms), você pode carimbar um evento no host e fazer o cliente reportar a hora em que exibiu o evento. Isso exige modificação do cliente remoto ou uma sobreposição de teste, portanto é mais avançado.

Prós/contras: o método da câmera mede todo o pipeline, incluindo persistência do monitor e erros de temporização da câmera, mas é simples. O timestamping pode ser automatizado, mas exige sincronização de relógio apertada (use chrony ou pool.ntp.org) e um meio de detectar a atualização de quadro no cliente.

Isolando de onde vem o atraso

Uma vez que você tenha medições, quebre o problema:

• Se ping/iperf mostrarem RTT/jitter baixos e seu teste ponta a ponta ainda estiver alto, verifique codificação/decodificação ou renderização do cliente. Monitore CPU/GPU no host e no cliente (Task Manager / top / nvidia-smi). CPU alta ou enfileiramento do codificador gera lag.
• Se o iperf mostrar perda de pacotes ou jitter significativos, corrija a rede. Perda de pacotes frequentemente faz codecs travarem ou re-solicitarem quadros.
• Se a vazão é o problema (por exemplo, vídeo remoto consumindo mais banda do que o link permite), limite o desktop remoto para bitrate ou resolução menores e teste novamente.
• Verifique as configurações do software remoto: profundidade de cor, limite de taxa de quadros, aceleração de hardware (habilite NVENC ou VA-API onde disponível).

Monitorando recursos do host/cliente

Verificações típicas:

• Windows: Task Manager > abas Performance e GPU. Verifique se o codificador está usando H.264/HEVC por hardware.
• Linux: top/htop para CPU; nvidia-smi para inspecionar a utilização do codificador da GPU; iostat para gargalos relacionados a disco.
• macOS: Activity Monitor e verifique uso de GPU/codificador se suportado.

Comparando diferentes softwares remotos e configurações

Quando fizer benchmarks, mantenha o teste consistente: mesma máquina host, mesmo cliente, mesmas condições de rede, mesma resolução de exibição. Teste cada versão do cliente e cada modo de protocolo (P2P direto vs servidor relé). Algumas coisas a testar:

• LAN com fio vs Wi‑Fi vs VPN — com fio sempre terá a menor latência.
• Conexão direta vs relé: relés podem adicionar 20–100 ms dependendo da localização.
• Codificação por hardware habilitada vs codificação por software.

Nota honesta: fornecedores como AnyDesk e TeamViewer frequentemente otimizam codecs para interatividade percebida e podem superar RDP/VNC genéricos em cenários de alta latência ou baixa banda. Se você estiver comparando, execute os mesmos testes em cada um. Cobrimos comparações mais profundas em AnyDesk vs TeamViewer 2026: recursos e preços e em nosso post sobre Desktop remoto sem redirecionamento de portas se você estiver testando modos relé vs direto.

Plano prático de benchmark e pontuação

Execute este plano para produzir resultados repetíveis e comparáveis:

1. Baseline: teste LAN com fio — registre ping, iperf3 (5M) e o teste de piscar com câmera.
2. Broadband doméstico: cliente no Wi‑Fi, host com fio — execute os mesmos testes.
3. Remoto pela internet: cliente em casa, host em data center (ou no trabalho) — execute os testes e anote regiões dos servidores de relé se usados.
4. Teste de estresse: use netem para adicionar 100 ms de atraso + 2% de perda e re-execute para ver como o software se comporta sob degradação.

Avalie cada execução em três eixos (0–10): saúde da rede (baseado em iperf/ping), saúde do codificador (uso de CPU/GPU e quedas de quadro), e interatividade percebida (latência do teste com câmera). Combine-os em uma única pontuação se precisar de um ranking rápido.

Dicas e correções rápidas para reduzir latência

• Prefira Ethernet com fio em vez de Wi‑Fi. Wi‑Fi adiciona latência variável e jitter.
• Habilite codificação por hardware no host (NVENC/QuickSync/VA-API) e decodificação por hardware no cliente quando suportado.
• Reduza resolução ou taxa de quadros. 720p@30 frequentemente oferece sensação interativa melhor que 1080p@60 em links limitados.
• Use conexões P2P diretas quando possível — relés adicionam latência.
• Feche aplicativos pesados em CPU/GPU no host e no cliente para evitar enfileiramento do codificador.
• Se você controla dispositivos de rede, priorize o tráfego de desktop remoto com QoS para sessões críticas.

Documentando resultados e benchmarks

Registre os metadados do teste: nome e versão do software (por exemplo, Tenvo v0.9.x, AnyDesk 7.x, TeamViewer 15.x), versões do SO, hardware do cliente e do host, tipo de rede, saída do iperf3 e a taxa de quadros da câmera. Armazene o vídeo bruto da câmera e a contagem de quadros para que você possa reproduzir a medição mais tarde. Isso é especialmente útil ao avaliar mudanças como atualizações de driver ou configurações de codec.

Para usuários de Tenvo: nossa página de download em /download lista builds atuais; se você testar Tenvo, inclua o build/commit exato. Se planeja self-host, nosso Desktop remoto auto-hospedado: o guia honesto de 2026 explica detalhes de implantação do servidor que afetam o modo de conexão e a latência.

Conclusão

Um bom "teste de latência em área de trabalho remota" combina medições objetivas de rede com um teste ponta a ponta voltado ao usuário. As ferramentas de rede (ping, traceroute/MTR, iperf3) identificam problemas de conectividade rapidamente; o teste de piscar com câmera mede o atraso real entrada-para-exibição que as pessoas sentem. Use netem para reproduzir condições problemáticas e monitore recursos do host/cliente para localizar gargalos do codificador.

Se quiser uma linha de base repetível entre diferentes fornecedores de software, automatize os testes de rede com scripts e mantenha um registro em vídeo curto dos testes de piscar. Comparando várias execuções, você verá quanto do atraso é rede vs pipeline de software — e isso indica a correção adequada.

Se você estiver testando opções self-hosted vs relés hospedados, nosso artigo sobre Desktop remoto sem redirecionamento de portas discute em mais detalhe os tradeoffs de relé. Para comparações entre fornecedores (comportamento de codec e tradeoffs de preço), veja AnyDesk vs TeamViewer 2026: recursos e preços.

Pronto para rodar testes em um cliente open-source que você pode self-host e modificar? Baixe Tenvo em /download e siga as notas de implantação em nosso Desktop remoto auto-hospedado: o guia honesto de 2026. Se precisar de ajuda para interpretar seus resultados de benchmark, cole a saída do iperf3 e sua medição com a câmera e nós ajudaremos a analisar os gargalos prováveis.