Prueba de latencia en escritorio remoto: medir y comparar

Necesitas que el control remoto se sienta ágil —no con retardos ni impredecible. Si arrastrar una ventana, escribir o mover el mouse en una sesión remota se siente lento, estás solucionando latencia. Esta guía muestra cómo ejecutar una "prueba de latencia en escritorio remoto" práctica que separa problemas de red de problemas de codificación/renderizado y proporciona mediciones repetibles que puedes comparar a lo largo del tiempo.

Por qué medir la latencia (y qué esperar)

La latencia en sesiones de escritorio remoto es multidimensional. Existe el tiempo de ida y vuelta de red bruto (RTT), jitter y pérdida de paquetes, la latencia del codificador/decodificador en host y cliente, y la latencia de procesamiento de pantalla/entrada en cada máquina. Todo eso se acumula en el retraso que percibe una persona al intentar hacer clic o arrastrar.

Umbrales prácticos que puedes usar como regla general:

• < 20 ms RTT: imperceptible en la mayoría de los casos (excelente para trabajo interactivo).
• 20–60 ms RTT: muy usable para la mayoría del trabajo remoto (solo un retraso menor en movimientos rápidos del puntero).
• 60–150 ms RTT: aceptable pero perceptible; algunas tareas (dibujo, juegos) se verán afectadas.
• > 150–200 ms RTT: claramente perceptible, no apto para trabajo de interfaz de precisión.

Esos son rangos aproximados —la latencia percibida real depende de la canalización de codificación del software remoto. Las soluciones propietarias (TeamViewer, AnyDesk) suelen usar códecs personalizados y predicción para reducir la sensación de lag; el software de código abierto/autohospedado (Tenvo, RustDesk) puede comportarse de forma distinta según la configuración. Si quieres una instalación autohospedada, consulta nuestra guía de escritorio remoto autohospedado para notas de despliegue.

Resumen: dos pruebas complementarias a ejecutar

Haz estas dos pruebas en secuencia. Aíslan la red frente a la latencia percibida de extremo a extremo.

1. Benchmarks a nivel de red: ping, traceroute/MTR e iperf3 para throughput/jitter/pérdida de paquetes.
2. Medición de extremo a extremo de entrada a pantalla: un método visual de benchmark usando un cuadrado intermitente y una cámara de alta velocidad o fotogramas con marcas de tiempo.

Paso 1 — Medición a nivel de red (rápida, objetiva)

Comienza midiendo la ruta de red entre cliente y host. Esto no te dirá todo, pero rápidamente descarta problemas obvios de red.

Herramientas que necesitarás

• ping (integrado en Windows/macOS/Linux)
• traceroute o MTR (mtr en Linux/macOS; WinMTR en Windows)
• iperf3 (instala vía el gestor de paquetes; se usa comúnmente para throughput, jitter y pérdida de paquetes)

Comandos básicos y números esperados

Sustituye host.example.com o 198.51.100.10 por la IP/nombre de tu host remoto.

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

Mira el RTT min/avg/max y la pérdida de paquetes. En la misma LAN deberías ver <1 ms min/avg; sobre una conexión doméstica a un servidor regional 10–40 ms es común; enlaces transcontinentales suelen estar en 80–200 ms.

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

MTR te da pérdida por salto, útil para detectar un enlace congestionado o un problema del ISP.

Mide jitter y pérdida con iperf3 (UDP)

Inicia un servidor iperf3 en el host:

iperf3 -s

Desde el cliente ejecuta una prueba UDP ajustada al ancho de banda que esperas que use tu sesión remota. Los streams típicos de escritorio remoto son de 1–10 Mbps según resolución y FPS; elige 5M como prueba realista:

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

iperf3 reportará pérdida de paquetes y jitter. Si ves >1% de pérdida de paquetes o jitter por encima de ~10 ms, eso afectará de forma material a algunos códecs de escritorio remoto.

Simular redes deficientes

Si quieres probar cómo se comporta tu software remoto bajo retardo, jitter o pérdida de paquetes, usa netem en Linux para añadir deterioros en el cliente o el host:

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

Este comando añade 100 ms de retardo con 20 ms de desviación estándar y 1% de pérdida de paquetes. Para eliminar las reglas:

sudo tc qdisc del dev eth0 root netem

Paso 2 — Latencia de entrada a pantalla de extremo a extremo (latencia percibida por el usuario)

Los números de red no siempre coinciden con la latencia percibida. Una pila de software que acumula frames, usa un codificador lento o espera V-sync puede añadir decenas o cientos de milisegundos. Usa este método para medir la latencia real de entrada a pantalla de forma que puedas comparar resultados.

Método A — Método con cámara de alta tasa de cuadros (más fiable, requiere hardware)

Resumen: ejecuta una pequeña página web en el host que alterna un cuadrado visible cuando presionas una tecla; conéctate con tu cliente remoto y apunta una cámara de 120–240 fps (o un smartphone en modo alta velocidad) para grabar al mismo tiempo la pantalla del host y la ventana cliente. Cuenta los fotogramas entre que el host cambia y el cliente cambia.

Pasos:

1. En el host, abre una página simple que cambie el color de un cuadrado grande cada vez que presiones la barra espaciadora. Pega este HTML en un archivo 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. Inicia una sesión remota y posiciona tanto el monitor físico del host como la ventana cliente remota dentro del encuadre de la cámara para que la cámara pueda ver ambos simultáneamente (por eso necesitas un campo visual amplio o mover las pantallas adyacentes).
3. Graba a alta tasa de cuadros (120 fps es suficiente; 240 fps mejor). Presiona SPACE y observa los fotogramas. Luego, revisa la grabación fotograma a fotograma y cuenta cuántos fotogramas pasan entre que cambia el cuadrado en el host y que cambia en el cliente. Latencia = número de fotogramas / cámara_fps.

Ejemplo: si contaste 6 fotogramas a 120 fps, latencia ≈ 6 / 120 = 0.05 s (50 ms).

Método B — Registro de marcas de tiempo por software (sin cámara, menos preciso)

Si puedes ejecutar código tanto en host como en cliente con relojes sincronizados (NTP-synced es suficiente para ~10 ms de alineación), puedes poner una marca de tiempo en un evento en el host y hacer que el cliente reporte la hora en que muestra el evento. Esto requiere modificar el cliente remoto o añadir una superposición de prueba, por lo que es más avanzado.

Pros/contras: el método de cámara mide toda la canalización, incluyendo la persistencia del monitor y errores de sincronización de la cámara, pero es directo. El registro de marcas de tiempo puede automatizarse pero requiere sincronización de reloj precisa (usa chrony o pool.ntp.org) y una forma de detectar la actualización de frame en el cliente.

Aislar de dónde proviene la latencia

Una vez que tengas mediciones, descompón el problema:

• Si ping/iperf muestran bajo RTT/jitter y tu prueba de extremo a extremo sigue alta, revisa la codificación/decodificación o el renderizado del cliente. Monitorea CPU/GPU en host y cliente (Task Manager / top / nvidia-smi). CPU alta o acumulación en la cola de codificación produce lag.
• Si iperf muestra pérdida de paquetes o jitter significativos, arregla la red. La pérdida de paquetes suele hacer que los códecs se detengan o re-soliciten frames.
• Si el throughput es el problema (por ejemplo, el video remoto usa constantemente más ancho de banda del que permite tu enlace), reduce el bitrate o la resolución del escritorio remoto y vuelve a probar.
• Revisa la configuración del software remoto: profundidad de color, límite de FPS, aceleración por hardware (habilita NVENC o VA-API donde esté disponible).

Monitoreo de recursos en host/cliente

Comprobaciones típicas:

• Windows: Task Manager > pestañas Performance y GPU. Verifica si el codificador está usando hardware H.264/HEVC.
• Linux: top/htop para CPU; nvidia-smi para inspeccionar la utilización del codificador de GPU; iostat para detectar bloqueos relacionados con disco.
• macOS: Activity Monitor y revisa el uso de GPU/codificador si está soportado.

Comparar distintos software y configuraciones de escritorio remoto

Al benchmarkear, mantén la prueba consistente: misma máquina host, mismo cliente, mismas condiciones de red, misma resolución de pantalla. Prueba cada versión del cliente y cada modo de protocolo (P2P directo vs servidor relay). Algunas cosas a probar:

• LAN cableada vs Wi‑Fi vs VPN — la cableada siempre tendrá la menor latencia.
• Conexión directa vs relay: los relays pueden añadir 20–100 ms según la ubicación.
• Codificación por hardware activada vs codificación por software.

Nota honesta: proveedores como AnyDesk y TeamViewer suelen optimizar códecs para interactividad percibida y pueden superar a RDP/VNC genéricos en escenarios de alta latencia o bajo ancho de banda. Si vas a comparar, ejecuta las mismas pruebas en cada uno. Hemos tratado comparaciones más profundas en AnyDesk vs TeamViewer: comparación de funciones y precios y en nuestra publicación sobre Escritorio remoto sin reenvío de puertos: explicado si estás probando modos relay vs directo.

Plan de benchmark práctico y sistema de puntuación

Ejecuta este plan para producir resultados repetibles y comparables:

1. Baseline: prueba LAN cableada — registra ping, iperf3 (5M) y la prueba de parpadeo con cámara.
2. Broadband doméstico: cliente en Wi‑Fi, host cableado — ejecuta las mismas pruebas.
3. Remoto por Internet: cliente en casa, host en centro de datos (o en el trabajo) — ejecuta pruebas y anota la región de los servidores relay si se usan.
4. Prueba de estrés: usa netem para añadir 100 ms de retardo + 2% de pérdida y vuelve a ejecutar para ver cómo se comporta el software bajo deterioro.

Puntúa cada ejecución en tres ejes (0–10): salud de la red (basado en iperf/ping), salud del codificador (uso CPU/GPU y pérdida de frames) e interactividad percibida (latencia de la prueba con cámara). Combínalos en una puntuación única si necesitas un ranking rápido.

Consejos y soluciones rápidas para reducir la latencia

• Prefiere Ethernet cableado sobre Wi‑Fi. Wi‑Fi añade latencia y jitter variables.
• Activa la codificación por hardware en el host (NVENC/QuickSync/VA-API) y la decodificación por hardware en el cliente cuando sea soportado.
• Reduce resolución o tasa de cuadros. 720p@30 a menudo ofrece una sensación interactiva mejor que 1080p@60 en enlaces limitados.
• Usa conexiones P2P directas cuando sea posible — los relays añaden latencia.
• Cierra aplicaciones intensivas en CPU/GPU en host y cliente para evitar acumulación en la cola del codificador.
• Si controlas los dispositivos de red, prioriza el tráfico de escritorio remoto con QoS para sesiones críticas.

Documentar resultados y benchmarks

Registra los metadatos de la prueba: nombre y versión del software (p. ej., Tenvo v0.9.x, AnyDesk 7.x, TeamViewer 15.x), versiones de OS, hardware del cliente y del host, tipo de red, salida de iperf3 y la tasa de cuadros de la cámara. Guarda el video bruto de la cámara y los fotogramas contados para que puedas reproducir la medición más adelante. Esto es especialmente útil al evaluar cambios como actualizaciones de drivers o ajustes de códecs.

Para usuarios de Tenvo: nuestra página de descargas en /download lista los builds actuales; si pruebas Tenvo, incluye el build/commit exacto. Si planeas autohospedar, nuestra Escritorio remoto autoalojado: la guía honesta de 2026 explica detalles de despliegue del servidor que afectan el modo de conexión y la latencia.

Resumen

Una buena "prueba de latencia en escritorio remoto" combina mediciones objetivas de red con una prueba de extremo a extremo orientada al usuario. Las herramientas de red (ping, traceroute/MTR, iperf3) identifican problemas de conectividad rápidamente; la prueba de parpadeo con cámara mide el retraso real de entrada a pantalla que sienten las personas. Usa netem para reproducir condiciones problemáticas y monitorea recursos de host/cliente para encontrar cuellos de botella del codificador.

Si quieres una línea base repetible entre distintos proveedores de software, automatiza las pruebas de red con scripts y guarda un breve registro en video de las pruebas de parpadeo. Comparando varias ejecuciones verás cuánto del retraso es red frente a la canalización de software —y eso te indica la solución correcta.

Si estás probando opciones autohospedadas vs relays alojados, nuestro artículo sobre Escritorio remoto sin reenvío de puertos: explicado discute los tradeoffs de los relays con más detalle. Para comparaciones entre proveedores (comportamiento de códecs y tradeoffs de precios), revisa AnyDesk vs TeamViewer: comparación de funciones y precios.

¿Listo para ejecutar pruebas en un cliente de código abierto que puedes autohospedar y modificar? Descarga Tenvo en /download y sigue las notas de despliegue en nuestra Escritorio remoto autoalojado: la guía honesta de 2026. Si necesitas ayuda para interpretar tus resultados de benchmark, pega la salida de iperf3 y tu medición con la cámara y revisaremos los cuellos de botella probables.