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

Game-Lag-Whitepaper › L8 Sockets und Protokolle

Einbruch der Senderate durch Congestion Control Congestion control backoff

Ursachen-ID sk-congestion · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

TCP wertet Paketverlust als Zeichen von Überlast und senkt die Senderate um 30–50 %. Auf Paketverlust im WLAN reagiert es genauso.

Warum Bei hohem Sendevolumen etwas Paketverlust im WLAN oder auf der Leitung → Folge TCP senkt die Senderate deutlich und erholt sich nur langsam (CUBIC, Standard unter Linux und Windows, senkt um 30 %) → Auf dem Bildschirm In belebten Gebieten stauen sich Updates: Zeitraffer und Input-Lag

Symptome
Zeitraffer, Input-Lag
Faktoren
Latenz, Stillstand
Wer ist betroffen
Nur ich
Wann
Bei großem Andrang
Zuständigkeit
Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Sendevolumen senken (nur Sichtbereich, nur Änderungen), Daten verteilt senden, nicht alles auf einen Schlag.
Aufgaben Infrastrukturteam
Auf eine Congestion Control wie BBR umstellen (tcp_congestion_control).
Im Graphen
Steigt langsam, fällt abrupt · Congestion Window (cwnd) und Senderate pro Verbindung
Wo nachsehen
Verbindungen von Spielern mit gestauten Updates mehrmals per ss -ti erfassen, Verlauf von cwnd und ssthresh sowie den Namen der Congestion Control (cubic, bbr) prüfen und kontrollieren, ob sich die Send-Q staut
Spricht dafür
cwnd fällt nach Paketverlust stark und steigt langsam wieder, immer wieder, in dieser Zeit staut sich die Send-Q, zeitgleich mit Meldungen über Zeitraffer und Input-Lag
Spricht dagegen
cwnd reichlich groß, trotzdem Stau: Window der Empfangsseite („Zero Window (Stillstand, der wie eine Retransmission aussieht)“) oder Sendeseite des Servers
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

  1. RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
    CUBIC verkleinert das Window bei Verlust auf das 0,7-Fache (30 % weniger), Reno auf das 0,5-Fache, CUBIC ist Standard unter Linux, Windows und bei Apple
  2. TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
    Verlustbasierte Congestion Control senkt die Senderate auch bei Verlusten deutlich, die nicht auf Überlast zurückgehen, BBR urteilt anhand von Zustellrate und RTT
  3. IP Sysctl Linux kernel
    tcp_congestion_control wählt den Congestion-Control-Algorithmus für neue Verbindungen
  4. ss(8) — Linux manual page iproute2
    cwnd und ssthresh bei -i sowie Name des Congestion-Control-Algorithmus
  5. net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
    Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes

Verwandte Ursachen

Gleiche Schicht: L8 Sockets und Protokolle

Ursachen aus anderen Schichten mit demselben Symptom (Zeitraffer)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen