Game-Lag-Whitepaper › L5 Netzwerkgeräte im Rechenzentrum

Vollauslastung der Rechenzentrumsanbindung Uplink saturation

Ursachen-ID dc-uplink · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Nutzen Patch-Verteilung, Log-Übertragung oder Backups dieselbe Leitung wie das Spiel, läuft die Leitung voll.

Warum Große Übertragungen belegen dieselbe Leitung → Folge Warteschlange und Paketverlust auf der Leitung steigen → Auf dem Bildschirm Höherer Ping und Teleportieren auf dem ganzen Server

Symptome

Input-Lag, Teleportieren

Faktoren

Latenz, Paketverlust

Wer ist betroffen

Ganzer Server

Wann

In festen Abständen, Bei großem Andrang

Zuständigkeit

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

Aufgaben Infrastrukturteam

Netzwerk: Spiel-Traffic priorisieren (QoS), große Übertragungen auf eine eigene Leitung legen, Alarm auf die Leitungsauslastung. Server/OS: Backups, Log-Übertragung und Deployments drosseln und zu ruhigen Zeiten ausführen.

Im Graphen

Plateau am Limit · Leitungsauslastung, RTT (Ping)

Wo nachsehen

Auslastung (berechnet aus SNMP ifHCInOctets und ifHCOutOctets) und Ausgangsdrops (ifOutDiscards) am Interface der Rechenzentrumsanbindung (Uplink) auf dieselbe Zeitachse legen wie die Zeitpläne für Backups, Deployments und Log-Übertragungen

Spricht dafür

Sobald die Leitungsauslastung flach an der Bandbreitengrenze anliegt, steigen RTT und Drops auf dem ganzen Server, und dieser Zeitpunkt fällt mit großen Übertragungsjobs zusammen

Spricht dagegen

Auslastung im Minutenmittel weit unter dem Limit, trotzdem Drops: „Microbursts am Switch“

Prüfmittel

Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

1. RFC 4594: Configuration Guidelines for DiffServ Service Classes IETF
   Interaktiven Echtzeit-Traffic wie Spiele und große Übertragungen wie Backups in getrennten Serviceklassen behandeln
2. RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
   Kommt mehr in ein Gerät hinein, als es ausgeben kann, bilden sich Warteschlangen, übermäßige Warteschlangen sind eine Hauptursache für Latenz
3. RFC 2863: The Interfaces Group MIB IETF
   ifHCInOctets, ifHCOutOctets: über das Interface empfangene bzw. gesendete Bytes (64 Bit), ifOutDiscards: Zahl der Pakete, die nicht gesendet werden konnten und verworfen wurden

Verwandte Ursachen

Gleiche Schicht: L5 Netzwerkgeräte im Rechenzentrum

• Volle Session-Tabelle der Firewall
• Umweg über DDoS-Schutz und False Positives
• Idle-Timeout des Load-Balancers
• Ablauf des Connection Trackings in Cloud-Security-Groups
• Verbindungs- und Portlimits des Cloud-NAT-Gateways
• Load-Balancer-Schieflast und fehlerhafte Health-Checks
• Microbursts am Switch
• Failover von Netzwerkgeräten
• Defekte Kabel und Portfehler
• MTU-Mismatch (nur große Pakete verschwinden)

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

• Renderlast durch große Spielermengen L1 Spielprozess auf dem Client
• Engpass bei der Paketverarbeitung im Main-Thread L1 Spielprozess auf dem Client
• V-Sync und Render-Warteschlange L1 Spielprozess auf dem Client
• Energiesparmodus und Thermal Throttling L2 Client-OS und Gerät
• Bandbreitenbelegung durch andere Apps auf demselben Gerät L2 Client-OS und Gerät
• Latenz von Display, Eingabegeräten und Frame Generation L2 Client-OS und Gerät
• Überlasteter WLAN-Kanal L3 Heimnetz
• Bufferbloat (Warteschlange im Router) L3 Heimnetz

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen