Game-Lag-Whitepaper › Grundursachen von TCP-Retransmissions

Duplex-Mismatch Duplex mismatch

Ursachen-ID rt-duplex · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Nutzt eine Seite Autonegotiation und hat die andere Geschwindigkeit und Duplex fest eingestellt, arbeitet eine Seite im Halbduplex und verliert unter Last durch Kollisionen Pakete.

Warum Nur auf einer Seite sind Geschwindigkeit und Duplex fest eingestellt → Folge Eine Seite arbeitet im Vollduplex, die andere im Halbduplex, es kommt zu Kollisionen und späten Kollisionen → Auf dem Bildschirm Normalerweise unauffällig, bei steigendem Traffic für alle Spieler über dieses Gerät: Freeze, dann Zeitraffer

Symptome

Freeze, Zeitraffer

Faktoren

Paketverlust

Wer ist betroffen

Ganzer Server, Bestimmter Ort oder Kanal

Wann

Bei großem Andrang, Abendliche Stoßzeit

Zuständigkeit

Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

Aufgaben Infrastrukturteam

Beide Seiten auf Autonegotiation oder beide fest auf dieselben Werte einstellen. Netzwerk: Geschwindigkeit und Duplex im Portstatus des Switches prüfen, in den Portzählern kontrollieren, ob auf der Halbduplex-Seite späte Kollisionen und auf der Vollduplex-Seite CRC-Fehler und zu kurze Frames (Runts) zunehmen. Server/OS: Geschwindigkeit und Duplex mit ethtool prüfen.

Größenordnungen

Bei 1 Gbps über Kupfer ist Autonegotiation Pflicht, ab 10 Gbps gibt es überhaupt kein Halbduplex mehr. Heute tritt das Problem daher vor allem bei älteren Geräten mit höchstens 100 Mbps, an Management-Ports und an manchen Leitungsübergaben auf.

Im Graphen

Steigt mit Spielerzahl und Last · Späte Kollisionen und CRC-Fehler pro Port, Retransmission-Rate

Wo nachsehen

Tatsächliche Geschwindigkeit und Duplex an beiden Enden des Links prüfen. Auf dem Server ethtool nur mit dem Schnittstellennamen ausführen, am Switch Portstatus oder dot3StatsDuplexStatus per SNMP. Späte Kollisionen (Server: tx_window_errors, Switch: dot3StatsLateCollisions) und CRC-Fehler mit prüfen

Spricht dafür

Eine Seite meldet Halbduplex, die andere Vollduplex. Mit jedem Traffic-Anstieg nehmen auf der Halbduplex-Seite späte Kollisionen und auf der Vollduplex-Seite CRC-Fehler gemeinsam zu

Spricht dagegen

Geschwindigkeit und Duplex auf beiden Seiten gleich, nur CRC steigt: „Physische Fehler“. Links ab 10 Gbps kennen kein Halbduplex, dort scheidet diese Ursache aus

Prüfmittel

Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

1. Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
   Der Standard 1000BASE-T schreibt Autonegotiation vor
2. IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
   10-Gigabit-Ethernet unterstützt nur Vollduplex
3. IEEE P802.3ba Objectives IEEE
   Auch 40- und 100-Gigabit-Ethernet unterstützen nur Vollduplex
4. Interface statistics Linux kernel
   tx_window_errors ist die Zahl der Übertragungen, die an einer späten Kollision (late collision) gescheitert sind, rx_crc_errors die Zahl der mit CRC-Fehler empfangenen Pakete
5. ethtool(8) — Linux manual page ethtool
   Geschwindigkeit, Duplex und Autonegotiation über speed, duplex und autoneg bei ethtool -s einstellen, nur mit dem Schnittstellennamen zeigt ethtool die aktuelle Einstellung
6. RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
   dot3StatsDuplexStatus (zeigt den aktuellen Duplex als halfDuplex oder fullDuplex), dot3StatsLateCollisions (Zahl später Kollisionen)

Verwandte Ursachen

Gleiche Schicht: Grundursachen von TCP-Retransmissions

• Verlust auf der Funkstrecke
• Warteschlangenüberlauf am Engpass (Verlust durch Überlast)
• Überlauf flacher Puffer durch Sende-Bursts
• Policer verwirft Überschuss
• Physische Fehler (defekte Kabel, optische Module, Stecker)
• Verworfene Pakete auf dem empfangenden Server-Host
• Verworfene Pakete in Firewall und Connection Tracking
• Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz)
• MTU-Blackhole (nur große Pakete gehen wiederholt verloren)
• Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung
• Routenwechsel oder defekter ECMP-Pfad
• Unnötige Retransmission durch Latenzsprünge
• Unnötiger Fast Retransmit durch vertauschte Reihenfolge
• Verspätete oder verlorene ACKs (ausgelasteter Upload)
• RTO-Einstellung passt nicht zur Umgebung
• Langsame Wiederherstellung bei Thin Streams
• Zwischengeräte entfernen TCP-Optionen
• Zero Window (Stillstand, der wie eine Retransmission aussieht)
• Retransmission der Verbindungsanfrage (SYN)

Ursachen aus anderen Schichten mit demselben Symptom (Freeze)

• Frametime-Spikes L1 Spielprozess auf dem Client
• Garbage Collection auf dem Client L1 Spielprozess auf dem Client
• Synchrones Laden und Shader-Kompilierung im Main-Thread L1 Spielprozess auf dem Client
• Langsamer Datenträger bremst Asset-Streaming L1 Spielprozess auf dem Client
• Prüfungen des Sicherheitsmoduls (Anti-Cheat) L1 Spielprozess auf dem Client
• Wechsel WLAN ↔ LTE/5G L2 Client-OS und Gerät
• Zu wenig Arbeitsspeicher und Swap auf dem Client L2 Client-OS und Gerät
• Zu wenig Grafikspeicher (VRAM) L2 Client-OS und Gerät

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen