Wie NuviraHub einen Remote-Desktop reaktionsschnell hält

Bei einem Remote-Desktop zählt eine Zahl mehr als alle anderen: die Zeit zwischen einer Änderung auf dem entfernten Bildschirm und dem Moment, in dem man sie sieht. Über 100 ms fühlt sich die Maus an, als würde sie durch Honig gezogen; um 40 ms fällt es nicht mehr auf. Dieser Artikel erklärt, wie NuviraHub diese Verzögerung niedrig hält und was unterwegs schiefging.

Wie wir messen

Jedes Videobild trägt den Zeitpunkt seiner Aufnahme mit sich. Der zuschauende PC kennt den Versatz zwischen den beiden Uhren und berechnet so für jedes Bild die Latenz von der Aufnahme bis zur Anzeige; alle 250 ms schickt er Median und Minimum an den gesteuerten PC zurück. Dieselben Werte erscheinen live in der Sitzungsleiste und im Fenstertitel.

Die folgenden Werte stammen aus einem bewusst ungünstigen Aufbau: Bildschirm mit einer Vollbildanimation, das Bild ändert sich also ständig; kabelgebundenes Netz. Quick Sync: gesteuerter PC mit Intel Core i7-10710U, Zuschauer auf einem Laptop mit Intel Core i7-8550U. NVIDIA: gesteuerter PC mit AMD Ryzen 7 5700X und RTX 4060 Ti, Zuschauer auf dem Mini-PC mit dem i7-10710U.

1. Das Bild bleibt auf der Grafikkarte

Der Bildschirm wird mit der Desktop Duplication von Windows aufgenommen, die das Bild bereits als GPU-Textur liefert. Der Videoprozessor der GPU wandelt es in das Format um, das der Encoder erwartet (NV12), und der H.264-Hardware-Encoder übernimmt es direkt, über Media Foundation. Das Bild wandert nie zurück in den Arbeitsspeicher des Prozessors: Die Farbumwandlung dauert etwa 1 ms statt der 3–4 ms auf der CPU.

Nicht jeder PC hat einen brauchbaren Hardware-Encoder, deshalb testet NuviraHub beim Start die vorhandenen und weicht bei Bedarf auf OpenH264 in Software aus. Allein OpenH264 mit seinen Assembler-Optimierungen zu kompilieren, brachte es von 19 auf 9 ms pro Bild.

2. Kein Bild darf altern

Die ersten Messungen zwischen zwei echten PCs waren viel schlechter als auf einem einzelnen Rechner. Drei Probleme, alle mit Bildern, die warteten, obwohl sie es nicht sollten:

• Eine Sperre, die beim Warten gehalten wurde. Der Aufnahmeaufruf wartete auf ein neues Bild (bis zu 100 ms) und hielt dabei die Sperre des gemeinsam genutzten Grafikgeräts; Umwandlung und Kodierung warteten dahinter: bis zu 360 ms für ein einziges Bild. Jetzt fragt die Aufnahme ab, ohne zu warten.
• Bilder, die vor dem Encoder altern. Ein aufgenommenes Bild wartete, bis der Encoder frei war, und war beim Kodieren schon alt. Jetzt wird zuerst auf den Encoder gewartet und erst dann das neueste Bild genommen: Die Latenz sank von 53 auf 38 ms.
• Eine Warteschlange beim Zuschauer. War der Zuschauer langsamer als der gesteuerte PC, zeigte er trotzdem alle Bilder der Reihe nach, und die Latenz stieg bis auf 2,5 s. Jetzt zeigt er immer das zuletzt dekodierte Bild und verwirft überholte. Auf der Senderseite ist der Netzwerkpuffer auf 256 KB begrenzt: Darüber hinaus werden Bilder übersprungen statt eingereiht.

3. Sich dem Netz anpassen

In einem sauberen lokalen Netz ist eine feste Bitrate völlig in Ordnung. In einem Netz mit Verzögerung und Verlusten ist sie eine Katastrophe: Mit 25 ms, 1 % Verlust und 5 Mbit/s lag der Median der Latenz bei 2,2 Sekunden, weil das Video mehr schob, als die Leitung tragen konnte, und sich alles in Warteschlangen staute.

Zwei Änderungen haben das gelöst. Die erste ist eine adaptive Bitrate: Liegt der Median der Latenz der letzten Sekunde mindestens eine Sekunde lang um 60 ms über dem Minimum der letzten zehn Sekunden, sinkt die Bitrate um 20 %; bleibt er nah daran, steigt sie um 15 %, mit einer Pause nach jeder Änderung. Die zweite ist BBR als Staukontrolle von QUIC: Bei zufälligen Verlusten deuten die klassischen Algorithmen (NewReno, Cubic) jedes verlorene Paket als Stau und nutzten weniger als die Hälfte der Bandbreite.

4. Was uns der erste Test im Mobilfunknetz gelehrt hat

Simulationen sind aufgeräumt; ein Handy-Hotspot über das Relay ist es nicht. Der erste echte Test über das Internet brachte fünf Probleme ans Licht, die keine Simulation gezeigt hatte:

• Langsame Kodierung, für Stau gehalten. Auf einem ausgelasteten PC dauerte die Kodierung 130 ms pro Bild; die Latenz stieg, und die adaptive Bitrate senkte die Qualität aufs Minimum, als läge es am Netz. Jetzt zählt nur der Netzanteil: vom Ende der Kodierung bis zur Ankunft beim Zuschauer.
• Ein ruhiger Bildschirm, der wie ein hängendes Netz aussieht. Mit fast nichts zu senden springt die Latenz der wenigen Pakete im Mobilfunknetz von selbst zwischen 30 und 185 ms, und die Bitrate fiel in 16 Sekunden von 4 auf 0,5 Mbit/s, ohne dass sich etwas bewegte. Jetzt ändert sich die Bitrate nur, solange das Video tatsächlich einen guten Teil davon nutzt.
• Einzelne Spitzen. Selbst bei wenig Verkehr hatte das Mobilfunknetz alle paar Sekunden Spitzen von 150–600 ms. Auf jede zu reagieren, drückte die Bitrate aufs Minimum, und Fotos wurden unscharf. Jetzt zählt nur eine Warteschlange, die eine ganze Sekunde anhält.
• Unscharfer Text bei ruhigem Bildschirm. Das erste Bild nach einer Änderung wird in Eile kodiert, und auf einer langsamen Leitung blieb der Text unlesbar. Jetzt wird das letzte Bild, sobald sich der Bildschirm nicht mehr ändert, bis zu 15-mal neu kodiert, etwa alle 100 ms: Jeder Durchgang verwendet die Bitrate für das, was der vorige ausgelassen hat, und sobald das Bild übereinstimmt, kostet es fast nichts mehr.
• Ein Encoder, der Änderungen ignoriert. Über Media Foundation ignoriert Quick Sync Änderungen der Bitrate, sobald eine Sitzung läuft. Anfangs haben wir ihn neu gestartet, und das Bild stand bei jeder Änderung etwa eine Sekunde still; jetzt bleibt die Sitzung offen und der Encoder wird in 1–4 ms mit der neuen Bitrate neu konfiguriert.

5. Direkt, wenn möglich, und verschlüsselt, wenn nicht

Die beiden PCs versuchen, sich durch ihre Router hindurch direkt zu erreichen (Hole Punching), und nutzen dabei auch lokale Adressen, wenn sie hinter demselben Router stehen. Gelingt das nicht, leitet das Relay des Servers die QUIC-Pakete unverändert weiter, bereits Ende-zu-Ende-verschlüsselt: Im lokalen Netz kostet das Relay etwa 5 ms. In Netzen, die UDP sperren, laufen dieselben Pakete in einem WebSocket, Verschlüsselung und Sitzung sind also identisch; zwischen unseren beiden Test-PCs blieb dieser Tunnel bei 38–39 ms.

NuviraHub ist Open Source: Die adaptive Bitrate steckt in client/agent/src/abr.rs, die Messungen und ihre Geschichte in den Projektdokumenten (auf Englisch). Wenn Sie in Ihrem Netz etwas messen, besonders mit NVIDIA- oder AMD-Karten, freuen wir uns über Rückmeldung: Issue eröffnen oder an support@nuvirahub.dev schreiben.