Come NuviraHub tiene reattivo un desktop remoto

In un desktop remoto c'è un numero che conta più di tutti: il tempo tra un cambiamento sullo schermo remoto e il momento in cui lo vedi. Sopra i 100 ms il mouse sembra muoversi nel miele; intorno ai 40 ms non ci fai più caso. Questo articolo spiega come NuviraHub tiene basso quel ritardo e cosa è andato storto lungo la strada.

Come misuriamo

Ogni fotogramma porta con sé il momento in cui è stato catturato. Chi guarda conosce lo scarto tra i due orologi, quindi calcola la latenza dalla cattura alla visualizzazione di ogni fotogramma, e ogni 250 ms ne rimanda mediana e minimo al PC controllato. Gli stessi valori compaiono dal vivo nella barra della sessione e nel titolo della finestra.

I numeri qui sotto vengono da una configurazione volutamente sfavorevole: schermo con un'animazione a tutto schermo, quindi l'immagine cambia sempre; rete cablata. Quick Sync: PC controllato con Intel Core i7-10710U, chi guarda un portatile con Intel Core i7-8550U. NVIDIA: PC controllato con AMD Ryzen 7 5700X e RTX 4060 Ti, chi guarda il mini PC con i7-10710U.

1. L'immagine resta nella scheda grafica

Lo schermo viene catturato con la Desktop Duplication di Windows, che consegna l'immagine già come texture della GPU. Il processore video della GPU la converte nel formato che vuole l'encoder (NV12) e l'encoder H.264 hardware la prende da lì, tramite Media Foundation. L'immagine non torna mai nella memoria del processore: la conversione del colore costa circa 1 ms invece dei 3–4 ms che servono sulla CPU.

Non tutti i PC hanno un encoder hardware utilizzabile, quindi all'avvio NuviraHub prova quelli disponibili e, se serve, ripiega su OpenH264 in software. Solo compilare OpenH264 con le sue ottimizzazioni in assembly l'ha portato da 19 a 9 ms per fotogramma.

2. Mai lasciare invecchiare un fotogramma

Le prime misure tra due PC veri erano molto peggio di quelle su un solo computer. Tre problemi, tutti di fotogrammi che aspettavano quando non dovevano:

• Un blocco tenuto mentre si aspetta. La chiamata di cattura aspettava una nuova immagine (fino a 100 ms) tenendo il blocco del dispositivo grafico condiviso, e conversione e codifica restavano in fila dietro: fino a 360 ms per un solo fotogramma. Ora la cattura controlla senza aspettare.
• Immagini che invecchiano davanti all'encoder. Un'immagine catturata aspettava che l'encoder si liberasse, ed era già vecchia quando veniva codificata. Ora si aspetta prima l'encoder e solo dopo si prende l'immagine più recente: la latenza è scesa da 53 a 38 ms.
• Una coda in chi guarda. Quando chi guarda era più lento del PC controllato mostrava comunque tutti i fotogrammi in ordine, e la latenza saliva fino a 2,5 s. Ora mostra sempre l'ultimo fotogramma decodificato e scarta quelli già superati. Dal lato di chi invia, il buffer di rete è limitato a 256 KB: oltre, si saltano fotogrammi invece di accodarli.

3. Seguire la rete

Su una rete locale pulita un bitrate fisso va benissimo. Su una rete con ritardo e perdite è un disastro: con 25 ms, 1% di perdite e 5 Mbit/s la latenza mediana era di 2,2 secondi, perché il video continuava a spingere più di quanto il collegamento potesse portare e tutto si accumulava nelle code.

Due modifiche l'hanno risolto. La prima è un bitrate adattivo: quando la latenza mediana dell'ultimo secondo supera di 60 ms il minimo degli ultimi dieci secondi, per almeno un secondo, il bitrate scende del 20%; quando resta vicina sale del 15%, con una pausa dopo ogni cambio. La seconda è BBR come controllo di congestione di QUIC: con perdite casuali gli algoritmi classici (NewReno, Cubic) leggono ogni pacchetto perso come congestione e usavano meno della metà della banda.

4. Cosa ci ha insegnato la prima prova su rete mobile

Le simulazioni sono ordinate; un hotspot del telefono attraverso il relay no. La prima prova vera via Internet ha trovato cinque problemi che nessuna simulazione aveva mostrato:

• Codifica lenta scambiata per congestione. Su un PC carico la codifica prendeva 130 ms per fotogramma; la latenza saliva e il bitrate adattivo tagliava la qualità al minimo, come se la colpa fosse della rete. Ora guarda solo la parte di rete: dalla fine della codifica all'arrivo da chi guarda.
• Uno schermo fermo che sembra una rete bloccata. Con quasi niente da inviare, su rete mobile la latenza dei pochi pacchetti salta da sola tra 30 e 185 ms, e il bitrate scendeva da 4 a 0,5 Mbit/s in 16 secondi senza che niente si muovesse. Ora il bitrate cambia solo mentre il video ne usa davvero una buona parte.
• Picchi isolati. Anche con poco traffico la rete mobile aveva picchi di 150–600 ms ogni pochi secondi. Reagire a ognuno portava il bitrate al minimo e le foto diventavano sfocate. Ora conta solo una coda che dura un secondo intero.
• Testo sfocato a schermo fermo. Il primo fotogramma dopo un cambiamento è codificato di fretta, e su un collegamento lento il testo restava illeggibile. Ora, quando lo schermo smette di cambiare, l'ultima immagine viene ricodificata fino a 15 volte, circa ogni 100 ms: ogni passaggio spende il bitrate su ciò che il precedente aveva lasciato indietro, e quando l'immagine coincide non costa quasi niente.
• Un encoder che ignora i cambi. Tramite Media Foundation, Quick Sync ignora i cambi di bitrate una volta iniziata la sessione. All'inizio lo riavviavamo, e l'immagine restava ferma per circa un secondo a ogni cambio; ora la sessione resta aperta e l'encoder si riconfigura con il nuovo bitrate in 1–4 ms.

5. Diretto quando possibile, e cifrato anche quando no

I due PC provano a raggiungersi direttamente attraverso i loro router (hole punching), usando anche gli indirizzi locali quando sono dietro lo stesso router. Quando non ci riescono, il relay del server inoltra i pacchetti QUIC così come sono, già cifrati da un capo all'altro: in rete locale il relay costa circa 5 ms. Nelle reti che bloccano UDP gli stessi pacchetti viaggiano dentro una WebSocket, quindi cifratura e sessione sono identiche; tra i nostri due PC di prova questo tunnel è rimasto a 38–39 ms.

NuviraHub è open source: il bitrate adattivo è in client/agent/src/abr.rs, le misure e la loro storia nei documenti del progetto (in inglese). Se misuri qualcosa sulla tua rete, soprattutto con schede NVIDIA o AMD, ci farebbe piacere saperlo: apri una segnalazione o scrivi a support@nuvirahub.dev.