Sendet der Server in jedem Tick die Updates für Tausende Spieler im selben Augenblick, laufen kleine Switch-Puffer oder kurzfristige Limits in der Cloud in weniger als 1 ms über, und ein Teil der Pakete wird verworfen.
Warum Zu Beginn jedes Ticks gehen die Pakete für alle Spieler auf einmal raus → Folge Switch-Port-Puffer, in denen der Traffic mehrerer Server zusammenläuft (einige hundert KB bis einige MB pro Port), oder Limits der Cloud-Instanz laufen kurzzeitig über (durchschnittliche Auslastung niedrig) → Auf dem Bildschirm Teleportieren oder kurzer Freeze bei mehreren Spielern gleichzeitig, Durchschnittsmetriken zeigen die Ursache nicht
Die Sendungen eines Ticks über den Tick verteilen (Tausende Verbindungen, die zu Tickbeginn gleichzeitig senden, lassen sich mit Pacing pro Verbindung kaum entzerren), Tickstartzeiten der Server gegeneinander versetzen, Verbindungen mit großen Datenmengen per SO_MAX_PACING_RATE auf eine Höchstrate begrenzen.
Aufgaben Infrastrukturteam
Server/OS: Senderate des ganzen Servers begrenzen (Shaper im Server-OS, Linux tc), Bursts einzelner Verbindungen per Pacing glätten (Linux-fq-Queue, BBR). Netzwerk: Switches mit großen Puffern einsetzen, Zähler für verworfene ausgehende Pakete an den Switch-Ports in kurzen Abständen prüfen (in der durchschnittlichen Auslastung unsichtbar).
Größenordnungen
Ein 10-Gbps-Port überträgt in 1 ms etwa 1,25 MB. Treffen die Ticks mehrerer Server zusammen und laufen über einen Port, ist der Puffer im Nu voll.
Im Graphen
Steigt mit Spielerzahl und Last · Verworfene ausgehende Pakete pro Switch-Port, Retransmission-Rate
Wo nachsehen
Verworfene ausgehende Pakete (ifOutDiscards) am Switch-Port des Servers und am übergeordneten Port im Abstand weniger Sekunden erfassen, in der Cloud bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S prüfen. Retransmissions zum selben Zeitpunkt mit bcc tcpretrans sammeln und abgleichen
Spricht dafür
Auslastung im Minutenmittel niedrig, trotzdem steigen verworfene ausgehende Pakete oder allowance-Überschreitungen, und ihre Zahl wächst mit den gleichzeitigen Verbindungen und mit der Zahl der Spieler an einem Ort. Die Retransmissions häufen sich in keinem bestimmten IP-Bereich von Spielern (Provider, Region) und treten im selben Moment auf vielen Verbindungen dieses Servers auf
Spricht dagegen
Am selben Port steigen auch CRC- und Eingangsfehler: „Physische Fehler“. Steigen beim empfangenden Server die Drop-Zähler der NIC oder softnet dropped: „Verworfene Pakete auf dem empfangenden Server-Host“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Pacing wirkt für jede Verbindung einzeln. Senden Tausende Verbindungen zu Tickbeginn je ein, zwei Pakete, lässt sich dieser Andrang mit Pacing pro Verbindung kaum entzerren: Der Spielserver muss die Sendezeitpunkte selbst verteilen. Sendet dagegen eine einzelne Verbindung große Datenmengen, zerlegt die NIC einige Dutzend KB in Pakete und schickt sie direkt hintereinander hinaus (TSO). Solche Bursts verteilt Pacing gut.
Quellen
High-Resolution Measurement of Data Center MicroburstsMeta Über 70 % der Bursts an Rack-Switches im Rechenzentrum enden innerhalb einiger Dutzend µs, der Zusammenhang zwischen Auslastung im Minutenmittel und Drops ist schwach (IMC 2017)
tc-fq(8) — Linux manual pageiproute2 Die fq-Queue führt Pacing pro Socket (Verbindung) durch, SO_MAX_PACING_RATE legt die Höchstrate pro Verbindung fest
net/ipv4/tcp_bbr.cLinux kernel BBR legt pacing_rate anhand der geschätzten Engpass-Bandbreite fest und sendet danach
IP SysctlLinux kernel TCP passt die Größe der TSO-Frames an die Rate des Flows an (maximal 64 KB, tcp_min_tso_segs)
Monitor network performance for ENA settings on your EC2 instanceAWS bw_out_allowance_exceeded und pps_allowance_exceeded: Zahl der Pakete, die wegen Überschreitung des Bandbreiten- oder PPS-Limits der Instanz in die Warteschlange gestellt oder verworfen wurden
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: Zahl ausgehender Pakete, die verworfen wurden, obwohl kein Fehler vorlag, etwa um Pufferplatz freizumachen