Cómo NuviraHub mantiene ágil un escritorio remoto

En un escritorio remoto hay una cifra que importa más que ninguna: el tiempo entre un cambio en la pantalla remota y el momento en que lo ves. Por encima de 100 ms el ratón parece moverse entre miel; alrededor de 40 ms dejas de notarlo. Este artículo explica cómo NuviraHub mantiene bajo ese retardo y qué salió mal por el camino.

Cómo medimos

Cada fotograma de vídeo lleva el instante en que se capturó. El equipo que mira conoce la diferencia entre los dos relojes, así que calcula la latencia desde la captura hasta la visualización de cada fotograma y, cada 250 ms, devuelve la mediana y el mínimo al PC controlado. Los mismos valores aparecen en directo en la barra de la sesión y en el título de la ventana.

Las cifras de abajo salen de una configuración deliberadamente desfavorable: pantalla con una animación a pantalla completa, de modo que la imagen cambia siempre; red por cable. Quick Sync: PC controlado con un Intel Core i7-10710U, equipo que mira en un portátil con Intel Core i7-8550U. NVIDIA: PC controlado con un AMD Ryzen 7 5700X y una RTX 4060 Ti, equipo que mira en el mini PC con el i7-10710U.

1. La imagen se queda en la tarjeta gráfica

La pantalla se captura con la Desktop Duplication de Windows, que entrega la imagen ya como textura de la GPU. El procesador de vídeo de la GPU la convierte al formato que espera el codificador (NV12), y el codificador H.264 por hardware la toma desde ahí, a través de Media Foundation. La imagen nunca vuelve a la memoria del procesador: la conversión de color tarda alrededor de 1 ms en lugar de los 3–4 ms que necesita en la CPU.

No todos los PC tienen un codificador por hardware utilizable, así que al arrancar NuviraHub prueba los disponibles y, si hace falta, recurre a OpenH264 por software. Solo compilar OpenH264 con sus optimizaciones en ensamblador lo llevó de 19 a 9 ms por fotograma.

2. Que ningún fotograma envejezca

Las primeras mediciones entre dos PC reales eran mucho peores que en un solo equipo. Tres problemas, todos de fotogramas que esperaban cuando no debían:

• Un bloqueo mantenido durante la espera. La llamada de captura esperaba una nueva imagen (hasta 100 ms) manteniendo el bloqueo del dispositivo gráfico compartido, y la conversión y la codificación esperaban detrás: hasta 360 ms para un solo fotograma. Ahora la captura consulta sin esperar.
• Imágenes que envejecen delante del codificador. Una imagen capturada esperaba a que el codificador quedara libre y ya era vieja cuando se codificaba. Ahora primero se espera al codificador y solo después se toma la imagen más reciente: la latencia bajó de 53 a 38 ms.
• Una cola en el equipo que mira. Cuando el que mira era más lento que el PC controlado, mostraba igualmente todos los fotogramas en orden, y la latencia subía hasta 2,5 s. Ahora muestra siempre el último fotograma decodificado y descarta los ya superados. En el lado que envía, el búfer de red está limitado a 256 KB: por encima, se saltan fotogramas en lugar de ponerlos en cola.

3. Adaptarse a la red

En una red local limpia, una tasa de bits fija funciona perfectamente. En una red con retardo y pérdidas es un desastre: con 25 ms, 1 % de pérdidas y 5 Mbit/s, la latencia mediana era de 2,2 segundos, porque el vídeo seguía empujando más de lo que el enlace podía llevar y todo se acumulaba en colas.

Dos cambios lo resolvieron. El primero es una tasa de bits adaptativa: cuando la latencia mediana del último segundo supera en 60 ms el mínimo de los últimos diez segundos, durante al menos un segundo, la tasa baja un 20 %; cuando se mantiene cerca, sube un 15 %, con una pausa tras cada cambio. El segundo es BBR como control de congestión de QUIC: con pérdidas aleatorias, los algoritmos clásicos (NewReno, Cubic) interpretan cada paquete perdido como congestión y usaban menos de la mitad del ancho de banda.

4. Lo que nos enseñó la primera prueba en una red móvil

Las simulaciones son ordenadas; un punto de acceso del teléfono a través del relay no lo es. La primera prueba real por Internet encontró cinco problemas que ninguna simulación había mostrado:

• Codificación lenta confundida con congestión. En un PC cargado la codificación tardaba 130 ms por fotograma; la latencia subía y la tasa adaptativa bajaba la calidad al mínimo, como si la culpa fuera de la red. Ahora solo mira la parte de red: desde el final de la codificación hasta la llegada al equipo que mira.
• Una pantalla quieta que parece una red atascada. Con casi nada que enviar, en una red móvil la latencia de los pocos paquetes salta por sí sola entre 30 y 185 ms, y la tasa bajaba de 4 a 0,5 Mbit/s en 16 segundos sin que nada se moviera. Ahora la tasa solo cambia mientras el vídeo usa realmente una buena parte de ella.
• Picos aislados. Incluso con poco tráfico, la red móvil tenía picos de 150–600 ms cada pocos segundos. Reaccionar a cada uno llevaba la tasa al mínimo y las fotos se volvían borrosas. Ahora solo cuenta una cola que dura un segundo entero.
• Texto borroso con la pantalla quieta. El primer fotograma tras un cambio se codifica deprisa y, en un enlace lento, el texto seguía ilegible. Ahora, cuando la pantalla deja de cambiar, la última imagen se vuelve a codificar hasta 15 veces, más o menos cada 100 ms: cada pasada dedica la tasa de bits a lo que la anterior dejó atrás y, cuando la imagen coincide, casi no cuesta nada.
• Un codificador que ignora los cambios. A través de Media Foundation, Quick Sync ignora los cambios de bitrate una vez iniciada la sesión. Al principio lo reiniciábamos, y la imagen se quedaba parada alrededor de un segundo en cada cambio; ahora la sesión sigue abierta y el codificador se reconfigura con el nuevo bitrate en 1–4 ms.

5. Directo cuando es posible, y cifrado incluso cuando no

Los dos PC intentan alcanzarse directamente a través de sus routers (hole punching), usando también las direcciones locales cuando están detrás del mismo router. Si no lo consiguen, el relay del servidor reenvía los paquetes QUIC tal cual, ya cifrados de extremo a extremo: en red local el relay cuesta unos 5 ms. En las redes que bloquean UDP, los mismos paquetes viajan dentro de un WebSocket, así que el cifrado y la sesión son idénticos; entre nuestros dos PC de prueba este túnel se mantuvo en 38–39 ms.

NuviraHub es de código abierto: la tasa de bits adaptativa está en client/agent/src/abr.rs, y las mediciones y su historia en los documentos del proyecto (en inglés). Si mides algo en tu red, sobre todo con tarjetas NVIDIA o AMD, nos gustaría saberlo: abre una incidencia o escribe a support@nuvirahub.dev.