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

Game-Lag-Whitepaper › Grundursachen von TCP-Retransmissions

Verlust auf der Funkstrecke Wi-Fi / cellular link loss

Ursachen-ID rt-wireless · Hauptzuständig Extern (Extern) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

WLAN und Mobilfunknetz wiederholen eine Übertragung auf der Funkstrecke einige Male und verwerfen das Paket, wenn es dann immer noch nicht klappt. Verworfene Pakete sendet TCP erst deutlich später erneut.

Warum Schwaches Signal oder starke Funkstörungen, Übertragungen auf der Funkstrecke scheitern mehrmals hintereinander → Folge Über dem Wiederholungslimit des Funkgeräts (meist einige bis gut zehn Versuche) wird das Paket verworfen → Auf dem Bildschirm Freeze für die Wartezeit bis zur TCP-Retransmission, nachfolgende Pakete warten im Empfangspuffer, danach Zeitraffer

Symptome
Freeze, Zeitraffer, Teleportieren
Faktoren
Paketverlust, Jitter
Wer ist betroffen
Nur ich, Gleicher Haushalt
Wann
Gelegentlich, zufällig, Beim Bewegen oder Zonenwechsel
Zuständigkeit
Hauptzuständig Extern (Extern) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Server: TCP_NODELAY aktivieren (bei aktivem Nagle fehlen die nachfolgenden Pakete, an denen RACK einen Verlust erkennt), Zustandsupdates, die anfallen, während eine Retransmission die Verbindung blockiert, nicht aufstauen: nur das jeweils neueste senden (die Menge im Kernel per TCP_NOTSENT_LOWAT begrenzen). Client: TCP_NODELAY aktivieren (Verluste in Richtung der eigenen Eingaben repariert das Client-OS), bei gehäuften Verlusten oder sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen.
Aufgaben Infrastrukturteam
Wiederherstellung nach Verlusten mit RACK-TLP beschleunigen (den Funkverlust selbst kann der Server nicht verhindern, er kann nur die Wiederherstellung beschleunigen), prüfen, ob die Standardwerte aktueller Linux-Kernel net.ipv4.tcp_recovery=1 (RACK) und net.ipv4.tcp_early_retrans=3 (TLP) unverändert sind.
Aufgaben Extern
Spieler auf LAN-Kabel, 5 GHz oder 6 GHz und einen anderen Router-Standort oder Funkkanal hinweisen.
Größenordnungen
Bei 1 % Funkverlust verschwindet eines von 100 Spielpaketen. Kommen 10 Pakete pro Sekunde an, stockt das Spiel etwa alle 10 s. Ohne RACK-TLP dauert jeder dieser Stillstände so lange wie das RTO (mindestens Ping + 200 ms).
Im Graphen
Nur einzelne Ausreißer · Retransmission-Rate pro Verbindung, RTT (Ping) pro Verbindung
Wo nachsehen
Auf dem PC des Spielers je einige hundert Pings an die Router-Adresse (Gateway) und an den Spielserver senden, Verlust und Latenzschwankung vergleichen, nach Wechsel auf LAN-Kabel oder mobile Daten erneut messen. Auf dem Server mit ss -ti retrans und rtt (Mittelwert/Abweichung) der Verbindung dieses Spielers prüfen
Spricht dafür
Schon der Ping zum Router zeigt Verlust oder stark schwankende Latenz, mit LAN-Kabel verschwindet das. Auf dem Server hat nur die Verbindung dieses Spielers hohe retrans-Werte und eine große RTT-Abweichung
Spricht dagegen
Bis zum Router sauber, Verlust beginnt erst dahinter: Provider oder Route („Warteschlangenüberlauf am Engpass“, „Routenwechsel oder defekter ECMP-Pfad“). Verschlechtert sich die Lage bei mehreren Spielern desselben Providers gleichzeitig: zuerst die Providerstrecke prüfen
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Die Wiederholungen des Funkgeräts erzeugen Jitter (einige ms pro Wiederholung). Zum Verlust wird es erst, wenn das Wiederholungslimit überschritten ist. Je schlechter die Funkqualität, desto stärker werden daher die Symptome, und zwar in der Reihenfolge „Jitter → gelegentliche Freezes → häufige Freezes“. Beim Wechsel zwischen Routern bzw. Access Points (Roaming) gehen mitunter einige Dutzend ms bis einige Sekunden lang Pakete in Folge verloren. Mobilfunknetze wiederholen auf der Strecke zur Funkzelle sehr viel. Dort zeigt sich das Problem daher häufig als Latenzsprung von mehreren hundert ms und seltener als Verlust.
Reale Fälle
Square Enix 2021: FINAL FANTASY XIV: Überlastung zum Start der Erweiterung und Fehler in der Login-Warteschlange

Quellen

  1. net/wireless/core.c Linux kernel
    Standard-Wiederholungslimit im Linux-WLAN-Stack: 7 für kurze Frames, 4 für lange Frames (dot11ShortRetryLimit, dot11LongRetryLimit)
  2. RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
    Mobilfunknetze haben dank Retransmission auf der Sicherungsschicht wenig IP-Verlust, die Wiederherstellung zeigt sich aber als Jitter und Latenzsprünge
  3. Wi-Fi roaming support in Apple devices Apple
    Beim Wechsel des Access Points können erst nach abgeschlossener Authentifizierung am neuen AP wieder Daten gesendet werden, in 802.1X-Umgebungen kann das einige Sekunden dauern
  4. RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
    Definition von RACK (zeitbasierte Verlusterkennung) und TLP (erneutes Senden des letzten Pakets)
  5. IP Sysctl Linux kernel
    tcp_recovery standardmäßig 0x1 (RACK), tcp_early_retrans standardmäßig 3 (TLP aktiv), TCP_NOTSENT_LOWAT und tcp_notsent_lowat begrenzen die Menge noch nicht gesendeter Daten
  6. tcp(7) — Linux manual page Linux man-pages
    TCP_NODELAY schaltet den Nagle-Algorithmus ab, auch kleine Datenmengen werden sofort gesendet
  7. include/net/tcp.h Linux kernel
    RTO-Minimum TCP_RTO_MIN = 200 ms
  8. misc/ss.c iproute2
    ss -ti zeigt retrans:laufende/kumulierte Retransmissions und rtt:RTT/RTT-Abweichung (rttvar)

Verwandte Ursachen

Gleiche Schicht: Grundursachen von TCP-Retransmissions

Ursachen aus anderen Schichten mit demselben Symptom (Freeze)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen