한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › Grundursachen von TCP-Retransmissions

Verspätete oder verlorene ACKs (ausgelasteter Upload) ACK path congestion on asymmetric links

Ursachen-ID rt-ack-path · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Die Daten sind angekommen, aber das ACK („erhalten“) verspätet sich in der vollen Upload-Warteschlange oder geht verloren. Dann wertet der Sender das als Verlust und sendet erneut.

Warum Upload zu Hause durch Video-Uploads oder Cloud-Backups voll ausgelastet → Folge ACKs verspäten sich in der Warteschlange des Routers um mehrere hundert ms oder werden beim Überlauf verworfen → Auf dem Bildschirm Die Spielpakete vom Server kommen meist pünktlich an. Die eigenen Eingaben stecken in derselben Upload-Warteschlange und kommen spät an: Input-Lag und Rubberbanding, gelegentlich unnötige Retransmissions

Symptome
Input-Lag, Rubberbanding
Faktoren
Latenz, Paketverlust
Wer ist betroffen
Gleicher Haushalt
Wann
Gelegentlich, zufällig, Abendliche Stoßzeit
Zuständigkeit
Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Bei sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen und den Hinweis „Laufende Uploads prüfen“ einblenden.
Aufgaben Extern
Spieler darauf hinweisen, mit SQM am Router die Upload-Warteschlange kurz zu halten, kleine Pakete (ACKs) zu priorisieren und die Upload-Rate (Video-Uploads, Cloud-Backups) zu begrenzen.
Größenordnungen
Ein späteres ACK bestätigt die vorherigen mit, daher schadet es meist nicht, wenn einige verloren gehen. Das Problem sind die Verzögerungen in der Warteschlange.
Im Graphen
Nur einzelne Ausreißer · RTT (Ping) pro Verbindung
Wo nachsehen
Auf dem PC des Spielers den Ping zum Spielserver mit und ohne laufenden Upload (Video-Upload, Cloud-Backup) vergleichen. Auf dem Server rtt der Verbindung dieses Spielers mit ss -ti prüfen
Spricht dafür
Nur während des Uploads steigt der Ping auf mehrere hundert ms, Input-Lag und Rubberbanding treten auf, nach dem Stoppen des Uploads normalisiert sich alles schnell. Serverseitig steigt zur selben Zeit auch rtt dieser Verbindung
Spricht dagegen
Verlust und Latenz unabhängig vom Upload: „Verlust auf der Funkstrecke“ oder eine Ursache auf der Route. Nur die Richtung Server → Spieler ist langsam, unabhängig vom Upload: „Warteschlangenüberlauf am Engpass“
Prüfmittel
Prüfung in der Umgebung des Spielers

Quellen

  1. RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
    Verspäten sich ACKs auf asymmetrischen Leitungen mit schmalem Upload oder gehen verloren, sinkt die TCP-Leistung, ACKs bestätigen kumulativ, daher springt bei Verlust einiger ACKs ein späteres ein, Gegenmaßnahmen wie ACK-Priorisierung im Scheduling
  2. Smart Queue Management Bufferbloat.net
    Warteschlangen im Router durch Warteschlangenverwaltung und Shaping kurz halten
  3. tc-cake(8) — Linux manual page iproute2
    CAKE trennt Flows und minimiert die Latenz für Flows mit vereinzelten Paketen (sparse flows)
  4. ss(8) — Linux manual page iproute2
    rtt (mittlere Umlaufzeit) und rttvar (Abweichung) bei ss -i

Verwandte Ursachen

Gleiche Schicht: Grundursachen von TCP-Retransmissions

Ursachen aus anderen Schichten mit demselben Symptom (Input-Lag)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen