Interaktive Fassung: https://jungrok5.github.io/mmo-lag-anatomy/de/ Ursachenseiten: https://jungrok5.github.io/mmo-lag-anatomy/de/c/[Ursachen-ID].html # Game-Lag-Whitepaper: Wissensdaten Automatisch erzeugt (2026-10-03, `node tools/export.cjs`). Nicht von Hand bearbeiten. Änderungen in src/js/ vornehmen und neu exportieren. 228 Ursachen, 135 Begriffe. Ursachen werden über ihre **ID** referenziert. Hängt man `#c-ID` an die Adresse der Website an, gelangt man zur Karte dieser Ursache. ## Zuständigkeitskürzel | Kürzel | Team | Zuständigkeit | Umfang | |---|---|---|---| | cli | Entwicklungsteam | Client-Entwicklung | Code des Spielclients: Frames, GC, Laden, Interpolation, Extrapolation und Vorhersage, Netzwerkverarbeitung im Client (einschließlich Senden von Heartbeats und automatischem Reconnect) | | srv | Entwicklungsteam | Server-Entwicklung | Code des Spielservers: Ticks, Threads, Locks, Synchronisationsdesign, Verbindungsannahme (accept-Schleife, listen-Parameter), Beantworten von Heartbeats und Aufräumen getrennter Verbindungen, Socket-Optionen, Design von Queries und Transaktionen | | net | Infrastrukturteam | Netzwerk-Infrastruktur | Leitungen und Netzwerkgeräte im Rechenzentrum (Switches, Router, Firewalls, Load-Balancer, DDoS-Schutz), Netzwerk-ACLs, VPC-Routing und Load-Balancer in der Cloud, Provider und Peering | | sys | Infrastrukturteam | Server-Infrastruktur | Serverhardware und Cloud-Instanzen (einschließlich Security Groups und Connection Tracking), OS- und Kernel-Einstellungen, NIC, Deployment- und Monitoring-Umgebung | | dba | Infrastrukturteam | DB-Infrastruktur | DB-Server und Storage, DB-Konfiguration, Replikation und Backups, Cache-Server | | ext | Extern | Extern | PC und Heimnetz der Spieler, Providerstrecken (außerhalb unserer Verträge), Cloud-Anbieter. Nicht direkt behebbar, daher Reaktion über Hinweise, Anfragen und Workarounds | „Hauptzuständig“ ist bei jeder Ursache die Stelle, die die Grundursache beseitigt. „Beteiligt“ sind Stellen, die ebenfalls konkret etwas zu tun haben. ## Symptome - **Ruckeln** (`stutter`, auch genannt: Stottern, Mikroruckler, gefühlte Framedrops): Bewegungen laufen nicht flüssig: Sie stocken immer wieder kurz und gehen dann weiter. Ist der Ping unauffällig, liegt es meist an den Frames des eigenen PCs (Client oder OS). Schwankt der Ping stark, ist wahrscheinlich Jitter im WLAN oder auf der Leitung die Ursache. Allerdings wird der Ping im Spiel meist innerhalb der Game-Loop gemessen, die einmal pro Frame läuft. Schlägt die Frametime aus, kann deshalb auch die Ping-Anzeige mit ausschlagen. - **Teleportieren** (`teleport`, auch genannt: Warpen, Teleport, Stocken und Springen): Ein Charakter springt ohne sichtbare Bewegung auf einen Schlag an eine weit entfernte Position. Meist heißt das, dass eine Zeit lang keine Pakete ankamen. Zu prüfen sind Paketverlust, kurze Leitungsunterbrechungen, ein Stillstand des Servers und fehlgeschlagene Extrapolation. Läuft bei allen anderen alles normal und springt nur einer, steht zuerst dessen Leitung unter Verdacht. - **Rubberbanding** (`rubber`, auch genannt: Zurückgeportet werden, Gummiband-Effekt, Positions-Rollback): Der eigene Charakter läuft vorwärts und wird an eine Stelle zurückgezogen, die er gerade passiert hat. Die eigene Anzeige (Vorhersage) und die Entscheidung des Servers passen nicht zusammen. Entweder kam die Eingabe nicht beim Server an (Paketverlust), die Bewegungsprüfung des Servers hat sie gekappt, oder Client und Server berechnen die Bewegung unterschiedlich. - **Zeitraffer** (`burst`, auch genannt: Schlag auf Schlag, Vorspulen, alles auf einmal): Das stehengebliebene Bild läuft wieder an, und aufgestaute Bewegungen, Treffer und Schaden rauschen im Schnelldurchlauf vorbei. Irgendwo haben sich Pakete angestaut und wurden auf einen Schlag freigegeben. Typisch sind das Warten auf eine TCP-Retransmission, ein Server, der Rückstand aufholt, und ein Client, der mit der Verarbeitung nicht hinterherkommt. - **Zeitlupe** (`slowmo`, auch genannt: Die Welt läuft langsamer, alles wirkt zäh): Alles bewegt sich langsamer. Skill-Casts und Monsterbewegungen wirken in die Länge gezogen. Je nach Serverdesign bleibt das Tempo auch gleich, und das Problem zeigt sich als Ruckeln oder Teleportieren. Der Server schafft seine Ticks nicht mehr rechtzeitig. Die Leitung ist in Ordnung, daher bleibt der außerhalb des Spiels gemessene Ping gleich. Der Ping im Spiel kann leicht steigen, wenn Wartezeit in der Serververarbeitung mit hineingerechnet wird. Zu prüfen sind sprunghaft steigende Spielerzahlen, Sichtbereichsberechnung, Broadcast und Speichermangel. - **Input-Lag** (`delay`, auch genannt: Verzögerte Reaktion, träge, schwammige Steuerung): Zwischen Tastendruck und Ergebnis vergeht spürbar Zeit. Das Bild selbst kann dabei flüssig sein. Die Umlaufzeit (Ping) ist lang, oder irgendwo staut sich eine Warteschlange. Zu prüfen sind Entfernung, die Warteschlange im Router, Nagle (eine TCP-Funktion, die kleine Pakete sammelt und gebündelt sendet) und Warteschlangen auf dem Server. Wirkt das Spiel trotz niedrigem Ping ständig träge, liegt es am eigenen PC (etwa V-Sync oder niedrige FPS) oder an einem Design, das bei jeder Aktion auf die Bestätigung des Servers wartet (Kapitel Synchronisationsmodelle). - **Freeze** (`freeze`, auch genannt: Einfrieren, Standbild, keine Reaktion): Alles im Bild bleibt kurz stehen (0,5 s bis einige Sekunden) und läuft dann weiter. Der ganze Server stand still (GC, Deadlock, synchroner Aufruf), die Leitung war kurz unterbrochen, oder der eigene PC hing. - **Verschluckte Aktion / Rollback** (`dropped`, auch genannt: Skill verschluckt, Item wieder weg, Handel fehlgeschlagen): Eine eindeutig ausgeführte Aktion gilt plötzlich als nie passiert, oder ihr Ergebnis wird deutlich später rückgängig gemacht. Die Anfrage ging verloren (Paketverlust, Warteschlangenüberlauf), der Server hat anders entschieden, als es auf dem eigenen Bildschirm aussah (unterschiedlicher Entscheidungszeitpunkt, Ablehnung nach clientseitigem Feedback), oder das Speichern schlug fehl (DB-Sperre oder DB-Störung, Serverabsturz). - **Verbindungsabbruch** (`disconnect`, auch genannt: Rausfliegen, Disconnect, „Die Verbindung zum Server wurde getrennt“): Mitten im Spiel bricht die Verbindung ab, und man landet im Login-Bildschirm oder im Reconnect-Fenster. Innerhalb des Timeouts kam kein einziges Paket an. Zu prüfen sind längere Leitungsunterbrechungen, Idle-Timeouts, Serverabstürze und Neustarts sowie ein Server oder eigener PC, der länger als das Timeout hing (langes Laden). Schließt sich das Spiel ohne jede Meldung, ist zuerst ein erzwungenes Beenden des Clients (Absturz, Speichermangel) zu prüfen und erst danach die Verbindung. - **Kein Login / Endlos-Laden** (`noconnect`, auch genannt: Login klappt nicht, Ladebildschirm endet nicht): Man kommt nicht ins Spiel oder bleibt im Lade- oder Eintrittsbildschirm hängen. Die Stellen, die neue Verbindungen annehmen (Verbindungswarteschlange des Servers, Firewall, Login-Server, DB), sind voll. Besonders häufig direkt nach einer Wartung. - **Unsichtbar / Geisterobjekte** (`invisible`, auch genannt: NPC fehlt, unsichtbarer Charakter, toter Mob steht noch da): NPCs, Monster oder Spieler, die da sein müssten, fehlen nur auf dem eigenen Bildschirm, oder längst verschwundene Objekte bleiben nur dort stehen. Mit Geschwindigkeit hat das meist wenig zu tun: Ein einzelnes Paket fehlt, oder das Zeichnen ist fehlgeschlagen. Zu prüfen sind unterschiedliche Kanäle oder Phasing, verlorene Spawn- und Despawn-Meldungen, Verwerfen während des Ladens und fehlgeschlagenes Laden von Assets. Der entscheidende Hinweis: Taucht das Objekt wieder auf, wenn man den Sichtbereich verlässt und zurückkehrt? ## Die vier Faktoren - **Latenz** (`lat`, Latency): Durch Entfernung, Warteschlangen und Verarbeitungszeit kommen alle Pakete gleichmäßig verspätet an. Umgang im Spiel: Vorhersage und clientseitiges Feedback zeigen die eigenen Aktionen sofort an, und für die Trefferabfrage spult der Server in die Vergangenheit zurück (Lag-Compensation). - **Jitter** (`jit`, Jitter): Im Mittel ist alles in Ordnung, doch manche Pakete kommen früh und andere spät. Verursacht wird das durch WLAN, überlastete Leitungen und eine ausgelastete CPU. Umgang im Spiel: Pakete werden kurz im Interpolationspuffer gesammelt und in gleichmäßigem Tempo zur Darstellung entnommen. Ist der Jitter größer als der Puffer, lässt er sich nicht mehr kaschieren. - **Paketverlust** (`loss`, Packet loss): Übergelaufene Warteschlangen, Funkstörungen und defekte Geräte verwerfen Pakete. Auch eine kurze Leitungsunterbrechung ist ein Verlust mehrerer Pakete in Folge. Umgang im Spiel: UDP-Spiele füllen Lücken per Interpolation und Extrapolation, und die eigenen Eingaben werden mehrfach gesendet, sodass der Verlust von ein, zwei Paketen nichts ausmacht. TCP gibt nachfolgende Pakete erst an das Spiel weiter, wenn das verlorene erneut empfangen wurde. - **Stillstand** (`stall`, Stall): Server-Ticks verspäten sich oder bleiben stehen (GC, Locks, synchrone Aufrufe, Überlast), oder die Frames auf dem eigenen PC stocken. Das passiert auch bei einwandfreier Leitung. Umgang im Spiel: Die aufgestaute Berechnung wird im Schnelldurchlauf nachgeholt, übersprungen oder läuft verlangsamt weiter. ## Ursachen ### L1 Spielprozess auf dem Client (16 Ursachen) #### cg-hitch · Frametime-Spikes · Frame hitch Die Berechnung eines einzelnen Frames dauert ein Vielfaches länger als sonst, und das Bild bleibt kurz stehen. - Warum → Folge → Auf dem Bildschirm: Massenhaft Skill-Effekte, Massen-Spawns und ein Neuaufbau der gesamten UI fallen in denselben Frame → Der Frame braucht 50–300 ms, das Budget liegt bei 16,7 ms → Bild stockt kurz, im nächsten Frame springen alle auf einmal weiter - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Nur ich / Wann: Bei großem Andrang, Bei bestimmten Aktionen, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Schwere Aufgaben auf mehrere Frames verteilen, Ausreißer-Frames mit dem Profiler finden, Obergrenze für die Zahl der Effekte. - Größenordnungen: Bei 60 FPS dauert ein Frame 16,7 ms. Schon ein einziger Frame über 50 ms wird oft als Ruckeln wahrgenommen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Frametime) - Wo nachsehen: Mit PresentMon während des Spielens die Frametime (FrameTime) und die Zeit aufzeichnen, die CPU und GPU für den Frame gebraucht haben (CPUBusy, GPUBusy). Auf Mobilgeräten die Metriken zu langsamen Sitzungen und langsamem Rendering in Android Vitals - Spricht dafür: Frametime liegt sonst bei etwa 16,7 ms und schießt genau dann über 50 ms hoch, wenn Skill-Animationen, Massen-Spawns oder ein Neuaufbau der gesamten UI laufen. Der Ping bleibt dabei unverändert - Spricht dagegen: Frametime gleichmäßig, aber nur andere Charaktere stocken: Netzwerkseite, etwa „Fehlender oder zu kurzer Interpolationspuffer“. Ausschläge in regelmäßigen Abständen: zuerst „Garbage Collection auf dem Client“ prüfen - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Slow rendering](https://developer.android.com/topic/performance/vitals/render) · Android (Google) · Für 60 FPS muss ein Frame in 16 ms gezeichnet sein. Dauert es länger, werden Frames übersprungen, sichtbar als Ruckeln (Jank) - [Slow Sessions (games only)](https://developer.android.com/topic/performance/issues/slow-session) · Android (Google) · Android Vitals wertet Spiel-Frames über 50 ms (20 FPS) bzw. über 34 ms (30 FPS) als langsame Frames - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · FrameTime (CPU-Zeit zwischen Frames), CPUBusy/GPUBusy (Zeit, die CPU bzw. GPU für diesen Frame gebraucht haben) #### cg-gc · Garbage Collection auf dem Client · Client GC (Unity C#, Unreal, Lua) Während nicht mehr benötigter Speicher (Garbage) freigegeben wird, steht das ganze Spiel still. Typisch ist Ruckeln in regelmäßigen Abständen. - Warum → Folge → Auf dem Bildschirm: In jedem Frame entstehen temporäre Strings, Arrays und Listen, die gleich wieder verworfen werden → Hat sich genug Garbage angesammelt, hält die GC den Main-Thread an und räumt auf → Regelmäßiges Ruckeln alle paar Sekunden bis alle paar Dutzend Sekunden - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Nur ich / Wann: In festen Abständen, Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Allokationen reduzieren (String-Verkettung, LINQ und Lambda-Captures vermeiden), Object-Pools nutzen, inkrementelle GC eingeschaltet lassen (seit Unity 2020 Standard), die GC vorab dann auslösen, wenn ein Stillstand nicht stört, etwa auf Ladebildschirmen. - Größenordnungen: Meist einige ms bis 100 ms pro Lauf, auf schwachen Smartphones oder bei Spielen mit hohem Speicherbedarf mehr (im Experiment etwa 150–170 ms). Die GC von Unity durchsucht bei jedem Lauf den gesamten Heap. Je mehr Speicher das Spiel belegt, desto länger dauert sie. - Im Graphen: Spitzen in festen Abständen (Frametime, Zeitpunkte der GC-Läufe) - Wo nachsehen: In einem Development-Build die Marker GC.Collect und GC.Alloc im Unity Profiler ansehen. In Unreal stat GC und stat Hitches (protokolliert Frames, die länger als der mit t.HitchFrameTimeThreshold festgelegte Wert dauern) - Spricht dafür: Jeder Ausreißer-Frame enthält einen GC.Collect-Abschnitt von etwa der Länge des Ausschlags, die Abstände sind regelmäßig und liegen bei einigen bis einigen Dutzend Sekunden. An belebten Orten steigt GC.Alloc pro Frame - Spricht dagegen: Kein GC-Abschnitt im Ausreißer-Frame: „Synchrones Laden und Shader-Kompilierung im Main-Thread“ oder „Renderlast durch große Spielermengen“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Häufig bei Clients mit C#, etwa in Unity. Hauptverursacher ist Code, der Kampflog-Texte, Schadenszahlen und UI-Texte in jedem Frame neu erzeugt. Ruckelt es nur an belebten Orten, gibt es Code, dessen Garbage mit der Spielerzahl wächst. Die inkrementelle GC sammelt pro Frame nur ein Stück (Unity-Standard 3 ms). Entsteht Garbage schneller, als gesammelt wird, steht das Spiel am Ende trotzdem auf einen Schlag still. Auch die Unreal Engine hat eine eigene GC, die nicht mehr genutzte Spielobjekte aufräumt. Abhängig von Engine-Version und Einstellungen läuft sie in der Standardkonfiguration etwa einmal pro Minute und kann so ein Stocken im Minutentakt verursachen. Clients, deren Spielregeln in einer Skriptsprache wie Lua geschrieben sind, haben zusätzlich die eigene GC dieser Skriptsprache. - Quellen: - [Garbage collection modes](https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html) · Unity · Inkrementelle GC ist Standard und sammelt verteilt über mehrere Frames. Ohne sie steht der Main-Thread still, während der gesamte Heap durchsucht wird, im Extremfall mehrere hundert ms - [Scripting.GarbageCollector.CollectIncremental](https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.CollectIncremental.html) · Unity · Standardziel für die Zeit, die die inkrementelle GC pro Durchgang nutzt (Zeitscheibe): 3 ms (incrementalTimeSliceNanoseconds) - [Garbage Collection Settings in the Unreal Engine Project Settings](https://dev.epicgames.com/documentation/en-us/unreal-engine/garbage-collection-settings-in-the-unreal-engine-project-settings) · Epic Games · Einstellung, nach der die Unreal-GC in festen Abständen läuft (Time Between Purging Pending Kill Objects, in Sekunden). Den Standardwert nennt dieses Dokument nicht - [Profiler markers reference](https://docs.unity3d.com/Manual/profiler-markers.html) · Unity · GC.Collect: Abschnitt, in dem der Programmcode während der Garbage Collection angehalten ist (unter 1 ms bis mehrere hundert ms), GC.Alloc: Allokation im Managed Heap - [Stat Commands in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/stat-commands-in-unreal-engine) · Epic Games · stat GC (Statistik zur Garbage Collection), stat Hitches (protokolliert Frames über t.HitchFrameTimeThreshold) #### cg-sync-load · Synchrones Laden und Shader-Kompilierung im Main-Thread · Synchronous asset load, shader compile Bevor ein neues Gebiet, ein neues Monster oder ein neuer Effekt zum ersten Mal gezeichnet wird, liest das Spiel Dateien und erzeugt Shader. Währenddessen steht es still. - Warum → Folge → Auf dem Bildschirm: Betreten eines neuen Gebiets, erstmals auftauchende Skills, Ausrüstung oder Monster → Main-Thread wartet auf das Lesen von Dateien und die Shader-Kompilierung → Nur beim ersten Mal 0,1–1 s Stillstand, ab dem zweiten Mal in Ordnung - Symptome: Freeze, Ruckeln / Faktoren: Stillstand - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel, Bei bestimmten Aktionen - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Asynchrones Laden, Vorladen (Prewarming), Shader auf dem Ladebildschirm oder beim ersten Start vorkompilieren, Ladebildschirme gezielt nutzen. - Größenordnungen: Die Kompilierung eines Shaders dauert einige Dutzend ms, im ungünstigen Fall 100 ms und mehr. Texturen laden je nach Datenträger in einigen Dutzend bis einigen hundert ms. - Im Graphen: Ansturm direkt nach Login oder Wartung (Anzahl der Frametime-Spikes (direkt nach Patch oder Treiber-Update)) - Wo nachsehen: Mit PresentMon dieselbe Route zweimal aufzeichnen und den ersten mit dem zweiten Durchlauf vergleichen. In Development-Builds unter Unreal r.PSOPrecache.Validation aktivieren und stat PSOPrecache sowie „PSO PRECACHING MISS“ im Log prüfen, unter Unity in der Timeline des Profilers die Lade- und Shader-Abschnitte der Ausreißer-Frames ansehen - Spricht dafür: Ausschläge von 0,1–1 s nur beim ersten Besuch eines Orts oder beim ersten Einsatz eines Skills, beim zweiten Mal verschwunden. Meldungen häufen sich direkt nach einem Patch oder Grafiktreiber-Update und nehmen dann ab - Spricht dagegen: Ausschlag jedes Mal am selben Ort: kein Shader-Cache-Problem. Wiederholt sich bei jeder Bewegung, aber nur auf PCs mit langsamem Datenträger: „Langsamer Datenträger bremst Asset-Streaming“. Dedizierter GPU-Speicher voll: „Zu wenig Grafikspeicher (VRAM)“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Auf dem PC speichert der Grafiktreiber einmal erzeugte Shader im Shader-Cache und verwendet sie wieder. Direkt nach einem Treiber-Update oder einem Spiel-Patch wird dieser Cache ungültig. Dann ruckelt es eine Weile auch bei Spielern, bei denen vorher alles flüssig lief. Typische Meldung: „Seit dem Patch hakt es an jedem Ort, an den ich zum ersten Mal komme.“ - Quellen: - [Shader loading](https://docs.unity3d.com/Manual/shader-loading.html) · Unity · Bei der ersten Nutzung einer Shader-Variante erzeugt der Grafiktreiber die GPU-Fassung, was spürbar stocken kann. Einmal erzeugte Varianten werden gecacht und stocken nicht erneut - [Optimizing Rendering With PSO Caches in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/optimizing-rendering-with-pso-caches-in-unreal-engine) · Epic Games · Pipeline-States (PSOs) erst im Moment des Bedarfs zu erzeugen kann 100 ms und länger dauern, deshalb vorab erzeugen - [Direct3D 12 Return Codes](https://learn.microsoft.com/en-us/windows/win32/direct3d12/d3d12-graphics-reference-returnvalues) · Microsoft · D3D12_ERROR_DRIVER_VERSION_MISMATCH: Ein PSO-Cache aus einer anderen Treiberversion lässt sich nicht wiederverwenden (nach einem Treiber-Update wird neu kompiliert) - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Aufzeichnung der Zeit pro Frame über FrameTime (CPU-Zeit zwischen Frames) - [PSO Precaching for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/pso-precaching-for-unreal-engine) · Epic Games · Mit aktiviertem r.PSOPrecache.Validation zeigt stat PSOPrecache Statistiken zu verpassten PSOs, und das Log meldet „PSO PRECACHING MISS“. Dauert die PSO-Erzeugung zur Laufzeit länger als standardmäßig 20 ms, zählt sie als Hitch #### cg-asset-stream · Langsamer Datenträger bremst Asset-Streaming · Slow storage stalls asset streaming Auf langsamen Datenträgern wie HDDs kommt das Einlesen von Texturen und Modellen in einer Open World der Bewegung nicht hinterher. Objekte erscheinen spät, oder das Spiel ruckelt, während es auf Lesevorgänge wartet. - Warum → Folge → Auf dem Bildschirm: Schnelle Fortbewegung per Reittier oder Teleport oder Betreten eines belebten Orts, viele neue Texturen und Modelle auf einmal nötig → Langsamer Datenträger wie eine HDD liest nicht schnell genug, Leseanfragen stauen sich, bei manchen Ladevorgängen wartet der Main-Thread bis zum Ende → Texturen bleiben eine Weile unscharf, Gebäude und Charaktere erscheinen spät, Ruckeln oder Freeze, während auf Lesevorgänge gewartet wird - Symptome: Unsichtbar / Geisterobjekte, Ruckeln, Freeze / Faktoren: Stillstand - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel, Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Asynchrones Streaming, bei dem der Main-Thread nicht auf Lesevorgänge wartet, vorausschauendes Laden anhand von Bewegungsrichtung und Tempo, zuerst niedrige Auflösung (Mipmaps) und einfache Modelle zeigen und später austauschen, bei Streaming-Rückstand während schneller Fortbewegung das Tempo kurz begrenzen oder einen Ladebildschirm zeigen, in Mindest- und empfohlenen Systemanforderungen angeben, ob eine SSD nötig ist. - Aufgaben Extern: Spielern empfehlen, das Spiel auf einer SSD zu installieren, und sie prüfen lassen, ob auf demselben Laufwerk Downloads oder Virenscans laufen. - Größenordnungen: Laut Microsoft lesen ältere Festplatten einige Dutzend MB pro Sekunde, NVMe-SSDs mehrere GB pro Sekunde. Spiele der vorigen Generation nutzten fürs Streaming etwa 50 MB pro Sekunde. Läuft ein Spiel, das auf SSD-Geschwindigkeit ausgelegt ist und weit mehr liest, auf einer HDD, hält das Lesen mit der Bewegung oft nicht Schritt. - Im Graphen: Nur einzelne Ausreißer (Anzahl der Frametime-Spikes (nach Datenträgertyp), Disk-Leselatenz) - Wo nachsehen: Beim schnellen Fortbewegen in der Windows-Leistungsüberwachung PhysicalDisk\Avg. Disk sec/Read (durchschnittliche Dauer eines Lesevorgangs) und Current Disk Queue Length zusammen mit der Frametime aus PresentMon aufzeichnen. In Development-Builds unter Unreal stat Streaming und stat AsyncLoad, unter Unity die Profiler-Warnung AssetBundle.asset/allAssets prüfen (Ergebnis vor Ende des Ladevorgangs angefordert, Main-Thread wartet) - Spricht dafür: Beim schnellen Fortbewegen schießen Disk-Leselatenz und Warteschlange hoch, gleichzeitig schlägt die Frametime aus oder Texturen und Objekte erscheinen spät. Dieselbe Szene läuft auf einer SSD ohne das Problem - Spricht dagegen: Datenträger untätig, Texturen trotzdem unscharf: „Zu wenig Grafikspeicher (VRAM)“. Ab dem zweiten Besuch am selben Ort in Ordnung: „Synchrones Laden und Shader-Kompilierung im Main-Thread“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Hakt es nur beim ersten Mal und danach nicht mehr, passt eher „Synchrones Laden und Shader-Kompilierung im Main-Thread“. Wiederholt es sich bei jeder Bewegung und nur auf PCs mit langsamem Datenträger, ist es diese Ursache. Auch „Zu wenig Grafikspeicher (VRAM)“ führt zu unscharfen Texturen, weil Texturen aus dem Grafikspeicher entfernt und wieder geladen werden. Deshalb sind die Wartezeit beim Lesen vom Datenträger und die Auslastung des Grafikspeichers gemeinsam zu prüfen. Auch der Echtzeitschutz eines Virenscanners kann sich bei jedem Öffnen einer Spieldatei einschalten und das Lesen weiter verzögern. - Quellen: - [DirectStorage is coming to PC](https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/) · Microsoft · Ältere Festplatten lesen einige Dutzend MB pro Sekunde, NVMe-SSDs mehrere GB pro Sekunde, das Asset-Streaming-Budget von Spielen der vorigen Generation lag bei etwa 50 MB pro Sekunde, Open-World-Spiele lesen ferne Landschaft während der Bewegung in Echtzeit ein und verwerfen sie wieder - [Texture and mesh loading](https://docs.unity3d.com/Manual/LoadingTextureandMeshData.html) · Unity · Synchroner Upload liest und überträgt im Main-Thread innerhalb eines Frames und verursacht ein sichtbares Stocken, asynchroner Upload streamt über mehrere Frames - [Texture Streaming Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/texture-streaming-overview-for-unreal-engine) · Epic Games · Der Streamer erhöht und senkt die Texturauflösung (Mip) passend zum Blickpunkt, rechnet größtenteils in asynchronen Worker-Threads und lädt zuerst die sichtbaren Mips - [Profiler markers reference](https://docs.unity3d.com/Manual/profiler-markers.html) · Unity · Warnung AssetBundle.asset/allAssets: Ergebnis vor Ende des Ladevorgangs angefordert, der Main-Thread hält an und wartet - [Stat Commands in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/stat-commands-in-unreal-engine) · Epic Games · stat Streaming (Speicher und Anzahl gestreamter Texturen), stat AsyncLoad (Statistik zum asynchronen Laden) - [Windows Performance Monitor Disk Counters Explained](https://learn.microsoft.com/en-us/archive/blogs/askcore/windows-performance-monitor-disk-counters-explained) · Microsoft · Avg. Disk sec/Read ist die durchschnittliche Dauer eines Lesevorgangs (I/O-Latenz), Current Disk Queue Length die Länge der Disk-Warteschlange im Moment der Messung - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Aufzeichnung der Zeit pro Frame über FrameTime (CPU-Zeit zwischen Frames) - [About regular quick and full scans with Microsoft Defender Antivirus](https://learn.microsoft.com/en-us/defender-endpoint/schedule-antivirus-scans) · Microsoft · Der Echtzeitschutz prüft Dateien bei jedem Öffnen und Schließen #### cg-crowd · Renderlast durch große Spielermengen · Render/animation cost of crowds Sind wie bei Belagerungen oder Weltbossen Hunderte Spieler auf einem Bildschirm, ist schon das Zeichnen selbst nicht mehr zu bewältigen. - Warum → Folge → Auf dem Bildschirm: Hunderte Spieler und Effekte gleichzeitig auf einem Bildschirm → Kosten für Animationen, Schatten, Namensschilder und Effekte steigen mit der Spielerzahl → FPS fallen (60 → 15), jede Bewegung ruckelt, auch Eingaben kommen verzögert an - Symptome: Ruckeln, Input-Lag / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Nur ich / Wann: Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Vereinfachung nach Entfernung (LOD), Obergrenze für angezeigte Spieler, Option für vereinfachte Effekte, Animationen seltener aktualisieren. - Größenordnungen: Selbst 0,02–0,1 ms pro Charakter ergeben bei 300 Charakteren 6–30 ms. Bei 60 FPS beträgt das Frame-Budget 16,7 ms; das allein verbraucht also mehr als 1/3 davon und sprengt es im ungünstigen Fall. - Im Graphen: Steigt mit Spielerzahl und Last (Frametime, Anzahl der Charaktere im Bild) - Wo nachsehen: Frametime sowie CPUBusy und GPUBusy aus PresentMon vor und nach Belagerungen oder Weltbossen vergleichen. In Development-Builds stat Unit in Unreal (Zeiten von Game-Thread, Render-Thread und GPU) - Spricht dafür: Mit der Zahl der Spieler im Bild steigt auch die Frametime. Eine Begrenzung der angezeigten Spieler oder vereinfachte Effekte bringen sofort Besserung - Spricht dagegen: Ausschläge unabhängig von der Spielerzahl: „Frametime-Spikes“ oder „Garbage Collection auf dem Client“. FPS in Ordnung, aber nur die Bewegungen anderer hinken hinterher: „Engpass bei der Paketverarbeitung im Main-Thread“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Introduction to level of detail](https://docs.unity3d.com/Manual/LevelOfDetail.html) · Unity · Ohne LOD werden auch klein dargestellte Objekte in voller Komplexität gezeichnet, LOD senkt die Zeichenlast - [Animation Budget Allocator in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/animation-budget-allocator-in-unreal-engine) · Epic Games · Animations-Updates (Ticks) von Skeletal Meshes dynamisch reduzieren und so die Animationszeit im Budget halten - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · FrameTime, CPUBusy und GPUBusy zeigen, ob CPU oder GPU den Frame bremst - [Stat Commands in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/stat-commands-in-unreal-engine) · Epic Games · stat Unit: gesamte Frametime sowie Zeiten von Game-Thread, Render-Thread und GPU #### cg-net-mainthread · Engpass bei der Paketverarbeitung im Main-Thread · Network processing on the main thread Verarbeitet der Client empfangene Pakete pro Frame nur bis zu einer festen Menge, schieben sich angestaute Pakete immer weiter in die nächsten Frames. - Warum → Folge → Auf dem Bildschirm: An belebten Orten treffen Tausende Updates pro Sekunde ein → Main-Thread stößt an die Verarbeitungsgrenze pro Frame und kommt mit dem Lesen nicht nach → Bewegungen anderer Spieler werden immer später und gebündelt übernommen - Symptome: Zeitraffer, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Bestimmter Ort oder Kanal, Nur ich / Wann: Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Empfang und Parsing in einen eigenen Thread verlegen, ältere Positions-Updates desselben Objekts zusammenfassen und nur das neueste anwenden. Server: an belebten Orten Updates entfernter Charaktere seltener senden und so die Datenmenge reduzieren. - Größenordnungen: Stauen sich unverarbeitete Pakete, reichen wenige Sekunden, um eine ganze Sekunde in Rückstand zu geraten. - Im Graphen: Steigt mit Spielerzahl und Last (Anzahl unverarbeiteter empfangener Pakete, Verzögerung zwischen Empfang und Anwendung) - Wo nachsehen: Im Client protokollieren, wie viele Pakete pro Frame unverarbeitet liegen bleiben und wie lange es vom Eintreffen eines Pakets bis zur Anwendung im Spiel dauert, und beides der Spielerzahl in der Umgebung gegenüberstellen - Spricht dafür: An belebten Orten wachsen die Zahl liegengebliebener Pakete und die Anwendungsverzögerung stetig, Ping und Sendeintervall des Servers sind zur selben Zeit normal - Spricht dagegen: Keine Anwendungsverzögerung, aber die Pakete selbst kommen spät an: Netzwerkstrecke. Frametime steigt stark: „Renderlast durch große Spielermengen“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Bei knapper Bandbreite priorisiert die Engine Actors nach Entfernung zum Betrachter und Zeit seit der letzten Replikation und repliziert nicht jeden Actor bei jedem Durchlauf - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · Spiele mit vielen Spielern und Replikationsobjekten (etwa MMORPGs) müssen nach Position gruppieren und nur die nötigen Objekte senden, um einen CPU-Engpass auf dem Server zu vermeiden #### cg-no-buffer · Fehlender oder zu kurzer Interpolationspuffer · Missing/short interpolation buffer Zeichnet der Client Serverpakete sofort nach dem Empfang, wird der Jitter (Schwankung der Ankunftsabstände) direkt auf dem Bildschirm sichtbar. - Warum → Folge → Auf dem Bildschirm: Empfangene Position wird sofort gezeichnet, oder der Puffer ist kürzer als der Jitter → Stillstand, solange ein Paket zu spät ist, Sprung, wenn Pakete gebündelt nachkommen → Andere Charaktere bewegen sich stockend, Ruck für Ruck - Symptome: Ruckeln / Faktoren: Jitter - Wer: Nur ich / Wann: Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Interpolationspuffer einführen, Pufferlänge automatisch an die Verbindungsqualität anpassen. Server: Lag-Compensation (Zurückspulen bei der Trefferabfrage) einsetzen, damit Treffer auch dann stimmen, wenn auf den um die Pufferlänge älteren Zustand gezielt wird. - Größenordnungen: Üblich ist ein Puffer von etwa dem Doppelten des Sendeintervalls des Servers (bei 20 Paketen pro Sekunde 100 ms). - Im Graphen: Von Anfang an dauerhaft hoch (Paket-Ankunftsabstände, Anzahl leergelaufener Interpolationspuffer) - Wo nachsehen: Im Client die Verteilung der Ankunftsabstände von Serverpaketen aufzeichnen sowie die Zahl der Frames, in denen mangels nächstem Snapshot die Bewegung stehen blieb oder auf Extrapolation umgeschaltet wurde - Spricht dafür: Die Schwankung der Ankunftsabstände übersteigt häufig die Länge des Interpolationspuffers, der Puffer läuft dann jedes Mal leer und andere Charaktere stocken. Ein längerer Puffer verringert das - Spricht dagegen: Stockt es trotz ausreichendem Puffer: prüfen, ob schon das Sendeintervall des Servers unregelmäßig ist (Tick-Verzögerung) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Ein längerer Puffer glättet die Bewegung, dafür sieht man den Gegner entsprechend weiter in der Vergangenheit. Deshalb kommt für die Trefferabfrage Lag-Compensation dazu: Der Server spult auf die Vergangenheit zurück, die dieser Spieler gesehen hat, und prüft den Treffer dort. - Quellen: - [Interpolation and extrapolation (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/interpolation.html) · Unity · Puffer-Interpolation zeichnet absichtlich verzögert, um auf späte Pakete warten zu können. Ein größerer Puffer ist genauer, erhöht aber entsprechend die Latenz - [Struct ClientTickRate (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/api/Unity.NetCode.ClientTickRate.html) · Unity · Standardwert des Interpolationspuffers InterpolationTimeNetTicks = 2 (zwei Server-Sendungen) - [Physics (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/physics.html) · Unity · Lag-Compensation: Der Server sucht die Kollisionswelt, die der Client in diesem Tick gesehen hat, und entscheidet dort über Treffer #### cg-extrap · Übermäßige Extrapolation (Dead Reckoning) · Over-extrapolation / dead reckoning Solange keine Pakete kommen, zeigt der Client das Objekt mit der letzten Geschwindigkeit weiter in Bewegung. Merkt er den Fehler, setzt er es zurück. - Warum → Folge → Auf dem Bildschirm: Paketempfang bricht ab, Objekt bewegt sich mit letzter Richtung und Geschwindigkeit weiter → In Wirklichkeit hat der Gegner angehalten oder die Richtung gewechselt → Gegnerischer Charakter läuft ein ganzes Stück weiter und springt dann plötzlich an die echte Position oder läuft durch Wände. Schwanken die Paketabstände, eilt er immer wieder voraus und wird zurückgezogen, die Bewegung wirkt zittrig - Symptome: Teleportieren, Ruckeln / Faktoren: Paketverlust, Jitter - Wer: Nur ich / Wann: Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Obergrenze für die Extrapolationsdauer (z. B. 200–250 ms), bei Fehlern sanft zur richtigen Position überblenden. - Größenordnungen: Bei 6 m/s ergibt schon ein Fehler von 300 ms eine Abweichung von 1,8 m. - Im Graphen: Vereinzelte Spitzen ohne Muster (Extrapolationsdauer, Korrekturdistanz der Position) - Wo nachsehen: Aufzeichnen, wie lange andere Charaktere per Extrapolation gezeichnet wurden und um welche Distanz die Position nach Eintreffen eines neuen Pakets korrigiert wurde - Spricht dafür: In jeder Phase ohne Pakete wächst die Extrapolationsdauer ohne Obergrenze, danach steigt die Korrekturdistanz auf mehrere Meter - Spricht dagegen: Extrapolation endet früh, trotzdem Teleportieren: Paketverlust oder Latenz selbst sind zu hoch, Leitung und Route prüfen - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Interpolation and extrapolation (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/interpolation.html) · Unity · Extrapolation mit gleicher Richtung und Geschwindigkeit liegt oft daneben, wenn der nächste Snapshot ausbleibt, deshalb gibt es eine Obergrenze (Unity-Standard 20 Ticks, bei 60 Hz etwa 1/3 s) - [Peeking into VALORANT's Netcode](https://technology.riotgames.com/news/peeking-valorants-netcode) · Riot Games · Werden späte oder fehlende Daten durch Schätzung ergänzt und liegt die Schätzung falsch, weicht der Zustand vom Server ab, und der Charakter springt oder wird rutschend korrigiert #### cg-predict · Abweichende clientseitige Vorhersage · Prediction mismatch / reconciliation Der eigene Client zeigt die Bewegung schon vorab. Berechnet der Server sie anders, wird der eigene Charakter zurückgezogen. - Warum → Folge → Auf dem Bildschirm: Client bewegt sich vor der Bestätigung durch den Server (Vorhersage) → Server berechnet Kollision, Bewegungstempo oder Buffs anders oder hat den Befehl nicht erhalten → Bei Eintreffen der Bestätigung wird der eigene Charakter zurückgezogen - Symptome: Rubberbanding / Faktoren: Paketverlust, Latenz - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: denselben Bewegungscode wie der Server verwenden, Eingaben redundant senden, Korrekturen sanft ausführen. Server: denselben Bewegungscode wie der Client verwenden, doppelt eingetroffene Eingaben anhand der Eingabenummer herausfiltern und nur einmal verarbeiten. - Größenordnungen: Die Distanz ergibt sich aus „Dauer der Abweichung × Bewegungstempo“. Schon wenige verlorene Befehle ergeben 1–3 m. - Im Graphen: Vereinzelte Spitzen ohne Muster (Anzahl der Serverkorrekturen (fehlgeschlagene Vorhersagen)) - Wo nachsehen: Anzahl und Distanz der vom Server gesendeten Positionskorrekturen aufzeichnen. In Unreal die Korrekturen per ClientAdjustPosition zählen, in Unity Netcode for Entities die Zahl der Rollbacks mit Neuberechnung nach fehlgeschlagener Vorhersage - Spricht dafür: Korrekturen häufen sich zu den Zeitpunkten der Rubberbanding-Meldungen, bei bestimmten Buffs, Geländestellen oder Bewegungsskills ist die Korrekturdistanz wiederholt groß - Spricht dagegen: Korrekturen häufen sich nur bei hohem Paketverlust: Verlust von Eingabepaketen (Leitung). Keine Korrekturen, nur andere Charaktere werden sichtbar zurückgezogen: „Übermäßige Extrapolation (Dead Reckoning)“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Introduction to prediction (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/intro-to-prediction.html) · Unity · Client und Server sagen mit demselben Simulationscode voraus. Weicht der Serverzustand ab (fehlgeschlagene Vorhersage), wird zurückgesetzt und neu berechnet, die Korrektur ist sichtbar - [Use the command stream to handle user inputs (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/command-stream.html) · Unity · Gegen Paketverlust werden mit der neuesten Eingabe auch die Eingaben der vorherigen Ticks redundant mitgeschickt - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Der Client bewegt sich zuerst, der Server spielt dieselbe Bewegung nach. Weicht die Position ab, korrigiert ClientAdjustPosition sie, und die gespeicherten Bewegungen werden erneut angewendet #### cg-fixed-step · Aufholspirale bei festem Zeitschritt · Fixed-timestep catch-up / spiral of death Nach einem einzelnen Stillstand rechnet das Spiel die aufgelaufenen Schritte im Block nach und gerät genau dadurch erneut in Rückstand. - Warum → Folge → Auf dem Bildschirm: Spielsimulation läuft in festen Abständen und bleibt einmal stehen → Aufgelaufene Schritte werden in einem einzigen Frame nachgerechnet → Lange Frames folgen in Serie aufeinander und schlagen aus, oder die Obergrenze greift und die Welt läuft langsamer - Symptome: Ruckeln, Zeitraffer, Zeitlupe / Faktoren: Stillstand - Wer: Nur ich / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Obergrenze für das Aufholen pro Frame, Restzeit per Interpolation ausgleichen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Frametime, Anzahl fester Zeitschritte pro Frame) - Wo nachsehen: Im Profiler eines Development-Builds zusammen mit der Frametime prüfen, wie oft der feste Zeitschritt pro Frame lief (in Unity Anzahl der Marker der FixedUpdate-Phase wie FixedBehaviourUpdate) - Spricht dafür: Auf einen langen Frame folgen in Serie lange Frames mit mehreren Schritten. Ist die Obergrenze erreicht (in Unity Maximum Allowed Timestep), läuft die Spielzeit langsamer als die reale Zeit - Spricht dagegen: Bleibt es bei einem einzelnen langen Frame: „Frametime-Spikes“ oder „Garbage Collection auf dem Client“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Die Physikberechnung von Unity (FixedUpdate) ist das typische Beispiel für einen festen Zeitschritt (Standard 0,02 s, 50-mal pro Sekunde). Die Obergrenze fürs Aufholen ist Maximum Allowed Timestep in den Time-Einstellungen (maximale Zeit, die in einem Frame aufgeholt wird, Standard etwa 0,33 s). Dauert ein Frame länger, wird die überschüssige Zeit verworfen, und die Spielzeit läuft entsprechend hinter der realen Zeit her. - Quellen: - [Set fixed timestep to optimize physics simulation frequency](https://docs.unity3d.com/Manual/physics-optimization-cpu-frequency.html) · Unity · Standardwert Fixed Timestep 0,02 s (50-mal pro Sekunde). Bei langen Frames laufen mehrere Physikschritte in einem Frame, die Last steigt - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Standardwert Maximum Allowed Timestep 1/3 s (0,3333333). Selbst wenn das Spiel 1 s hängt, vergehen nur 0,333 s Spielzeit. Die Obergrenze verhindert den Teufelskreis, in dem die Aufholschritte alles weiter verlangsamen - [Profiler markers reference](https://docs.unity3d.com/Manual/profiler-markers.html) · Unity · FixedBehaviourUpdate: Ausführungsabschnitt von MonoBehaviour.FixedUpdate, die Physik-Marker werden in der FixedUpdate-Phase aufgerufen #### cg-clock · Fehler bei der Uhrensynchronisation · Clock sync error Liegt die vom Client geschätzte Serverzeit daneben, stimmen Interpolationszeitpunkt und Cooldown-Prüfung nicht mehr. - Warum → Folge → Auf dem Bildschirm: Serverzeit wird nur einmal beim Login abgeglichen und bleibt so, auch wenn sich der Ping ändert → Interpolationszeitpunkt und Ende des Cooldowns weichen vom Server ab → Gegner stockt gelegentlich, Skill wird abgelehnt, obwohl der Cooldown abgelaufen ist - Symptome: Ruckeln, Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur ich / Wann: Je länger es läuft, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Zeit regelmäßig synchronisieren (Umlaufzeit messen, dann korrigieren), allmählich angleichen, ohne abrupt umzustellen, verstrichene Zeit mit einer Monotonic Clock messen (die PC-Uhrzeit ist dafür ungeeignet). - Im Graphen: Langsamer Anstieg (Fehler der geschätzten Serverzeit) - Wo nachsehen: Regelmäßig die Differenz zwischen der vom Client geschätzten Serverzeit und der vom Server im Paket mitgeschickten Serverzeit (Tick-Nummer) aufzeichnen - Spricht dafür: Der Fehler wächst mit der Zeit seit dem Login oder springt auf einen Schlag, wenn die PC-Uhr gestellt wird, und um diese Zeit häufen sich Meldungen über abgelehnte Skills und Stocken - Spricht dagegen: Fehler bleibt klein, Skills werden trotzdem abgelehnt: Ursache eher bei der Entscheidung des Servers oder bei der Latenz - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Misst man die verstrichene Zeit an Datum und Uhrzeit des PCs (Wall Clock), springt die Spielzeit, sobald Windows die Uhr mit der Internetzeit abgleicht oder der Nutzer die Uhr umstellt. Verstrichene Zeit gehört deshalb auf eine Monotonic Clock, die nie zurückläuft (etwa Stopwatch). - Quellen: - [RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification](https://www.rfc-editor.org/rfc/rfc5905) · IETF · Verfahren, das aus den vier Zeitstempeln von Anfrage und Antwort Umlaufverzögerung und Uhrabweichung berechnet - [Acquiring high-resolution time stamps](https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps) · Microsoft · QueryPerformanceCounter (von Stopwatch genutzt) ist eine Uhr für verstrichene Zeit ohne Synchronisation mit externer Zeit. Systemzeit nur verwenden, wenn UTC-Zeit benötigt wird - [Time synchronization (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/time-synchronization.html) · Unity · Serverzeit aus der Umlaufzeit schätzen und angleichen, indem der Gang der Uhr leicht beschleunigt oder gebremst wird, ohne die Zeit sprunghaft zu ändern #### cg-float-time · Präzisionsverlust bei float-Zeitwerten · Float time precision loss on long sessions Hält das Spiel die Spielzeit in einem ungenauen Gleitkommaformat (float), sinkt die Zeitauflösung (kleinster unterscheidbarer Zeitabstand), je länger es läuft. Bewegungen und Effekte zittern. - Warum → Folge → Auf dem Bildschirm: Seit Spielstart vergangene Zeit wird als float aufsummiert oder direkt an Shader übergeben → Je länger das Spiel läuft, desto größer wird der kleinste Abstand, den float darstellen kann → Nur bei Clients, die seit Tagen laufen, zittern Charaktere, Animationen und fließende Effekte, nach einem Neustart ist alles normal - Symptome: Ruckeln / Faktoren: Jitter - Wer: Nur ich / Wann: Je länger es läuft - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Verstrichene Zeit als double (64 Bit) oder Ganzzahl speichern, an Shader übergebene Zeit in festen Abständen zurücksetzen, automatisierte Langzeittests über mehrere Tage. - Größenordnungen: Ein 32-Bit-float hat gut 7 signifikante Stellen. Nach einem Tag Laufzeit (etwa 86.400 s) liegt die Zeitauflösung bei etwa 8 ms, also etwa einem halben Frame bei 60 FPS (16,7 ms), nach einer Woche bei etwa 60 ms und damit über einem ganzen Frame. - Im Graphen: Langsamer Anstieg (Zitter-Meldungen nach Laufzeit des Clients) - Wo nachsehen: Bei Zitter-Meldungen die Laufzeit des Clients mit abfragen und vor und nach einem Neustart vergleichen. Entwicklungsseitig testen, indem der Startzeitwert des Spiels auf einen Wert mehrere Tage in der Vergangenheit gesetzt wird - Spricht dafür: Zittern nur bei Clients, die seit Tagen laufen, verschwindet nach einem Neustart und wird mit längerer Laufzeit stärker - Spricht dagegen: Zittern direkt nach dem Start: „Fehlender oder zu kurzer Interpolationspuffer“ oder „Timer-Auflösung“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Besonders häufig bei Mobile-MMOs, in denen Spieler Auto-Farming tagelang laufen lassen. Auch Time.time in Unity ist ein float, deshalb bietet Unity zusätzlich Time.timeAsDouble als double an und empfiehlt diese Variante. - Quellen: - [Time.timeAsDouble](https://docs.unity3d.com/ScriptReference/Time-timeAsDouble.html) · Unity · double-Variante von Time.time, bei langer Laufzeit genauer als float, wird für die meisten Fälle empfohlen - [Floating-point numeric types (C# reference)](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/floating-point-numeric-types) · Microsoft · float-Genauigkeit etwa 6–9 Stellen, double etwa 15–17 Stellen #### cg-vsync · V-Sync und Render-Warteschlange · V-Sync, render queue Die GPU legt fertige Frames in eine Warteschlange und gibt sie im Takt des Monitors aus. Solange sie dort warten, kommt die Eingabe verzögert an. - Warum → Folge → Auf dem Bildschirm: Grafiktreiber legt vorab 1–3 Frames in die Warteschlange → Bis eine Eingabe auf dem Bildschirm erscheint, dauert es entsprechend länger → Ping niedrig, Steuerung trotzdem schwer und träge - Symptome: Input-Lag, Ruckeln / Faktoren: Latenz - Wer: Nur ich / Wann: Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Low-Latency-Modus unterstützen, Frame-Warteschlange verkürzen, Option für ein Framelimit knapp unter der Bildwiederholrate anbieten, auf Smartphones Frame-Pacing aktivieren. - Aufgaben Extern: Spielern empfehlen, mit einem Monitor mit variabler Bildwiederholrate ein Framelimit knapp unter der Bildwiederholrate zu setzen und den Low-Latency-Modus im Grafiktreiber einzuschalten. - Größenordnungen: Bei 60 Hz kostet jeder Frame 16,7 ms. Ist die CPU schneller als die GPU oder der Bildwiederholtakt und läuft die Warteschlange mit drei Frames voll (Standard in DirectX 11), kommen 50 ms dazu. Bei V-Sync mit Doppelpufferung wartet ein Frame, der 17 ms gebraucht hat, bis zur nächsten Bildaktualisierung (33,3 ms), und so lange ist der vorige Frame ein zweites Mal zu sehen. - Im Graphen: Von Anfang an dauerhaft hoch (Latenz von der Eingabe bis zur Anzeige) - Wo nachsehen: Die PresentMon-Werte MsClickToPhotonLatency und MsAllInputToPhotonLatency (von Maus- oder Tastatureingabe bis zur Ausgabe an den Bildschirm) sowie DisplayLatency bei wechselnden Einstellungen für V-Sync, Low-Latency-Modus und Framelimit vergleichen. MsPCLatency (vom Eingang der Eingabe im PC bis zur Ausgabe an den Bildschirm) wird nur aufgezeichnet, wenn das Spiel PC-Latency-Events ausgibt - Spricht dafür: Mit V-Sync oder ohne Framelimit steigt diese Latenz um ein bis zwei Frames (einige Dutzend ms), mit Low-Latency-Modus oder einem Framelimit knapp unter der Bildwiederholrate sinkt sie. Der Ping bleibt unverändert - Spricht dagegen: Latenz im PC niedrig, Steuerung trotzdem träge: „Latenz von Display, Eingabegeräten und Frame Generation“. Ping hoch: Netzwerkseite - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: V-Sync (vertikale Synchronisation) gibt neue Frames nur in dem Moment aus, in dem der Monitor das Bild wechselt. Tearing verschwindet, aber das Warten auf diesen Moment verzögert die Eingabe. Fallen die FPS unter 60, springt die Ausgabe zwischen 60 und 30 hin und her, und das Bild ruckelt. Monitore mit variabler Bildwiederholrate wechseln das Bild dann, wenn ein Frame fertig ist, und verkürzen so diese Wartezeit. Auf Smartphones passiert dasselbe. Gibt ein 30-FPS-Spiel seine Frames auf einem 60-Hz-Display nicht gleichmäßig aus, liegt der Durchschnitt zwar bei 30 FPS, die einzelnen Frames bleiben aber unterschiedlich lange stehen, etwa 49, 16 und 33 ms, und das Bild ruckelt (Beispiel aus der Android-Entwicklerdokumentation). Abhilfe schaffen die Frame-Pacing-Bibliothek von Android (gleichmäßige Abstände bei der Frame-Ausgabe) oder entsprechende Optionen der Engine. - Quellen: - [IDXGIDevice1::SetMaximumFrameLatency](https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgidevice1-setmaximumframelatency) · Microsoft · Standardwert für die Zahl der Frames, die der Treiber in die Warteschlange legen darf: 3 (1–16) - [Reduce latency with DXGI 1.3 swap chains](https://learn.microsoft.com/en-us/windows/uwp/gaming/reduce-latency-with-dxgi-1-3-swap-chains) · Microsoft · Present blockiert, bis in der Warteschlange Platz ist, sodass zwischen Zeichnen und Anzeige fast ein weiterer Frame Wartezeit entsteht. Eine Waitable Swap Chain verringert das - [Frame Pacing library](https://developer.android.com/games/sdk/frame-pacing) · Android (Google) · Liegt auf einem 60-Hz-Display kein neuer Frame vor, wird der vorige erneut angezeigt. Beispiel eines 30-FPS-Spiels mit unregelmäßigen Frametimes wie 49, 16 und 33 ms - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsPCLatency (vom Eingang der Eingabe im PC bis zur Ausgabe an den Bildschirm), MsClickToPhotonLatency (Mausklick bis Bildschirm), MsAllInputToPhotonLatency (Tastatur- oder Mauseingabe bis Bildschirm), DisplayLatency (Übergabe des Frames bis zur Ausgabe an den Monitor) - [PresentMon Console Application (README-ConsoleApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-ConsoleApplication.md) · Intel · MsPCLatency wird nur aufgezeichnet, wenn die App PC-Latency-Events ausgibt (--track_pc_latency), MsAllInputToPhotonLatency bezieht sich auf Tastatur- und Mauseingaben #### cg-leak · Speicherleck im Client · Client memory leak Je länger das Spiel läuft, desto mehr Speicher belegt es. Es wird zunehmend langsamer und am Ende zwangsweise beendet. - Warum → Folge → Auf dem Bildschirm: Texturen, UI und Effekte werden beim Gebietswechsel nicht freigegeben → GC läuft häufiger, dem OS geht der Arbeitsspeicher aus, es lagert in den Swap aus → Nach einigen Stunden Spielzeit zunehmendes Ruckeln, dann erzwungenes Beenden (für den Spieler wie ein Verbindungsabbruch) - Symptome: Ruckeln, Verbindungsabbruch / Faktoren: Stillstand - Wer: Nur ich / Wann: Je länger es läuft - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Speicherverbrauch bei Gebietswechseln messen, nicht freigegebene Texturen, UI-Elemente und Effekte finden und beheben, automatisierte Langzeittests (Soak-Tests). - Im Graphen: Langsamer Anstieg (Speicherverbrauch des Spielprozesses) - Wo nachsehen: In der Leistungsüberwachung Process(Spiel)\Private Bytes über mehrere Stunden aufzeichnen. Auf Mobilgeräten den Beendigungsgrund in ApplicationExitInfo unter Android (REASON_LOW_MEMORY) und Jetsam-Berichte unter iOS - Spricht dafür: Bei jedem Gebietswechsel steigt der Speicherverbrauch und sinkt nicht wieder, mit längerer Laufzeit nehmen Ruckeln und erzwungenes Beenden zu - Spricht dagegen: Speicherverbrauch konstant, mit längerer Laufzeit aber Zittern: „Präzisionsverlust bei float-Zeitwerten“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Smartphones halten meist durch, indem sie Speicher komprimieren. Reicht der Speicher trotzdem nicht, beendet das OS das Spiel sofort, und es „fliegt raus“. Geräte mit wenig RAM trifft es zuerst. - Quellen: - [Memory allocation among processes](https://developer.android.com/topic/performance/memory-management) · Android (Google) · Android hält durch, indem es Speicher in zRAM komprimiert. Reicht das nicht, beendet der Low Memory Killer Prozesse. Wird die App im Vordergrund beendet, wirkt das wie ein Absturz - [Identifying high-memory use with jetsam event reports](https://developer.apple.com/documentation/xcode/identifying-high-memory-use-with-jetsam-event-reports) · Apple · iOS beendet Apps zwangsweise (Jetsam), wenn der Speicherdruck anhält. Überschreitet eine App ihr Speicherlimit, kommt sie für die Beendigung in Frage - [Find user-mode memory leaks with Performance Monitor (PerfMon)](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-performance-monitor-to-find-a-user-mode-memory-leak) · Microsoft · Process > Private Bytes (vom Prozess belegter privater Speicher) und Virtual Bytes über lange Zeit aufzeichnen. Steigen sie nur an, liegt ein Leck vor - [ApplicationExitInfo](https://developer.android.com/reference/android/app/ApplicationExitInfo) · Android (Google) · REASON_LOW_MEMORY: Der Low Memory Killer des Systems hat den App-Prozess beendet (Geräte ohne Unterstützung melden REASON_SIGNALED bzw. SIGKILL) #### cg-crash · Client-Absturz · Client crash Ein nicht abgefangener Fehler beendet das Spiel. Für den Spieler sieht das wie ein Verbindungsabbruch aus, der Server läuft aber normal. - Warum → Folge → Auf dem Bildschirm: Nullreferenz, Speichermangel, Fehler im Grafiktreiber → Spielprozess wird zwangsweise beendet → Meldungen wie „Bin rausgeflogen“, andere sind zur selben Zeit nicht betroffen - Symptome: Verbindungsabbruch / Faktoren: Stillstand - Wer: Nur ich / Wann: Bei bestimmten Aktionen, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Absturzberichte sammeln, Statistik nach Gerät und Treiber führen, häufigste Fehler zuerst beheben. - Aufgaben Extern: Häufen sich Abstürze bei einer bestimmten Grafiktreiberversion, Spielern ein Treiber-Update empfehlen. - Im Graphen: Nur einzelne Ausreißer (Anzahl der Abstürze (nach Gerät, Grafiktreiber, Build)) - Wo nachsehen: Absturzberichte und die Absturzrate in Android Vitals nach Gerät, Treiber und Build auswerten. Auf dem PC des Spielers im Anwendungsprotokoll der Ereignisanzeige Ereignis-ID 1000 (Name des fehlerhaften Moduls) und Einträge „Display driver stopped responding and has recovered“ - Spricht dafür: Zum Zeitpunkt der gemeldeten Abbrüche gibt es Absturzeinträge, andere Spieler auf demselben Server sind zur selben Zeit nicht betroffen. Häufung bei bestimmten Geräten, Treiberversionen oder Modulen - Spricht dagegen: Keine Absturzeinträge, nur die Verbindung ist weg: „Ablauf des NAT-Mappings“ oder Leitung - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Crashes](https://developer.android.com/topic/performance/vitals/crash) · Android (Google) · Ein Absturz ist das unerwartete Beenden einer App durch eine nicht behandelte Exception oder ein Signal (etwa SIGSEGV), erfasst über Android Vitals in der Play Console - [WDDM Support for Timeout Detection and Recovery (TDR)](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery) · Microsoft · Schafft die GPU eine Aufgabe nicht innerhalb von standardmäßig 2 s, setzt Windows Grafiktreiber und GPU zurück - [The application or service crashing behavior troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-application-service-crashing-behavior) · Microsoft · Ereignis-ID 1000 im Anwendungsprotokoll ist der eigentliche Absturzeintrag und enthält die fehlerhafte Anwendung und den Namen des fehlerhaften Moduls (Faulting module name) #### cg-anticheat · Prüfungen des Sicherheitsmoduls (Anti-Cheat) · Anti-cheat scan and heartbeat Ein Sicherheitsmodul, das zum Schutz vor Cheats mit dem Spiel läuft, prüft in regelmäßigen Abständen. Ist die Prüfung aufwendig oder kommt der Heartbeat (regelmäßiges Lebenszeichen) zum Sicherheitsserver zu spät, ruckelt das Spiel, oder es kommt zum Verbindungsabbruch. - Warum → Folge → Auf dem Bildschirm: Sicherheitsmodul prüft regelmäßig Spielspeicher, laufende Programme und Treiber → Während der Prüfung steht der Game-Thread still, oder der Heartbeat geht nicht rechtzeitig raus → Stocken in festen Abständen, schlimmstenfalls Verbindungsabbruch mit Sicherheitsfehlermeldung - Symptome: Ruckeln, Freeze, Verbindungsabbruch / Faktoren: Stillstand - Wer: Nur ich / Wann: In festen Abständen, Direkt nach Login oder Wartung, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: aufwendige Prüfungen außerhalb des Game-Threads in kleinen Portionen ausführen, Statistiken zu Ruckeln und Rauswürfen nach Version des Sicherheitsmoduls vergleichen (bei Häufung direkt nach einem Update an den Hersteller des Moduls weitergeben). Server: ein, zwei verspätete Heartbeats tolerieren. - Größenordnungen: Leichte Prüfungen dauern meist unter 1 ms. Aufwendige Prüfungen im Game-Thread belegen je nach Implementierung aber pro Durchlauf einige Dutzend bis einige hundert ms. - Im Graphen: Spitzen in festen Abständen (Frametime, Anzahl der Anti-Cheat-Kicks) - Wo nachsehen: In der Frametime aus PresentMon die Abstände der Ausschläge messen und die vom Server empfangenen Anti-Cheat-Kick-Gründe (bei EOS etwa AuthenticationFailed / Authentication Timed Out aus ClientActionReason) nach Version des Sicherheitsmoduls und nach Hardware auswerten - Spricht dafür: Unabhängig von der Spielsituation wiederholen sich kurze Stillstände in festen Abständen, direkt nach einem Update des Sicherheitsmoduls nehmen bei bestimmter Hardware Ruckeln und Kicks wegen Authentifizierungs-Timeout zu - Spricht dagegen: Gleiche Abstände auf jeder Hardware, unabhängig von der Version des Sicherheitsmoduls: „Garbage Collection auf dem Client“ oder „CPU-Belegung durch Hintergrundprozesse“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Sicherheitsmodule sitzen als Treiber tief im OS und geraten daher mitunter mit Virenscannern, Overlays oder den Sicherheitsmodulen anderer Spiele in Konflikt. Häufen sich direkt nach einem Update des Sicherheitsmoduls Meldungen über Ruckeln und Rauswürfe nur bei bestimmter Hardware, steht das Modul als Erstes unter Verdacht. - Quellen: - [Using the Anti-Cheat Interfaces](https://dev.epicgames.com/docs/epic-online-services/trust-and-safety/anti-cheat-interfaces/using-anti-cheat) · Epic Games · Erhält der Server die Anti-Cheat-Nachricht des Clients nicht innerhalb der festgelegten Zeit (RegisterTimeout), wirft er ihn wegen Authentifizierungs-Timeout raus (häufige Ursache: Client hängt beim Laden). Liegt das Problem an einem kürzlichen Modul-Update, auf das vorige Modul zurückgehen - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Aufzeichnung der Zeit pro Frame über FrameTime (CPU-Zeit zwischen Frames) ### L2 Client-OS und Gerät (15 Ursachen) #### co-background · CPU-Belegung durch Hintergrundprozesse · Background CPU contention Belegen Virenscans, Windows Update, Streaming-Software oder Videos im Browser die Kerne, bekommt der Game-Thread keine CPU-Zeit und muss warten. - Warum → Folge → Auf dem Bildschirm: Andere Programme belegen CPU-Kerne über längere Zeit → Game-Thread wartet auf CPU-Zuteilung → Frames kommen zu spät, auch empfangene Pakete werden verspätet verarbeitet - Symptome: Ruckeln, Zeitraffer / Faktoren: Stillstand - Wer: Nur ich / Wann: Gelegentlich, zufällig, In festen Abständen - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Priorität des Game-Threads anpassen, in den Logs, die beim Ruckeln entstehen, die CPU-Auslastung des gesamten PCs mitschreiben, um andere Programme als Ursache zu erkennen. - Aufgaben Extern: Spielern empfehlen, den Windows-Spielmodus einzuschalten und unnötige Programme während des Spielens zu beenden (Virenscans, Windows Update, Streaming-Software, Videos im Browser). - Größenordnungen: Windows vergibt Kerne meist in Abschnitten von einigen bis einigen Dutzend ms. Schon ein einziges Zurückstellen beim Scheduling kostet einen ganzen Frame. - Im Graphen: Vereinzelte Spitzen ohne Muster (CPU-Auslastung des gesamten PCs, Frametime) - Wo nachsehen: Die CPU-Spalte im Reiter „Prozesse“ des Task-Managers und Processor Information(_Total)\% Processor Time aus der Leistungsüberwachung zusammen mit der Frametime aus PresentMon aufzeichnen. Bei Verdacht auf den Virenscanner mit New-MpPerformanceRecording aufzeichnen und mit Get-MpPerformanceReport die Dateien und Prozesse mit langer Scanzeit ansehen - Spricht dafür: Zum Zeitpunkt des Ruckelns schießt die CPU-Nutzung eines anderen Programms hoch (Virenscan, Update, Streaming-Software), oder Dateien aus dem Spielordner stehen oben in der Liste der Scanzeiten. Wird das Programm beendet oder eine Ausnahme eingetragen, verschwindet es - Spricht dagegen: CPU-Auslastung niedrig, trotzdem stockt das ganze Bild und der Ton knistert: „NIC-Energiesparmodus und Treiberprobleme“ (DPC-Latenz) - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Windows gibt dem Programm im Vordergrundfenster etwas mehr Priorität. Gibt es aber mehr Arbeit als Kerne, wartet auch das Spiel. Virenscanner stören häufiger über den „Echtzeitschutz“ als über CPU-Last. Der Echtzeitschutz prüft jede Datei, die das Spiel öffnet, und verlängert so den Stillstand beim Laden von Assets. - Quellen: - [Multitasking](https://learn.microsoft.com/en-us/windows/win32/procthread/multitasking) · Microsoft · Windows gibt jedem Thread eine Zeitscheibe und wechselt nach deren Ablauf zum nächsten Thread, eine Zeitscheibe beträgt etwa 20 ms (je nach OS und CPU) - [Priority Boosts](https://learn.microsoft.com/en-us/windows/win32/procthread/priority-boosts) · Microsoft · Der Prozess im Vordergrundfenster erhält eine Priorität, die mindestens so hoch ist wie die von Hintergrundprozessen - [About regular quick and full scans with Microsoft Defender Antivirus](https://learn.microsoft.com/en-us/defender-endpoint/schedule-antivirus-scans) · Microsoft · Der Echtzeitschutz prüft bei jedem Öffnen und Schließen einer Datei und bei jedem Öffnen eines Ordners - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Processor Information: Leistungsindikator % Processor Time - [Performance analyzer for Microsoft Defender Antivirus](https://learn.microsoft.com/en-us/defender-endpoint/tune-performance-defender-antivirus) · Microsoft · Mit New-MpPerformanceRecording aufzeichnen und mit Get-MpPerformanceReport die Dateien, Pfade und Prozesse ansehen, die die Scanzeit am stärksten beeinflusst haben - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Aufzeichnung der Zeit pro Frame über FrameTime (CPU-Zeit zwischen Frames) #### co-power · Energiesparmodus und Thermal Throttling · Power saving, thermal throttling Akkubetrieb am Notebook, der Energiesparmodus des Smartphones oder Hitze im Gerät senken die Taktraten von CPU und GPU. Typisch für Hitze: Anfangs läuft alles, nach einer Weile wird es langsamer. - Warum → Folge → Auf dem Bildschirm: Akku- oder Energiesparmodus, oder das Gerät wird heiß → CPU- und GPU-Takt sinken je nach Gerät um 30–50 % → FPS sinken, und es ruckelt: im Energiesparmodus sofort, bei Hitze nach einigen bis etwa 20 Minuten Spielzeit - Symptome: Ruckeln, Input-Lag / Faktoren: Stillstand - Wer: Nur ich / Wann: Je länger es läuft, Immer - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Grafikoptionen automatisch anpassen, Hitze per Framelimit begrenzen, vom OS gemeldete Thermalstufen auswerten (thermalState unter iOS, Thermal-API unter Android) und Optionen vorab senken, auf Notebooks mit zwei Grafikchips die ausführbare Datei so kennzeichnen, dass die dedizierte Grafik genutzt wird (NvOptimusEnablement und AmdPowerXpressRequestHighPerformance exportieren). - Aufgaben Extern: Spielern empfehlen, den Energiesparmodus auszuschalten und Notebooks am Netzteil zu betreiben, bei Meldungen wie „Gutes Notebook, aber niedrige FPS“ prüfen, auf welchem Grafikchip das Spiel läuft, und Spieler bitten, das Spiel in den Windows-Grafikeinstellungen der Hochleistungs-GPU zuzuweisen. - Im Graphen: Langsamer Anstieg (FPS, CPU- und GPU-Takt) - Wo nachsehen: CPUFrequency, GPUFrequency, CPUTemperature und GPUTemperature aus PresentMon zusammen mit der Frametime 20–30 Minuten lang aufzeichnen und in der Spalte „GPU-Engine“ im Reiter „Prozesse“ des Task-Managers prüfen, auf welchem Grafikchip das Spiel läuft. Auf Mobilgeräten die Thermal-API von Android (getThermalHeadroom, Thermal-Status) und thermalState unter iOS zusammen mit den FPS aufzeichnen - Spricht dafür: FPS sinken ab dem Moment, in dem nach steigender Temperatur der Takt fällt, oder der Takt ist nur im Akku- oder Energiesparmodus niedrig. Oder das Spiel läuft auf der integrierten Grafik - Spricht dagegen: Takt und Temperatur unverändert, FPS sinken trotzdem: „CPU-Belegung durch Hintergrundprozesse“ oder „Speicherleck im Client“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Notebooks mit zwei Grafikchips lassen Spiele zum Stromsparen mitunter auf der langsamen integrierten Grafik laufen. Bei Meldungen wie „Gutes Notebook, aber niedrige FPS“ ist zuerst zu prüfen, auf welchem Grafikchip das Spiel läuft. - Quellen: - [Thermal API](https://developer.android.com/games/optimize/adpf/thermal) · Android (Google) · Geräte halten hohe Leistung nur begrenzte Zeit und werden danach wegen Hitze gedrosselt. Empfohlen wird, den Thermal-Status zu beobachten und die Last vorab zu senken - [thermalState](https://developer.apple.com/documentation/foundation/processinfo/thermalstate-swift.property) · Apple · Aktuelle Thermalstufe, die iOS meldet. Steigt die Stufe, soll die App ihren Ressourcenverbrauch senken - [Selecting the Best Graphics Device to Run a 3D Intensive Application](https://gpuopen.com/learn/amdpowerxpressrequesthighperformance/) · AMD · Läuft ein Spiel auf einem Notebook mit zwei Grafikchips auf der integrierten Grafik, werden aus 60 FPS mitunter 30 FPS. Mit dem Export von AmdPowerXpressRequestHighPerformance wird die dedizierte Grafik gewählt - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · CPUFrequency und GPUFrequency (Takt), CPUTemperature und GPUTemperature (Temperatur) pro Frame aufzeichnen - [GPUs in the task manager](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) · Microsoft · Der Task-Manager hat Spalten, die die GPU-Auslastung pro Prozess zeigen und angeben, zu welcher GPU und Engine der Wert gehört #### co-timer · Timer-Auflösung · Timer resolution (Windows 15.6ms) Der Standard-Timer von Windows arbeitet in Schritten von 15,6 ms. Ein „nur 1 ms warten“ dauert deshalb tatsächlich bis zum nächsten Timer-Takt, im ungünstigsten Fall 15,6 ms. - Warum → Folge → Auf dem Bildschirm: Framelimit und Paketversand über Sleep (kurzes Warten) umgesetzt → OS weckt nur in Schritten von 15,6 ms auf → Frame-Abstände und Sendeabstände der Eingaben schwanken - Symptome: Ruckeln / Faktoren: Jitter - Wer: Nur ich / Wann: Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Hochauflösende Timer verwenden, Pacing über Events oder V-Sync (ohne Sleep-Wartezeiten). - Größenordnungen: In Schritten von 15,6 ms lässt sich kein Abstand von 16,7 ms treffen. Die Frame-Abstände springen zwischen 15,6 ms und 31,2 ms hin und her. - Im Graphen: Von Anfang an dauerhaft hoch (Verteilung der Frame-Abstände) - Wo nachsehen: Die Verteilung von MsBetweenPresents (Frame-Abstand) in PresentMon und den Abschnitt „Platform Timer Resolution“ im Bericht von powercfg /energy (Prozesse, die die Timer-Auflösung geändert haben) ansehen - Spricht dafür: Frame-Abstände häufen sich bei Vielfachen von 15,6 ms wie 15,6 ms und 31,2 ms, und das Spiel fordert keine höhere Timer-Auflösung an - Spricht dagegen: Abstände gleichmäßig gestreut: eher „CPU-Belegung durch Hintergrundprozesse“ oder Frame-Last als der Timer - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: In älteren Windows-Versionen wirkte es sich auf alle Programme aus, wenn ein Programm den Timer auf 1 ms stellte. Daher stammt auch der Spruch „Mit offenem Browser läuft das Spiel flüssiger“. Seit Windows 10, Version 2004, gilt die Einstellung nur für das anfragende Programm. Windows 11 kann Anfragen von Fenstern ignorieren, die minimiert oder vollständig verdeckt sind und keinen Ton ausgeben. - Quellen: - [_WDF_TIMER_CONFIG (wdftimer.h)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdftimer/ns-wdftimer-_wdf_timer_config) · Microsoft · Genauigkeit gewöhnlicher Timer entspricht dem Takt der Systemuhr, standardmäßig 15,6 ms, hochauflösende Timer 1 ms - [timeBeginPeriod function (timeapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod) · Microsoft · Bis Windows 10 2004 globale Einstellung, danach nur für den anfragenden Prozess, Windows 11 garantiert Prozessen mit verdeckten oder minimierten Fenstern keine hohe Auflösung - [CreateWaitableTimerExW function (synchapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createwaitabletimerexw) · Microsoft · Flag für hochauflösende Waitable Timer: CREATE_WAITABLE_TIMER_HIGH_RESOLUTION - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsBetweenPresents: Zeit zwischen diesem und dem vorigen Present()-Aufruf (ms) - [Results for the Idle Energy Efficiency Assessment](https://learn.microsoft.com/en-us/windows-hardware/test/assessments/results-for-the-idle-energy-efficiency-assessment) · Microsoft · Standardauflösung des Systemtimers 15,6 ms, Prozesse, die die Timer-Auflösung geändert haben, stehen im Abschnitt „Platform Timer Resolution“ des Energieberichts - [Powercfg command-line options](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/powercfg-command-line-options) · Microsoft · powercfg /energy: analysiert das System und erstellt einen Energiebericht (HTML) #### co-mobile-bg · Wechsel der mobilen App in den Hintergrund · App suspended in background Wird die App kurz minimiert, um eine Benachrichtigung zu lesen, pausiert das OS sie nach einigen Sekunden (Suspend). In dieser Zeit trennt der Server die Verbindung des Spielers. - Warum → Folge → Auf dem Bildschirm: Spiel wird für eine Nachricht oder einen Anruf in den Hintergrund geschickt → Engine hält das Spielgeschehen an, kurz darauf pausiert das OS auch App und Netzwerk → Bei der Rückkehr ist die Verbindung schon abgebrochen, Reconnect - Symptome: Verbindungsabbruch / Faktoren: Stillstand, Paketverlust - Wer: Nur ich / Wann: Nach Inaktivität, Bei bestimmten Aktionen - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: bei der Rückkehr sofort per Session-Token automatisch neu verbinden (Session ohne erneuten Login fortsetzen), ohne auf die abgebrochene Verbindung zu warten, den aktuellen Zustand in einem Schritt abholen und abgleichen. Server: bei ausbleibendem Heartbeat die Verbindung aufräumen, die Charakter-Session aber für eine kurze Karenzzeit halten (nicht sofort entfernen), bei Reconnect innerhalb dieser Zeit per Session-Token fortsetzen. - Größenordnungen: Spiel-Engines halten meist sofort beim Minimieren an. iOS pausiert die App nach einigen Sekunden, mit zusätzlich angeforderter Zeit meist innerhalb einiger Dutzend Sekunden. Ab Android 14 werden Apps, die nicht mehr im Vordergrund sind, nach etwa 10 s eingefroren. - Im Graphen: Verbindungen brechen gleichzeitig ab (Anzahl der Abbrüche (Heartbeat-Timeout), Einträge zum Pausieren der App) - Wo nachsehen: Zeitpunkte von App-Pause und Rückkehr im Client-Log (in Unity OnApplicationPause) über die Session-ID mit Grund und Zeitpunkt der Trennung auf dem Server abgleichen. Unter Android auch die in ApplicationExitInfo hinterlegten Beendigungsgründe des Prozesses (etwa REASON_LOW_MEMORY) prüfen - Spricht dafür: Kurz vor der Trennung wegen Heartbeat-Timeout auf dem Server ging der Client in die Pause, direkt nach der Rückkehr verbindet er sich neu - Spricht dagegen: Verbindung brach ab, während die App im Vordergrund war: „Ablauf des NAT-Mappings“, „Geteilte Provider-IP (CGNAT)“, „Wechsel WLAN ↔ LTE/5G“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Bei Speichermangel beenden Smartphones minimierte Spiele mitunter ganz. Deshalb startet das Spiel nach einem Abstecher in die Kamera oder in eine Zahlungs- oder Authentifizierungs-App von vorn. Je schwächer das Gerät, desto häufiger passiert das. - Quellen: - [Extending your app’s background execution time](https://developer.apple.com/documentation/uikit/extending-your-app-s-background-execution-time) · Apple · Beim Wechsel in den Hintergrund bleiben applicationDidEnterBackground 5 s, danach wird pausiert. Mehr Zeit lässt sich mit beginBackgroundTask anfordern (Restzeit in backgroundTimeRemaining) - [Cached apps freezer](https://source.android.com/docs/core/perf/cached-apps-freezer) · Android (Google) · Ab Android 14 werden App-Prozesse im Cached-Zustand nach 10 s eingefroren, dann stehen alle Threads still - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Standardwert false, die App hält im Hintergrund an. Android hält im Hintergrund unabhängig von der Einstellung an, iOS ignoriert die Einstellung - [MonoBehaviour.OnApplicationPause(bool)](https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnApplicationPause.html) · Unity · Wird die App pausiert oder fortgesetzt, erhalten alle MonoBehaviours OnApplicationPause(true/false) - [ApplicationExitInfo](https://developer.android.com/reference/android/app/ApplicationExitInfo) · Android (Google) · REASON_LOW_MEMORY: Der Low Memory Killer des Systems hat den App-Prozess beendet (Geräte ohne Unterstützung melden REASON_SIGNALED bzw. SIGKILL) #### co-netswitch · Wechsel WLAN ↔ LTE/5G · Network switch changes IP Verlässt man das Haus, bricht das WLAN ab, und das Gerät wechselt zu LTE oder 5G. Dabei ändert sich die eigene IP-Adresse, und die bestehende Verbindung wird ungültig. - Warum → Folge → Auf dem Bildschirm: WLAN-Signal wird schwach, Wechsel ins Mobilfunknetz → Eigene IP-Adresse ändert sich, über die mit der alten Adresse aufgebaute Verbindung geht nichts mehr → Kurzer Stillstand, dann Verbindungsabbruch oder Reconnect - Symptome: Freeze, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Server: den Spieler per Session-Token auch bei geänderter Adresse als denselben weiterführen und die Verbindung der alten Adresse sofort aufräumen, Protokolle prüfen, die Adresswechsel überstehen (etwa Connection Migration bei QUIC). Client: bei erkanntem Netzwechsel sofort per Session-Token neu verbinden, ohne auf das Heartbeat-Timeout zu warten. - Aufgaben Infrastrukturteam: Bei QUIC Connection Migration den Load-Balancer den Server anhand der Connection-ID wählen lassen (wählt er nach Adresse und Port, landen Pakete mit geänderter Adresse auf einem anderen Server). - Im Graphen: Verbindungen brechen gleichzeitig ab (Abbrüche und Reconnects, geänderte IP beim Reconnect) - Wo nachsehen: Im Verbindungslog des Servers Reconnects mit demselben Session-Token, aber anderer IP suchen und mit den Zeitpunkten des Callbacks für Änderungen des Standardnetzwerks im Client (registerDefaultNetworkCallback) abgleichen - Spricht dafür: Direkt nach dem Abbruch wechselt die IP beim Reconnect vom WLAN-Bereich (Festnetzanschluss zu Hause) in den Bereich des Mobilfunkanbieters oder umgekehrt, kurz davor kommt der Callback zum Netzwechsel - Spricht dagegen: IP unverändert, trotzdem abgebrochen: „Handover zwischen Funkzellen (unterwegs)“ oder „Schwaches Mobilfunksignal und Funklöcher“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Read network state](https://developer.android.com/training/basics/network-ops/reading-network-state) · Android (Google) · Ändert sich das Standardnetzwerk, laufen neue Verbindungen über das neue Netz, und Verbindungen im alten Netz werden am Ende zwangsweise getrennt. Erkennung des Wechsels über registerDefaultNetworkCallback - [RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https://www.rfc-editor.org/rfc/rfc9000) · IETF · Connection-IDs halten die Verbindung auch bei geänderter IP-Adresse oder geändertem Port (Kapitel 9), Load-Balancer, die nur nach Adresse und Port verteilen, können Pakete mit geänderter Adresse an einen anderen Server schicken (Abschnitt 5.2.3) - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Eine TCP-Verbindung wird durch das Socket-Paar (Adresse und Port) beider Enden identifiziert #### co-security · Paketprüfung durch Sicherheitssoftware · Antivirus / firewall inspection Prüfen Virenscanner oder Firewall jedes Paket, steigt die Latenz. Im Extremfall halten sie das Spiel fälschlich für einen Angriff und blockieren es. - Warum → Folge → Auf dem Bildschirm: Sicherheitssoftware prüft gesendete und empfangene Pakete einzeln → Jedes Paket bekommt zusätzliche Verzögerung, staut sich die Prüfung, werden Pakete verworfen → Ping schlägt unregelmäßig aus, oder die Verbindung wird blockiert - Symptome: Ruckeln, Kein Login / Endlos-Laden / Faktoren: Jitter, Paketverlust - Wer: Nur ich / Wann: Immer, Direkt nach Login oder Wartung - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Kompatibilitätsliste für Sicherheitssoftware pflegen, bei der Installation eine Ausnahme für das Spiel in der Windows-Firewall eintragen. - Aufgaben Extern: Spielern empfehlen, das Spiel in der Sicherheitssoftware als Ausnahme einzutragen, bei Fehlerkennung als Angriff den Hersteller um Korrektur des False Positives bitten. - Größenordnungen: Im Normalfall kostet die Paketprüfung meist unter 1 ms. Problematisch wird es, wenn das Prüfmodul überlastet oder fehlerhaft ist oder die Kommunikation des Spiels fälschlich für einen Angriff hält. - Im Graphen: Nur einzelne Ausreißer (RTT, Verbindungsfehler (pro Spieler)) - Wo nachsehen: Mit kurz deaktivierter Sicherheitssoftware oder eingetragener Ausnahme für das Spiel vergleichen. Unter Windows nach Aktivieren von Audit Filtering Platform Connection und Audit Filtering Platform Packet Drop in der Überwachungsrichtlinie die Einträge 5157 (Verbindung blockiert) und 5152 (Paket blockiert) im Sicherheitsprotokoll prüfen und die Zahl verworfener Pakete über WFPv4\Packets Discarded/sec in der Leistungsüberwachung ansehen - Spricht dafür: Es gibt Blockiereinträge für Verbindungen oder Pakete zur Adresse des Spielservers, oder Ping-Spikes und Verbindungsfehler verschwinden, wenn die Sicherheitssoftware aus ist - Spricht dagegen: Andere Geräte im selben Haushalt zeigen dasselbe, unabhängig von der Sicherheitssoftware: Router oder Leitung - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [About Windows Filtering Platform](https://learn.microsoft.com/en-us/windows/win32/fwp/about-windows-filtering-platform) · Microsoft · Architektur, die über Hooks im Windows-Netzwerkstack und eine Filter-Engine Pakete zulässt oder blockiert, Drittanbieter von Sicherheitssoftware können eigene Filtermodule (Callouts) einhängen - [Windows Firewall Rules](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules) · Microsoft · Standardmäßig werden eingehende Verbindungen blockiert, daher brauchen Apps Ausnahmeregeln, die oft das Installationsprogramm der App anlegt - [Address false positives/negatives in Microsoft Defender for Endpoint](https://learn.microsoft.com/en-us/defender-endpoint/defender-endpoint-false-positives-negatives) · Microsoft · Vorgehen, wenn ein harmloses Programm fälschlich als Bedrohung erkannt wird (False Positive): Ausnahme einrichten und Datei zur Analyse bei Microsoft einreichen - [5157(F): The Windows Filtering Platform has blocked a connection.](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5157) · Microsoft · Ereignis 5157: Die Windows Filtering Platform hat eine Verbindung blockiert (Audit Filtering Platform Connection) - [Audit Filtering Platform Packet Drop](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-filtering-platform-packet-drop) · Microsoft · Ereignis 5152: Die Windows Filtering Platform hat ein Paket blockiert - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · WFPv4/WFPv6: Leistungsindikator Packets Discarded/sec #### co-rcvbuf · Überlauf des Empfangspuffers · Socket receive buffer overflow Ist das Spiel zu beschäftigt und holt Pakete zu spät aus dem Socket (der vom OS bereitgestellten Netzwerkschnittstelle zum Senden und Empfangen), läuft der Puffer des OS über. - Warum → Folge → Auf dem Bildschirm: Frames verzögern sich, das Spiel liest den Socket zu spät → Empfangspuffer des OS voll, UDP-Pakete werden verworfen, bei TCP wird das Receive Window verkleinert und der Sender gestoppt → Teleportieren (UDP) oder Zeitraffer (TCP) - Symptome: Teleportieren, Zeitraffer / Faktoren: Paketverlust, Stillstand - Wer: Nur ich / Wann: Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Eigener Empfangs-Thread, Puffergröße anpassen (SO_RCVBUF). - Größenordnungen: Der Standard-Empfangspuffer liegt je nach OS und Einstellung bei einigen Dutzend bis einigen hundert KB. Updates an belebten Orten erreichen mitunter mehrere hundert KB pro Sekunde. - Im Graphen: Steigt mit Spielerzahl und Last (Verworfene UDP-Pakete im Empfangspuffer, Frametime) - Wo nachsehen: In der Windows-Leistungsüberwachung Microsoft Winsock BSP\Dropped Datagrams (wegen zu kleinen Socket-Empfangspuffers verworfene UDP-Pakete) und UDPv4\Datagrams Received Errors zusammen mit der Frametime aufzeichnen, im Spiel Lücken in den Sequenznummern empfangener Pakete zählen - Spricht dafür: An belebten Orten oder direkt nach langen Frames steigt Dropped Datagrams, im selben Moment entstehen Lücken in den Sequenznummern des Spiels. Zur selben Zeit kein Verlust auf der Leitung - Spricht dagegen: Dropped Datagrams unverändert, aber Sequenznummern fehlen: Verlust unterwegs auf der Route - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · SO_RCVBUF ist die maximale Größe des Socket-Empfangspuffers, Standardwert aus rmem_default, Maximum aus rmem_max (auch Android nutzt den Linux-Kernel) - [SOL_SOCKET Socket Options (Winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/winsock/sol-socket-socket-options) · Microsoft · Windows SO_RCVBUF: Pufferplatz, der pro Socket für den Empfang reserviert wird - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Das Window-Feld von TCP gibt an, wie viele Bytes der Empfänger noch aufnehmen kann. Bei 0 sendet der Sender nur Zero-Window-Probes und wartet - [Low Latency Workloads Management and Operations](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh997022(v=ws.11)) · Microsoft · Dropped Datagrams und Dropped Datagrams/sec im Leistungsindikatorsatz Microsoft Winsock BSP: verworfene UDP-Pakete, weil sie schneller eintreffen, als die App sie verarbeitet, oder weil der Socket-Empfangspuffer zu klein ist - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Leistungsindikatoren UDPv4/UDPv6: Datagrams Received Errors und Microsoft Winsock BSP: Dropped Datagrams #### co-swap · Zu wenig Arbeitsspeicher und Swap auf dem Client · Paging / swap on client Laufen Dutzende Browser-Tabs neben dem Spiel, lagert das OS einen Teil des Spielspeichers auf den Datenträger aus. - Warum → Folge → Auf dem Bildschirm: Arbeitsspeicher insgesamt wird knapp → OS verschiebt gerade nicht genutzten Spielspeicher auf den Datenträger → Sobald dieser Teil wieder gebraucht wird, Stillstand von einigen Dutzend bis einigen hundert ms je nach Datenträger - Symptome: Freeze, Ruckeln / Faktoren: Stillstand - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel, Gelegentlich, zufällig - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Speicherverbrauch senken, bei wenig freiem Speicher eine Warnung anzeigen. - Aufgaben Extern: Spieler auf die Mindestanforderungen hinweisen, empfehlen, während des Spielens andere Programme (etwa Browser-Tabs) zu schließen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Hard Page Faults, Speicherverbrauch) - Wo nachsehen: Memory\Pages Input/sec aus der Leistungsüberwachung (Seiten, die zur Behebung von Hard Page Faults vom Datenträger gelesen wurden) sowie Speicherverbrauch und zugesicherten Speicher (Commit) im Reiter „Leistung“ des Task-Managers zusammen mit der Frametime aufzeichnen - Spricht dafür: Im Moment des Stillstands schießt Pages Input/sec hoch, und der Arbeitsspeicher ist fast voll. Werden Browser oder andere Programme geschlossen, verschwindet es - Spricht dagegen: Speicher hat Reserven, Pages Input/sec bleibt ruhig: „Synchrones Laden und Shader-Kompilierung im Main-Thread“ oder „Langsamer Datenträger bremst Asset-Streaming“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Introduction to the page file](https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/introduction-to-the-page-file) · Microsoft · Die Auslagerungsdatei ist eine Datei auf dem Datenträger, in die selten genutzte, geänderte Speicherseiten aus dem RAM ausgelagert werden - [Working Set](https://learn.microsoft.com/en-us/windows/win32/memory/working-set) · Microsoft · Zugriff auf eine Seite, die nicht im RAM liegt, löst einen Seitenfehler aus. Ein Hard Fault lässt sich nur durch Lesen vom Datenträger beheben, etwa aus der Auslagerungsdatei - [Chapter 12 - Detecting Memory Bottlenecks](https://learn.microsoft.com/en-us/previous-versions/cc749872(v=technet.10)) · Microsoft · Memory\Pages Input/sec: Seiten, die zur Behebung von Seitenfehlern vom Datenträger gelesen wurden (Hard Page Faults) #### co-vram · Zu wenig Grafikspeicher (VRAM) · VRAM over-commit Brauchen die Grafikoptionen mehr Speicher, als die Grafikkarte hat, lagert das OS Texturen in den Arbeitsspeicher des PCs aus und holt sie wieder zurück. Das Bild ruckelt. - Warum → Folge → Auf dem Bildschirm: Hohe Texturstufe und an belebten Orten jede Menge Ausrüstung und Effekte füllen den Grafikkartenspeicher → OS verschiebt gerade nicht genutzte Texturen in den PC-Arbeitsspeicher und holt sie bei Bedarf über den langsamen PCIe-Bus zurück → Bei jeder neuen Szene oder jedem neuen Charakter Stocken, Texturen bleiben eine Weile unscharf - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Nur ich / Wann: Bei großem Andrang, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Standardoptionen passend zur Größe des Grafikkartenspeichers, Texturqualität automatisch senken, wenn das Speicherbudget überschritten wird, an belebten Orten Charaktertexturen vereinfachen. - Aufgaben Extern: Spielern empfehlen, die Texturstufe zu senken, und bei zwei gleichzeitig laufenden Clients die Optionen noch weiter zu senken. - Größenordnungen: Grafikkartenspeicher liest mehrere hundert GB pro Sekunde. Der PCIe-Bus zum PC-Arbeitsspeicher schafft je nach Generation etwa 16–64 GB pro Sekunde und ist damit mehr als zehnmal langsamer. - Im Graphen: Plateau am Limit (Dedizierter GPU-Speicher, gemeinsam genutzter GPU-Speicher) - Wo nachsehen: Im Reiter „Leistung“ des Task-Managers unter „GPU“ die Graphen für dedizierten und gemeinsam genutzten GPU-Speicher (im Reiter „Details“ lassen sich auch Spalten pro Prozess hinzufügen) zusammen mit der Frametime aus PresentMon ansehen - Spricht dafür: Solange der dedizierte GPU-Speicher flach am Limit klebt und der gemeinsam genutzte GPU-Speicher steigt, stockt es häufig. Mit niedrigerer Texturstufe verschwindet es - Spricht dagegen: Dedizierter Speicher hat Reserven: „Langsamer Datenträger bremst Asset-Streaming“ oder „Synchrones Laden und Shader-Kompilierung im Main-Thread“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Läuft im Windows-Task-Manager unter „GPU“ der „Dedizierte GPU-Speicher“ voll und steigt der „Gemeinsam genutzte GPU-Speicher“, liegt dieser Zustand vor. Mit zwei Clients auf demselben PC ist er schneller voll (siehe „Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM“). - Quellen: - [Residency](https://learn.microsoft.com/en-us/windows/win32/direct3d12/residency) · Microsoft · Jeder Prozess hat ein Budget an Grafikspeicher. Wird es überschritten, verschiebt der Kernel einen Teil des Heaps der diskreten GPU in den PC-Arbeitsspeicher (letztes Mittel, daher wird Budgetverwaltung empfohlen) - [GPUs in the task manager](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) · Microsoft · Dedizierter GPU-Speicher im Task-Manager ist der VRAM der Grafikkarte, gemeinsam genutzter GPU-Speicher ist PC-Arbeitsspeicher, den GPU und CPU gemeinsam nutzen - [CUDA C++ Best Practices Guide](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html) · NVIDIA · Die Bandbreite des Grafikspeichers (V100: 898 GB/s) ist weit größer als die von PCIe x16 der 3. Generation (16 GB/s), daher wird empfohlen, Transfers zum PC-Arbeitsspeicher zu reduzieren - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Aufzeichnung der Zeit pro Frame über FrameTime (CPU-Zeit zwischen Frames) #### co-wifi-scan · WLAN-Hintergrundscan · Periodic Wi-Fi background scan Während das OS regelmäßig die Kanäle wechselt, um nach WLANs in der Umgebung zu suchen, setzt die Übertragung kurz aus. - Warum → Folge → Auf dem Bildschirm: OS oder Treiber suchen in festen Abständen nach WLANs in der Umgebung → Während der Suche setzen Senden und Empfangen kurz aus → Ping schlägt in exakt gleichen Abständen aus (z. B. alle 60 s) - Symptome: Ruckeln, Teleportieren / Faktoren: Jitter - Wer: Nur ich / Wann: In festen Abständen - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Während des Spielens einen Modus mit weniger Funkscans anfordern (unter Android den Low-Latency-WLAN-Modus WIFI_MODE_FULL_LOW_LATENCY, unter Windows den Media-Streaming-Modus von WlanSetInterface. Je nach Gerät und Treiber mitunter ohne Wirkung). - Aufgaben Extern: Spielern ein LAN-Kabel empfehlen, Einstellungen für Standortdienste und automatische WLAN-Suche anpassen lassen, WLAN-Treiber aktualisieren lassen. - Größenordnungen: Meist einige Dutzend bis einige hundert ms pro Scan. Ist das Muster auffällig regelmäßig, steht diese Ursache als Erstes unter Verdacht. - Im Graphen: Spitzen in festen Abständen (RTT bis zum Router) - Wo nachsehen: Während des Spielens mit ping /t einige Minuten lang die Router-Adresse (Standardgateway aus ipconfig) anpingen und die Abstände der Ausschläge messen. Dieselbe Messung per LAN-Kabel wiederholen - Spricht dafür: Der Ping zum Router schlägt in exakt gleichen Abständen (z. B. 60 s) um einige Dutzend bis einige hundert ms aus, per LAN-Kabel verschwindet es - Spricht dagegen: Ausschläge in unregelmäßigen Abständen: „WLAN-Funkstörungen und schwaches Signal“. Bis zum Router alles normal, Ausschläge erst dahinter: Leitung oder Providerstrecke - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [WDI low latency connection quality](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/wdi-low-latency-connection-quality) · Microsoft · Scans und Roaming lenken den Funkchip vom verbundenen Kanal weg, daher begrenzt der Low-Latency-Modus die Zeit außerhalb des Kanals und die Scans - [WlanSetInterface function (wlanapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/nf-wlanapi-wlansetinterface) · Microsoft · API unter Windows zum Ein- und Ausschalten des Hintergrundscans (wlan_intf_opcode_background_scan_enabled) und des Media-Streaming-Modus - [Wi-Fi low-latency mode](https://source.android.com/docs/core/connect/wifi-low-latency) · Android (Google) · Im Low-Latency-Modus wird der WLAN-Energiesparmodus abgeschaltet, die Optimierung von Scan- und Roaming-Einstellungen hängt von der Implementierung des Geräteherstellers ab - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /t: sendet Echoanforderungen, bis der Vorgang abgebrochen wird - [ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) · Microsoft · Ohne Parameter zeigt es IPv4- und IPv6-Adressen sowie das Standardgateway pro Adapter #### co-driver · NIC-Energiesparmodus und Treiberprobleme · NIC power saving, driver bugs Gehen Netzwerkkarte oder WLAN-Chip zwischen zwei Paketen in einen Energiesparzustand, braucht das Aufwachen Zeit. - Warum → Folge → Auf dem Bildschirm: Energiesparfunktion des Netzwerkgeräts aktiv oder Treiber veraltet → Verzögerung beim Aufwachen (Wake-up), gelegentlich Neustart des Geräts → Unregelmäßige Verzögerungen, selten Stillstand von einigen Sekunden - Symptome: Ruckeln, Freeze / Faktoren: Jitter, Paketverlust - Wer: Nur ich / Wann: Nach Inaktivität, Gelegentlich, zufällig - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Im Android-Client während des Spielens den Low-Latency-WLAN-Modus (WIFI_MODE_FULL_LOW_LATENCY) anfordern und so den WLAN-Energiesparmodus abschalten. - Aufgaben Extern: Spielern empfehlen, den Netzwerktreiber zu aktualisieren und im Geräte-Manager den Energiesparmodus des Netzwerkgeräts abzuschalten, bei Stocken des ganzen Bildes mit knisterndem Ton den verursachenden Treiber mit LatencyMon suchen lassen. - Im Graphen: Vereinzelte Spitzen ohne Muster (DPC- und ISR-Zeit, RTT bis zum Router) - Wo nachsehen: Mit dem Windows Performance Recorder (WPR) aufzeichnen, im DPC/ISR-Graphen des Windows Performance Analyzer (WPA) Treiber mit langer Laufzeit suchen (Spalte Module) und im Geräte-Manager die Energieverwaltung des Netzwerkadapters prüfen - Spricht dafür: Zum Zeitpunkt des Stockens laufen DPCs und ISRs des Netzwerktreibers jeweils mehrere ms am Stück, oder die unregelmäßigen Verzögerungen verschwinden, wenn der Energiesparmodus aus ist - Spricht dagegen: DPCs kurz und mit abgeschaltetem Energiesparmodus unverändert: „WLAN-Funkstörungen und schwaches Signal“ oder „WLAN-Hintergrundscan“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Belegt ein Treiber die CPU lange mit der Verarbeitung von Interrupts (unter Windows DPC-Latenz genannt), kann auch der Game-Thread diesen Kern nicht nutzen. Dann stockt das ganze Bild trotz niedriger CPU-Auslastung, und der Ton knistert. Werkzeuge wie LatencyMon zeigen, welcher Treiber es ist. Häufige Ursache sind WLAN- und LAN-Treiber. - Quellen: - [Introduction to NDIS Selective Suspend](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/ndis-selective-suspend) · Microsoft · Windows kann inaktive Netzwerkadapter in einen Energiesparzustand versetzen (selektives Energiesparen) - [Guidelines for Writing DPC Routines](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/guidelines-for-writing-dpc-routines) · Microsoft · Während ein DPC läuft, stehen alle Threads auf diesem Kern still. Daher die Empfehlung, pro Aufruf 100 µs nicht zu überschreiten - [Wi-Fi low-latency mode](https://source.android.com/docs/core/connect/wifi-low-latency) · Android (Google) · Im Low-Latency-WLAN-Modus von Android schaltet das Framework den WLAN-Energiesparmodus ausdrücklich ab - [CPU Analysis](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/cpu-analysis) · Microsoft · DPC/ISR-Graph in WPA: Dauer jedes ununterbrochenen DPC- oder ISR-Abschnitts und das Modul (Module), das die Funktion enthält #### co-other-apps · Bandbreitenbelegung durch andere Apps auf demselben Gerät · Other apps saturating the link Laufen Cloud-Synchronisation, große Downloads oder Spiel-Patches auf demselben PC, warten die Spielpakete in der Warteschlange. - Warum → Folge → Auf dem Bildschirm: Andere Apps lasten Upload oder Download voll aus → Spielpakete stauen sich in den Warteschlangen von PC und Router → Ping schießt hoch, Input-Lag, Zeitraffer - Symptome: Input-Lag, Zeitraffer / Faktoren: Latenz, Jitter - Wer: Nur ich, Gleicher Haushalt / Wann: Gelegentlich, zufällig - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Im eigenen Launcher und Patcher Hintergrund-Downloads während des Spielens anhalten oder drosseln. - Aufgaben Extern: Spielern empfehlen, die Download-Geschwindigkeit zu begrenzen und automatische Updates während des Spielens abzuschalten. - Im Graphen: Steigt mit Spielerzahl und Last (RTT, gesendete und empfangene Datenmenge des PCs) - Wo nachsehen: Network Interface\Bytes Sent/sec und Bytes Received/sec aus der Leistungsüberwachung zusammen mit dem Ping aufzeichnen. Gleiches Vorgehen wie beim Bufferbloat-Test, bei dem man bei laufendem Ping absichtlich eine große Übertragung startet - Spricht dafür: Solange Download oder Upload die Leitungsgeschwindigkeit fast ausschöpfen, steigt der Ping um einige Dutzend bis einige hundert ms und normalisiert sich sofort, wenn die Übertragung stoppt - Spricht dagegen: Datenmenge des PCs gering, Ping steigt trotzdem: „Bufferbloat (Warteschlange im Router)“ durch ein anderes Gerät im Haushalt oder Providerstrecke - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Introduction](https://www.bufferbloat.net/projects/bloat/wiki/Introduction/) · Bufferbloat.net · Puffern Netzwerkgeräte wie Router zu viele Daten, schießt die Latenz stark hoch (Bufferbloat) - [Delivery Optimization reference](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference) · Microsoft · Downloads von Windows Update (Übermittlungsoptimierung) passen sich standardmäßig dynamisch an die verfügbare Bandbreite an, für Hintergrund- und Vordergrund-Downloads lassen sich Bandbreitenobergrenzen festlegen - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Network Interface: Leistungsindikatoren Bytes Received/sec und Bytes Sent/sec - [Tests for Bufferbloat](https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/) · Bufferbloat.net · Steigt der Ping, während ein Speedtest die Leitung bei laufendem Ping auslastet, liegt Bufferbloat vor #### co-unfocused · Drosselung bei minimiertem oder inaktivem Fenster · Minimized / unfocused window throttling Wechselt man in ein anderes Fenster oder minimiert das Spiel, lassen Spiel und Windows es zum Stromsparen langsamer laufen. Bei der Rückkehr kommen die aufgestauten Pakete auf einmal, oder die Verbindung ist schon abgebrochen. - Warum → Folge → Auf dem Bildschirm: Mit Alt+Tab in ein anderes Fenster gewechselt oder Spiel minimiert → Solange das Spiel nicht sichtbar ist, senkt es die FPS stark oder pausiert, auch Windows senkt die Priorität nicht sichtbarer Programme → Im Moment der Rückkehr Zeitraffer, nach längerer Zeit im Hintergrund Verbindungsabbruch - Symptome: Zeitraffer, Ruckeln, Verbindungsabbruch / Faktoren: Stillstand - Wer: Nur ich / Wann: Bei bestimmten Aktionen, Nach Inaktivität - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Paketempfang und Heartbeat auch bei unsichtbarem Fenster in einem eigenen Thread weiterlaufen lassen, Engine-Einstellung „Im Hintergrund ausführen“ (Run In Background) prüfen, bei der Rückkehr in einem Schritt auf den aktuellen Zustand abgleichen. - Größenordnungen: Senkt das Spiel die FPS bei unsichtbarem Fenster auf 5–10, dauert ein Frame 100–200 ms. Spiele, die Pakete pro Frame verarbeiten, lesen Pakete entsprechend später. - Im Graphen: Lücke, dann alles auf einmal (Frame-Abstand (vor und nach dem Fensterwechsel), Anzahl verarbeiteter Pakete) - Wo nachsehen: Bei laufendem PresentMon Alt+Tab und Minimieren ausprobieren und den Frame-Abstand bei unsichtbarem Fenster ansehen. Im Spiel-Log die Zeitpunkte von Fokuswechseln protokollieren und mit den Trennungsgründen abgleichen - Spricht dafür: Solange das Fenster nicht sichtbar ist, steigt der Frame-Abstand auf 100 ms oder mehr, oder die Aufzeichnung reißt ab. Im Moment der Rückkehr werden aufgestaute Pakete auf einmal verarbeitet: Zeitraffer. Nach längerer Zeit im Hintergrund Trennung wegen Heartbeat-Timeout - Spricht dagegen: Gleiches Verhalten auch bei sichtbarem Fenster: „CPU-Belegung durch Hintergrundprozesse“ oder Netzwerkseite - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Windows 11 garantiert Programmen, deren Fenster minimiert oder vollständig verdeckt ist und keinen Ton ausgibt, keinen 1-ms-Timer. Auf Notebooks im Akkubetrieb drosselt Windows solche Programme auf die sparsamste Taktrate und lässt sie bei CPUs mit gemischten Kerntypen mitunter auf den langsamen Effizienzkernen laufen. Verhält sich von zwei Clients auf demselben PC nur der im Hintergrund auffällig, sehen Sie sich zusätzlich „Drosselung von Hintergrundfenstern“ an. - Quellen: - [Quality of Service](https://learn.microsoft.com/en-us/windows/win32/procthread/quality-of-service) · Microsoft · Programme mit Fenstern, die weder sichtbar noch hörbar sind, erhalten Low QoS und laufen im Akkubetrieb mit der effizientesten CPU-Taktrate auf Effizienzkernen - [timeBeginPeriod function (timeapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod) · Microsoft · Windows 11 garantiert Prozessen mit verdeckten oder minimierten Fenstern keine höhere Timer-Auflösung als den Standard - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Unity-Standardwert ist false, daher hält die Game-Loop an, sobald das Fenster in den Hintergrund geht - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsBetweenPresents: Zeit zwischen diesem und dem vorigen Present()-Aufruf (ms) #### co-overlay · Störung durch Overlay-Programme · Overlays and screen hooks Messenger, Launcher, Aufnahmeprogramme und FPS-Anzeigen klinken sich in das Rendering des Spiels ein (Hooking), um ihre eigene UI über das Spielbild zu zeichnen. Das kostet in jedem Frame zusätzliche Arbeit und kollidiert gelegentlich mit dem Spiel, sodass es stockt oder zwangsweise beendet wird. - Warum → Folge → Auf dem Bildschirm: Overlays von Messengern, Spiel-Launchern, Grafikkarten-Tools oder Aufnahmeprogrammen sind aktiv → Bei jeder Ausgabe eines Frames klinkt sich das Overlay ein und zeichnet seine UI darüber → Frames kommen etwas später, beim Einblenden einer Benachrichtigung Stocken, Grafikfehler oder erzwungenes Beenden (für den Spieler wie ein Verbindungsabbruch) - Symptome: Ruckeln, Freeze, Verbindungsabbruch / Faktoren: Stillstand - Wer: Nur ich / Wann: Immer, Gelegentlich, zufällig - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: In Absturzberichten und Ruckel-Logs die Liste laufender Overlays mit erfassen. - Aufgaben Extern: Bei Meldungen Spieler bitten, alle Overlays abzuschalten und erneut zu testen. - Im Graphen: Nur einzelne Ausreißer (Frametime und Anzahl der Abstürze (Spieler mit aktivem Overlay)) - Wo nachsehen: Mit allen Overlays aus die Frametime derselben Szene in PresentMon vergleichen, bei Abstürzen den Namen des fehlerhaften Moduls (Faulting module name) bei Ereignis-ID 1000 in der Ereignisanzeige prüfen - Spricht dafür: Mit abgeschalteten Overlays verschwinden Stocken und Grafikfehler, oder das fehlerhafte Modul des Absturzes ist eine DLL des Overlay-Programms - Spricht dagegen: Unverändert, auch wenn alle Overlays aus sind: Grafiktreiber oder „Client-Absturz“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Ruckelt das Spiel nur bei bestimmten Spielern oder stürzt es ab, und lässt sich das nicht mit der Hardware erklären, stehen Konflikte zwischen Overlays und dem Sicherheitsmodul des Spiels als Erstes unter Verdacht. - Quellen: - [Steam Overlay (Steamworks Documentation)](https://partner.steamgames.com/doc/features/overlay) · Valve · Das Steam-Overlay klinkt sich automatisch in über Steam gestartete Spiele ein und kann dadurch Speicherfehler im Umgang des Spiels mit der Rendering-API zutage fördern, was zu Abstürzen führt - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Aufzeichnung der Zeit pro Frame über FrameTime (CPU-Zeit zwischen Frames) - [The application or service crashing behavior troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-application-service-crashing-behavior) · Microsoft · Ereignis-ID 1000 im Anwendungsprotokoll enthält den Namen des fehlerhaften Moduls (Faulting module name). Durch Beschädigung in einem anderen Modul wird mitunter ein Windows-Modul als fehlerhaftes Modul eingetragen #### co-display-input · Latenz von Display, Eingabegeräten und Frame Generation · Display, input device and frame generation latency Ist der Ping normal, die Steuerung aber schwerfällig, fügen womöglich die Bildverarbeitung des Fernsehers, ein kabelloser Controller oder Frame Generation Verzögerung zwischen Eingabe und Bild ein. - Warum → Folge → Auf dem Bildschirm: Spielmodus am Fernseher aus, Bluetooth- oder Funk-Controller in Gebrauch oder Frame Generation (DLSS bzw. FSR Frame Generation) aktiv → Der Fernseher gibt Frames während der Bildverarbeitung verspätet aus, kabellose Eingaben verspäten sich um das Sendeintervall und durch Störungen, Frame Generation wartet auf den nächsten Frame und erzeugt dann den Zwischenframe → Ping und FPS-Zahl gut, aber bis ein Tastendruck auf dem Bildschirm erscheint, dauert es: Input-Lag - Symptome: Input-Lag / Faktoren: Latenz - Wer: Nur ich / Wann: Immer - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Frame Generation als optionale Einstellung anbieten und darauf hinweisen, dass sie den Input-Lag erhöhen kann, bei Frame Generation die Low-Latency-Funktionen der Grafikhersteller einbinden (NVIDIA Reflex, AMD Anti-Lag 2), im Spiel eine Anzeige der PC-seitigen Latenz von Eingabe bis Bild anbieten, in Builds für Android TV und Set-Top-Boxen mit Window.setPreferMinimalPostProcessing(true) beim Fernseher den Low-Latency-Modus (ALLM) anfordern. - Aufgaben Extern: Spielern empfehlen, den Spielmodus (ALLM) an Fernseher oder Monitor einzuschalten, in kompetitiven Inhalten einen kabelgebundenen Controller zu nutzen und Frame Generation abzuschalten, Bluetooth-Geräte nah zu halten und WLAN im 5-GHz-Band zu nutzen. - Größenordnungen: Ein 60-Hz-Display braucht allein für die Übertragung eines Frames 16,7 ms, bei 120 Hz 8,3 ms. Ältere Xbox-Controller lasen Eingaben alle 8 ms aus und sendeten sie. Die zusätzliche Verzögerung durch die Bildverarbeitung eines Fernsehers ist je nach Gerät verschieden und lässt sich nicht mit einer Zahl angeben. Der Spielmodus ist die Einstellung, die diese Verarbeitung reduziert. Für Frame Generation empfiehlt AMD eine Bildrate von mindestens 60 FPS vor der Generierung. - Im Graphen: Von Anfang an dauerhaft hoch (Latenz von der Eingabe bis zur Anzeige) - Wo nachsehen: MsAllInputToPhotonLatency aus PresentMon (von Tastatur- oder Mauseingabe bis zur Ausgabe an den Bildschirm) mit ein- und ausgeschalteter Frame Generation vergleichen und über FrameType (nur aufgezeichnet, wenn Treiber oder SDK es melden) prüfen, ob generierte Zwischenframes dabei sind. Funkstrecke des Controllers und Verarbeitung im Fernseher sind in diesem Wert nicht enthalten, diesen Teil durch Wechsel auf Spielmodus am Fernseher und kabelgebundenen Controller vergleichen - Spricht dafür: Ping normal, und mit abgeschalteter Frame Generation sinkt die Latenz von Eingabe bis Bild, oder mit Spielmodus am Fernseher und kabelgebundenem Controller verschwindet die gefühlte Verzögerung - Spricht dagegen: Unverändert trotz Änderung all dieser Einstellungen, Ping hoch oder schwankend: Netzwerkseite. PC-seitige Latenz durch V-Sync oder Frame-Warteschlange hoch: „V-Sync und Render-Warteschlange“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Netzwerklatenz zeigt sich im Ping, diese Verzögerung taucht dort nicht auf. Deshalb ist sie bei Meldungen wie „Ping niedrig, aber es laggt“ als Erstes zu prüfen. Frame Generation verdoppelt ungefähr die angezeigte FPS-Zahl. Für den Zwischenframe muss sie aber auf den nächsten echten Frame warten, daher dauert es länger, bis eine Eingabe auf dem Bildschirm erscheint (laut AMD steigt die Latenz konstruktionsbedingt). Bluetooth-Geräte nutzen dasselbe 2,4-GHz-Band wie WLAN. Bei Störungen können Eingaben aussetzen oder springen. Zu V-Sync und Render-Warteschlange, die die Latenz im PC erhöhen, siehe „V-Sync und Render-Warteschlange“. - Quellen: - [Auto Low Latency Mode (ALLM)](https://www.hdmi.org/spec21sub/autolowlatencymode) · HDMI Licensing Administrator · ALLM lässt das Gerät das Display automatisch in den Low-Latency-Modus (meist Spielmodus) schalten, im Low-Latency-Modus setzt der Fernseher einen Teil der Bildverarbeitung aus, um die Latenz zu senken - [Xbox Series X: What’s the Deal with Latency?](https://news.xbox.com/en-us/2020/03/16/xbox-series-x-latency/) · Microsoft · Input-Lag ist die Summe der Strecke Controller → Konsole → HDMI → Fernseher, ältere Controller lasen Eingaben alle 8 ms aus und sendeten sie, Übertragung eines Frames per HDMI bei 60 Hz 16,6 ms und bei 120 Hz 8,3 ms, automatischer Wechsel in den Spielmodus des Fernsehers per ALLM - [AMD FSR 3 game integrations out now + more details for developers](https://gpuopen.com/news/fsr3-in-games-technical-details/) · AMD · Frame-Interpolation erhöht konstruktionsbedingt die Latenz, empfohlen ab einer Bildrate von 60 vor der Interpolation, bei 60 FPS Eingang bis zu 120 FPS Ausgabe - [AMD FSR Frame Generation](https://gpuopen.com/amd-fsr-framegeneration/) · AMD · Frame Generation empfohlen ab 60 FPS vor der Interpolation (unter 30 FPS vermeiden), AMD Radeon Anti-Lag 2 stimmt CPU- und GPU-Arbeit aufeinander ab und senkt die Systemlatenz - [NVIDIA DLSS](https://developer.nvidia.com/rtx/dlss) · NVIDIA · DLSS Frame Generation ist darauf ausgelegt, zusammen mit NVIDIA Reflex (Low-Latency-Funktion) die Reaktionsfähigkeit zu erhalten - [Resolve Wi-Fi and Bluetooth issues caused by wireless interference](https://support.apple.com/en-us/102319) · Apple · Funkstörungen verursachen Aussetzer und Leistungseinbußen bei WLAN- und Bluetooth-Geräten, Bluetooth und WLAN nutzen dasselbe 2,4-GHz-Band - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsAllInputToPhotonLatency (Latenz von Eingabe bis Bild), DisplayLatency (Übergabe des Frames bis zur Ausgabe an den Monitor), FrameType (unterscheidet von der App gezeichnete und von Treiber oder SDK interpolierte Frames) - [PresentMon Console Application (README-ConsoleApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-ConsoleApplication.md) · Intel · MsAllInputToPhotonLatency bezieht sich auf Tastatur- und Mauseingaben, FrameType wird nur aufgezeichnet, wenn App oder Treiber Intel-PresentMon-Events ausgeben (--track_frame_type) - [Window.setPreferMinimalPostProcessing](https://developer.android.com/reference/android/view/Window#setPreferMinimalPostProcessing(boolean)) · Android (Google) · Fenster, bei denen Latenz zählt, etwa Spiele, fordern beim Display minimale Bildverarbeitung an. Bei HDMI-Verbindung werden ALLM- und Game-Content-Type-Signale gesendet, die den Fernseher in den Low-Latency-Modus schalten ### L3 Heimnetz (10 Ursachen) #### hn-wifi · WLAN-Funkstörungen und schwaches Signal · Wi-Fi interference, weak signal Bei schwachem Signal oder Störungen muss auf der Funkstrecke mehrfach erneut gesendet werden, und die Pakete kommen unregelmäßig an. - Warum → Folge → Auf dem Bildschirm: Wände, Entfernung, Mikrowelle, Bluetooth oder Router der Nachbarn verschlechtern die Funkqualität → Übertragung auf der Funkstrecke scheitert → mehrfache Retransmission → Pakete kommen unregelmäßig an (Jitter), Charaktere bewegen sich stockend, in schweren Fällen führt Paketverlust zu Teleportieren - Symptome: Ruckeln, Teleportieren, Rubberbanding / Faktoren: Jitter, Paketverlust - Wer: Nur ich, Gleicher Haushalt / Wann: Gelegentlich, zufällig, Immer - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Länge des Interpolationspuffers automatisch an die Verbindungsqualität anpassen, bei hohem Jitter oder Paketverlust den Netzwerkstatus im Bild anzeigen. - Aufgaben Extern: Spielern ein LAN-Kabel, 5 GHz oder 6 GHz und einen anderen Standort für den Router empfehlen. - Größenordnungen: Jede Retransmission kostet etwa 1–4 ms extra. Bei schwachem Signal wird mehrfach mit niedriger Rate erneut gesendet und zusätzlich gewartet, bis der Kanal frei ist. So entstehen Ausschläge von 50–200 ms. Die Falle: Der durchschnittliche Ping sieht unauffällig aus. - Im Graphen: Vereinzelte Spitzen ohne Muster (RTT bis zum Router) - Wo nachsehen: Mit ping /t einige Minuten lang die Router-Adresse (Standardgateway aus ipconfig) messen und mit netsh wlan show networks mode=bssid Signalstärke und Kanal des eigenen Routers prüfen. Am selben Platz per LAN-Kabel vergleichen - Spricht dafür: Schon der Ping zum Router schlägt unregelmäßig um einige Dutzend bis einige hundert ms aus, gelegentlich mit Paketverlust, die Signalstärke ist niedrig. Per LAN-Kabel oder nahe am Router verschwindet es - Spricht dagegen: Bis zum Router gleichmäßig, Ausschläge erst dahinter: Leitung oder Providerstrecke. Ausschläge nur in gleichen Abständen: „WLAN-Hintergrundscan“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Sind die Knoten eines Mesh-WLANs per Funk verbunden (Wireless Backhaul), kann ein weiterleitender Knoten nicht senden, während er empfängt, und teilt sich die Sendegelegenheiten mit den Abschnitten davor und danach auf demselben Kanal. Bei viel Betrieb sinkt der Durchsatz, und die Latenz steigt. Produkte mit eigenem Funkband für den Backhaul sind weniger betroffen. Werden die Knoten per Kabel (Ethernet) verbunden, fällt diese Funkstrecke weg. Powerline-Adapter (PLC) senden wie WLAN erst nach Prüfung, ob das Medium frei ist (CSMA/CA). Ihre Qualität ändert sich laufend mit dem Rauschen von Haushaltsgeräten und deren Ein- und Ausschalten, was Retransmissions und Jitter verursachen kann. - Reale Fälle: ffxiv-2021 - Quellen: - [Resolve Wi-Fi and Bluetooth issues caused by wireless interference](https://support.apple.com/en-us/102319) · Apple · Störquellen wie Mikrowellen und schnurlose Telefone, WLAN und Bluetooth nutzen dasselbe 2,4-GHz-Band, empfohlen werden der Wechsel auf 5 GHz und ein Kanal mit wenig Störungen - [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325) · IETF · CSMA/CA in 802.11: Gesendet wird nur bei freiem Kanal. Ist er belegt, wird gewartet, bis er frei ist, und dann zusätzlich um einen zufälligen Backoff - [Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017)](https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf) · USENIX · Die Standard-Warteschlange eines ausgelasteten WLANs verursacht mehrere hundert ms Latenz, Geräte mit niedriger Rate (schwaches Signal) liegen selbst mit FQ-CoDel im Median über 200 ms - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /t: sendet Echoanforderungen, bis der Vorgang abgebrochen wird - [ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) · Microsoft · Ohne Parameter zeigt es IPv4- und IPv6-Adressen sowie das Standardgateway pro Adapter - [Wireless network connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/wireless-network-connectivity-issues-troubleshooting) · Microsoft · netsh wlan show networks mode=bssid: zeigt für jedes sichtbare WLAN BSSID, Signalstärke, Kanal und Funkstandard - [Capacity of Ad Hoc Wireless Networks (MobiCom 2001)](https://pdos.csail.mit.edu/papers/grid:mobicom01/paper.pdf) · ACM · Bei mehrfacher Weiterleitung über 802.11-Funk kann ein Knoten nicht senden, während er empfängt, und benachbarte Abschnitte stören sich gegenseitig. Der Durchsatz einer linearen Weiterleitungskette sinkt theoretisch auf ein Drittel (in der Simulation auf etwa ein Siebtel) - [Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015)](https://conferences.sigcomm.org/imc/2015/papers/p325.pdf) · ACM · Handelsübliche Powerline-Geräte (IEEE 1901, HomePlug AV) senden ähnlich wie WLAN per CSMA/CA, kurzzeitige Unfairness kann den Jitter erhöhen, die Kanalqualität ändert sich mit dem Rauschen von Haushaltsgeräten und deren Ein- und Ausschalten (im Bereich von Minuten bis Stunden) #### hn-channel · Überlasteter WLAN-Kanal · Crowded Wi-Fi channel Wo wie in großen Wohnanlagen Dutzende Router funken, teilen sie sich denselben Kanal und müssen auf Sendegelegenheiten warten. - Warum → Folge → Auf dem Bildschirm: Dutzende Router nutzen denselben 2,4-GHz-Kanal → Vor dem Senden wird gewartet, bis die Übertragungen anderer Geräte vorbei sind und der Kanal frei ist → Abends, wenn alle zu Hause sind, steigt der Jitter (Schwankung der Ankunftsabstände), Ruckeln - Symptome: Ruckeln, Input-Lag / Faktoren: Jitter, Latenz - Wer: Gleicher Haushalt / Wann: Abendliche Stoßzeit - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Bei steigendem Jitter den Interpolationspuffer automatisch verlängern. - Aufgaben Extern: Spielern 5 GHz oder 6 GHz, einen weniger belegten Kanal oder ein LAN-Kabel empfehlen. - Im Graphen: Nur zu bestimmten Tageszeiten hoch (RTT und Jitter bis zum Router) - Wo nachsehen: Mit netsh wlan show networks mode=bssid Kanäle und Signalstärken der WLANs in der Umgebung ansehen und den Ping zum Router abends und tagsüber vergleichen - Spricht dafür: Auf demselben 2,4-GHz-Kanal sind viele Router der Umgebung zu sehen, und der Jitter bis zum Router steigt nur abends. Mit 5 GHz oder 6 GHz oder einem weniger belegten Kanal sinkt er - Spricht dagegen: Ausschläge unabhängig von der Tageszeit: „WLAN-Funkstörungen und schwaches Signal“. Bis zum Router in Ordnung, abends nur dahinter schlecht: „Überlast am Peering-Punkt zur Stoßzeit“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Recommended settings for Wi-Fi routers and access points](https://support.apple.com/en-us/102766) · Apple · Andere Router und Geräte auf demselben Kanal sind Störquellen, für 2,4 GHz wird eine Kanalbreite von 20 MHz empfohlen, bei 5 GHz und 6 GHz sind Störungen ein geringeres Problem - [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325) · IETF · 802.11 verschiebt das Senden bei belegtem Kanal, bis er frei ist, und sendet nach einem zufälligen Backoff (CSMA/CA) - [Wireless network connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/wireless-network-connectivity-issues-troubleshooting) · Microsoft · netsh wlan show networks mode=bssid: zeigt für jedes sichtbare WLAN BSSID, Signalstärke, Kanal und Funkstandard - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /t: sendet Echoanforderungen, bis der Vorgang abgebrochen wird #### hn-bufferbloat · Bufferbloat (Warteschlange im Router) · Bufferbloat Lädt jemand im Haushalt ein Video hoch oder eine große Datei herunter, stauen sich im Router Pakete für mehrere hundert ms, und die Spielpakete warten dahinter. - Warum → Folge → Auf dem Bildschirm: Video-Uploads oder Cloud-Backups anderer Haushaltsmitglieder, eigenes Streaming oder große Downloads lasten die Leitung voll aus → Router oder Modem puffern überschüssige Pakete in einer großen Warteschlange → Auch Spielpakete warten am Ende der Warteschlange, der Ping schießt auf mehrere hundert ms hoch - Symptome: Input-Lag, Zeitraffer, Teleportieren / Faktoren: Latenz, Jitter - Wer: Gleicher Haushalt, Nur ich / Wann: Gelegentlich, zufällig, Abendliche Stoßzeit - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Steigt der Ping plötzlich auf mehrere hundert ms, den Netzwerkstatus im Bild anzeigen (mit Hinweis auf mögliche große Übertragungen über dieselbe Leitung). - Aufgaben Extern: Spielern einen Router mit SQM (fq_codel, CAKE) oder QoS empfehlen, die SQM-Rate auf 90–95 % der Leitungsgeschwindigkeit setzen lassen (nur so entsteht die Warteschlange im Router und SQM wirkt), Upload-Geschwindigkeit begrenzen lassen. - Größenordnungen: Bei 10 Mbps Upload und 1 MB Puffer wird die Warteschlange bis zu 800 ms lang. - Im Graphen: Steigt mit Spielerzahl und Last (RTT, Upload- und Download-Auslastung der Leitung) - Wo nachsehen: Bei laufendem Ping die Leitung per Speedtest voll auslasten oder einen Webtest nutzen, der die Latenz unter Last misst (Hinweise von Bufferbloat.net). Zusammen mit der Upload- und Download-Auslastung in der Router-Oberfläche ansehen - Spricht dafür: Solange Upload oder Download die Leitung füllen, steigt der Ping auf mehrere hundert ms und normalisiert sich nach Ende der Übertragung (verdächtig ab über 50 ms Latenz unter Last). Mit SQM verschwindet es - Spricht dagegen: Ping-Ausschläge auch bei ruhiger Leitung: „WLAN-Funkstörungen und schwaches Signal“ oder „Schlechte Leitungsqualität“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Besonders oft verstopft der Upload. Bei Kabel- und Mobilfunkanschlüssen ist der Upload oft viel schmaler als der Download. In Haushalten mit reichlich Glasfaser-Bandbreite wird die WLAN-Strecke zum Engpass, und dasselbe passiert in der Funk-Warteschlange des Routers. Spielpakete sind klein und brauchen kaum Bandbreite, müssen aber genauso in der Warteschlange warten. Ist nur der Upload verstopft, kommen nur die eigenen Eingaben verzögert an, die Bewegungen anderer sind unauffällig. Auf Smartphones füllen Foto-Backups und App-Updates auf demselben Gerät die Warteschlangen von Modem und Funkzelle, mit demselben Effekt. - Quellen: - [Setting up SQM for CeroWrt 3.10](https://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310/) · Bufferbloat.net · Die SQM-Rate auf 95 % der gemessenen Geschwindigkeit (85 % bei Bezug auf die beworbene Geschwindigkeit) senken, damit der Engpass vom Gerät des Providers in den Router wandert, sonst wirkt SQM nicht - [SQM (Smart Queue Management)](https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm) · OpenWrt · Download- und Upload-Rate mit 90 % der gemessenen Werte eintragen, als Warteschlangenverfahren wird cake empfohlen (bei schwacher CPU fq_codel) - [Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017)](https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf) · USENIX · Ist die WLAN-Strecke ausgelastet, entstehen in der Funk-Warteschlange des Routers mehrere hundert ms Latenz, eine Korrektur der Funk-Warteschlange senkt die Latenz unter Last auf etwa ein Zehntel - [Tests for Bufferbloat](https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/) · Bufferbloat.net · Steigt der Ping, während ein Speedtest die Leitung bei laufendem Ping auslastet, liegt Bufferbloat vor, bei über 50 ms Latenz unter Last (oder schlechter als Note B) werden Gegenmaßnahmen empfohlen #### hn-nat · Ablauf des NAT-Mappings · NAT mapping timeout Router löschen Idle-Verbindungen, über die eine Weile keine Pakete gelaufen sind, aus der NAT-Tabelle. Das ist eine häufige Ursache dafür, dass die Verbindung genau dann abbricht, wenn man sich nach einer Pause wieder bewegt. - Warum → Folge → Auf dem Bildschirm: Router trägt die Verbindung „Gerät im Heimnetz ↔ Server draußen“ in die NAT-Tabelle (Adressumsetzungstabelle) ein → Ohne Pakete für eine Weile wird der Eintrag gelöscht (bei UDP häufig nach 30–120 s) → Serverpakete kommen nicht mehr ins Heimnetz, Verbindungsabbruch - Symptome: Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich, Gleicher Haushalt / Wann: Nach Inaktivität - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Heartbeats in Abständen von höchstens der Hälfte des kürzesten Idle-Timeouts senden (UDP-Mappings werden zuverlässig nur durch ausgehende Pakete aus dem Heimnetz erneuert, daher sendet der Client), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und die Verbindung bei längerem Ausbleiben selbst aufräumen, den Spieler per Session-Token (beim Login erhaltene Kennung) wiedererkennen und weiterführen, auch wenn sich durch ein gelöschtes Mapping externe Adresse und Port geändert haben. - Im Graphen: Verbindungen brechen gleichzeitig ab (Abbrüche (Heartbeat-Timeout), Idle-Zeit vor dem Abbruch) - Wo nachsehen: Trennungsgründe auf dem Server und die Zeit seit dem letzten Paket über diese Verbindung vor dem Abbruch (Idle-Zeit) sammeln und als Verteilung ansehen. Im Test den Abstand zwischen UDP-Paketen auf 30, 60 und 120 s erhöhen und messen, ab welchem Abstand keine Antworten mehr kommen - Spricht dafür: Nur Verbindungen ohne Aktivität brechen ab, die Idle-Zeiten häufen sich knapp oberhalb eines bestimmten Werts im Bereich 30–120 s. Mit kürzerem Heartbeat-Intervall verschwindet es - Spricht dagegen: Abbrüche auch während der Bewegung: Leitung oder Route. Häufung bei kurzen Werten nur bei einem bestimmten Mobilfunkanbieter: „Geteilte Provider-IP (CGNAT)“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · Der Timer eines UDP-Mappings darf nicht vor 2 Minuten ablaufen, empfohlen sind standardmäßig mindestens 5 Minuten, Erneuerung durch ausgehende Pakete ist Pflicht, durch eingehende optional - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Messung an 34 Heimroutern: UDP-Mappings bleiben 30–691 s bestehen, Median 90 s, bei mehr als der Hälfte unter 2 Minuten, bei TCP Median etwa 60 Minuten - [RFC 9308: Applicability of the QUIC Transport Protocol](https://www.rfc-editor.org/rfc/rfc9308) · IETF · Im Internet mit NAT auf dem Pfad sind Keepalives im Abstand von etwa 30 s angemessen, häufigere verschwenden Traffic und Energie #### hn-router · Leistungsschwacher oder überhitzter Router · Router CPU / session table exhaustion Hängen an einem billigen Router Dutzende Geräte mit Tausenden Verbindungen, kommt der Router selbst nicht mehr mit. - Warum → Folge → Auf dem Bildschirm: Dutzende Geräte, P2P und Torrents öffnen Tausende Verbindungen → Router-CPU und Session-Tabelle ausgelastet → Verzögerte Paketverarbeitung, Paketverlust, neue Verbindungen scheitern - Symptome: Ruckeln, Kein Login / Endlos-Laden, Verbindungsabbruch / Faktoren: Paketverlust, Jitter - Wer: Gleicher Haushalt / Wann: Je länger es läuft, Gelegentlich, zufällig - Hauptzuständig: Extern (Extern) - Aufgaben Extern: Spielern einen Neustart des Routers (vorübergehend), einen Routertausch und das Beenden von Programmen mit vielen Verbindungen (P2P, Torrents) empfehlen. - Im Graphen: Plateau am Limit (CPU und Verbindungszahl des Routers, RTT bis zum Router) - Wo nachsehen: In der Router-Oberfläche CPU-Auslastung, Zahl der Verbindungen (Sessions) und verbundenen Geräte ansehen (sofern der Router das anbietet) und den Ping zum Router selbst vor und nach einem Neustart vergleichen - Spricht dafür: Bei vielen Verbindungen schlägt schon der Ping zum Router aus oder es gibt Paketverlust, neue Verbindungen scheitern. Nach einem Neustart eine Weile in Ordnung, dann wieder schlechter - Spricht dagegen: Bis zum Router alles normal, nur dahinter schlecht: Leitung oder Providerstrecke - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Heimrouter erlauben zu einem Server-Port 16 bis etwa 1.024 TCP-Verbindungen (Median 135), günstige Geräte schaffen mitunter nur einen Durchsatz von einigen Mbps - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Höchstzahl der Einträge in der Connection-Tracking-Tabelle von Linux (nf_conntrack_max) und Standard-Haltezeiten je Zustand #### hn-handover · Handover zwischen Funkzellen (unterwegs) · Cellular handover Unterwegs in Bus oder U-Bahn setzt die Verbindung aus, während die Funkzelle wechselt. - Warum → Folge → Auf dem Bildschirm: Bei der Fortbewegung wechselt die verbundene Funkzelle → Meist eine Lücke von einigen Dutzend ms. Scheitert der Wechsel wegen schlechten Signals, auch Unterbrechungen von mehreren hundert ms bis einigen Sekunden → Stillstand, dann Teleportieren, bei längerer Lücke Verbindungsabbruch - Symptome: Freeze, Teleportieren, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Timeouts, die kurze Unterbrechungen verkraften, schneller Reconnect. Server: Timeouts, die Spieler nach einigen Sekunden Unterbrechung nicht sofort entfernen, Reconnects in dieselbe Session übernehmen. - Aufgaben Extern: Spielern erklären, dass Abbrüche unterwegs (Bus, U-Bahn) durch den Wechsel der Funkzelle entstehen. - Im Graphen: Lücke, dann alles auf einmal (Empfangene Pakete, RTT) - Wo nachsehen: Prüfen, ob die gemeldeten Abbrüche unterwegs (Bus, U-Bahn) auftraten, und im Client-Log die Zeitpunkte von Empfangslücken sowie Wechsel von Netztyp und Signal ansehen - Spricht dafür: Nur unterwegs bleibt der Empfang mehrere hundert ms bis einige Sekunden aus und kommt dann gebündelt, ohne Fortbewegung nicht reproduzierbar - Spricht dagegen: Auch ohne Fortbewegung dasselbe: „Schwaches Mobilfunksignal und Funklöcher“ oder „Häufiger Wechsel 5G↔LTE (Rand der 5G-Abdeckung)“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s)](https://www.itu.int/pub/R-REP-M.2134-2008) · ITU · Anforderung an die Zeit ohne Datenübertragung während des Handovers: 27,5 ms auf derselben Frequenz, 40–60 ms zwischen verschiedenen Frequenzen - [Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020)](https://xyzhang.ucsd.edu/papers/DXu_SIGCOMM20_5Gmeasure.pdf) · ACM · Gemessene Handover-Verzögerung in kommerziellen Netzen: 4G↔4G durchschnittlich 30 ms, zwischen 5G-Zellen (NSA) durchschnittlich 108 ms #### hn-rrc · Verzögerung beim RRC-Zustandswechsel (Energiesparen im Mobilfunk) · Radio state promotion (RRC) Ohne Datenverkehr schaltet das Smartphone die Funkverbindung nach einer Weile in einen Energiesparzustand und muss sie beim nächsten Paket erst wieder hochfahren. Das kostet Zeit. - Warum → Folge → Auf dem Bildschirm: Nach kurzer Pause ohne Datenverkehr schaltet das Smartphone die Funkverbindung in den Energiesparzustand → Für das nächste Paket muss die Verbindung erst wieder hochgefahren werden → Nach einer Pause ist ausgerechnet die erste Aktion auffällig verzögert - Symptome: Input-Lag / Faktoren: Latenz - Wer: Nur ich / Wann: Nach Inaktivität - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Verbindung durch leichte periodische Übertragungen aktiv halten (geht zulasten des Akkus). - Größenordnungen: LTE wechselt meist nach etwa 10 s ohne Datenverkehr in den Energiesparzustand, das Hochfahren dauert einige Dutzend bis einige hundert ms (gemessenes Beispiel: etwa 0,3–0,6 s). Bei 3G mindestens 1 s. - Im Graphen: Nur einzelne Ausreißer (RTT der ersten Anfrage nach einer Pause (mobil)) - Wo nachsehen: RTT im Spiel nach Abstand zur vorherigen Übertragung aufschlüsseln. Auf Mobilgeräten die RTT des ersten Pakets nach über 10 s Pause mit der von unmittelbar folgenden Paketen vergleichen - Spricht dafür: Im Mobilfunknetz kommt nur das erste Paket nach einer Pause mehrere hundert ms zu spät, direkt folgende Pakete sind normal. Im WLAN kein Unterschied - Spricht dagegen: Auch direkt aufeinanderfolgende Pakete verspätet: Signal, Leitung oder Route - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013)](https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p363.pdf) · ACM · Im gemessenen LTE-Netz Timer für den Wechsel in den Energiesparzustand (Tail) 10 s, Median der Verzögerung beim Hochfahren aus dem Energiesparzustand 435 ms (25–75 %: 319–558 ms), bei 3G etwa 1,5–2 s - [Optimize network access](https://developer.android.com/develop/connectivity/network-ops/network-access-optimization) · Android (Google) · Verzögerung beim Funkzustandswechsel und Tail-Zeit hängen von der Funktechnik (3G, LTE, 5G) und den Einstellungen des Providers ab, Beispiel 3G: Niedrigenergie → volle Leistung etwa 1,5 s, Leerlauf → volle Leistung über 2 s - [Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s)](https://www.itu.int/pub/R-REP-M.2134-2008) · ITU · Anforderung an die Control-Plane-Latenz beim Wechsel vom Leerlauf- in den aktiven Zustand: unter 100 ms (ohne Paging und Festnetzabschnitt) #### hn-weak-cell · Schwaches Mobilfunksignal und Funklöcher · Weak cellular signal In Aufzügen, im Untergeschoss oder tief im Gebäudeinneren nehmen Retransmissions zu, die Geschwindigkeit sinkt, und schließlich bricht die Verbindung ab. - Warum → Folge → Auf dem Bildschirm: Bewegung an einen Ort mit schwachem Signal → Mehr Retransmissions auf der Funkstrecke, sinkende Geschwindigkeit, kurze Unterbrechungen → Jitter und Paketverlust verursachen Ruckeln und Teleportieren, am Ende Verbindungsabbruch - Symptome: Ruckeln, Teleportieren, Verbindungsabbruch / Faktoren: Jitter, Paketverlust - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Reconnect-Ablauf verbessern, Netzwerkqualität anzeigen. - Aufgaben Extern: Spielern erklären, dass das Problem an Orten mit schwachem Signal entsteht (Aufzug, Untergeschoss, Gebäudeinneres). - Im Graphen: Nur einzelne Ausreißer (RTT und Paketverlust (pro Mobilfunk-Spieler)) - Wo nachsehen: Ort zum Zeitpunkt der gemeldeten Abbrüche (Aufzug, Untergeschoss, Gebäudeinneres) und die Signalanzeige des Smartphones prüfen, dieselbe Aktion an einem Ort mit gutem Signal wiederholen und vergleichen - Spricht dafür: Nur an Orten mit schwachem Signal steigen RTT und Paketverlust, und die Verbindung bricht ab. An einem Ort mit gutem Signal verschwindet es - Spricht dagegen: Dasselbe trotz guten Signals: Providerstrecke oder Serverseite - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013)](https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p363.pdf) · ACM · LTE verbirgt Verluste auf der Funkstrecke durch Retransmissions auf PHY- und MAC-Schicht, die verfügbare Bandbreite schwankt je nach Signalstärke und anderen Faktoren im Sekundentakt stark #### hn-5g-flip · Häufiger Wechsel 5G↔LTE (Rand der 5G-Abdeckung) · 5G NSA / LTE switching In Gebäuden mit schwachem 5G-Signal oder am Rand der 5G-Abdeckung wechselt das Smartphone häufig zwischen 5G und LTE. Bei jedem Wechsel schlägt der Ping aus, oder die Verbindung setzt kurz aus. - Warum → Folge → Auf dem Bildschirm: Aufenthalt an einem Ort mit schwankendem 5G-Signal (im Gebäude, am Rand der 5G-Abdeckung) → Smartphone wechselt ständig zwischen 5G und LTE, bei jedem Wechsel entsteht eine kurze Lücke → Ping schlägt auch ohne Bewegung regellos aus, gelegentlich Freeze oder Teleportieren - Symptome: Ruckeln, Teleportieren, Freeze / Faktoren: Jitter, Paketverlust - Wer: Nur ich / Wann: Gelegentlich, zufällig, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Bei steigendem Jitter den Interpolationspuffer automatisch verlängern, in den Logs, die bei Lag entstehen, Wechsel des Netztyps (5G, LTE) mitschreiben, um die Ursache unterscheiden zu können. - Aufgaben Extern: Spielern empfehlen, zum Vergleich in den Einstellungen einen LTE-bevorzugten Modus zu wählen, WLAN-Nutzung empfehlen. - Größenordnungen: Einige Dutzend bis einige hundert ms pro Wechsel. 5G in Südkorea läuft größtenteils im Verbund mit LTE (NSA), daher bricht der 5G-Teil leicht weg und verbindet sich wieder. - Im Graphen: Vereinzelte Spitzen ohne Muster (RTT, Wechsel des Netztyps (5G, LTE)) - Wo nachsehen: Smartphone auf LTE-bevorzugt umstellen und am selben Ort vergleichen. Zeichnet der Client Änderungen der Netzanzeige in TelephonyDisplayInfo von Android (etwa OVERRIDE_NETWORK_TYPE_NR_NSA) zusammen mit der RTT auf, ist der Befund eindeutiger - Spricht dafür: Die Zeitpunkte der RTT-Ausschläge fallen mit dem Wechsel der Anzeige 5G↔LTE zusammen, im LTE-bevorzugten Modus verschwinden die Ausschläge - Spricht dagegen: Ausschläge ohne Wechsel der Netzanzeige: „Schwaches Mobilfunksignal und Funklöcher“ oder Leitung - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020)](https://xyzhang.ucsd.edu/papers/DXu_SIGCOMM20_5Gmeasure.pdf) · ACM · NSA-5G überlässt die Steuerung LTE, beim Wechsel der 5G-Zelle wird 5G aufgegeben und über LTE neu verbunden: durchschnittlich 108 ms (4G→5G 80 ms), direkt nach Wechseln mit 5G-Beteiligung sinkt der TCP-Durchsatz um 73–83 % - [5G 통신서비스 품질평가 결과 발표](https://www.korea.kr/briefing/policyBriefingView.do?newsId=156404679) · 과학기술정보통신부 · Laut einer Veröffentlichung von 2020 wird 5G in Südkorea im NSA-Modus angeboten, der Umstieg auf SA ist in Planung - [TelephonyDisplayInfo](https://developer.android.com/reference/android/telephony/TelephonyDisplayInfo) · Android (Google) · OVERRIDE_NETWORK_TYPE_NR_NSA: Netzanzeige, wenn das Gerät mit LTE verbunden ist und Dual Connectivity (EN-DC) mit 5G (NR) möglich oder aktiv ist #### hn-captive · Einschränkungen in öffentlichen WLANs und Firmennetzen · Captive portal, restrictive network Die Login-Seite im Café-WLAN oder die Firewall der Firma blockiert die Spielverbindung. - Warum → Folge → Auf dem Bildschirm: Login-Seite noch nicht bestätigt, oder die Firewall sperrt Spiel-Ports bzw. UDP → Verbindungsversuche werden komplett blockiert oder kommen nur teilweise durch → Verbindung scheitert ganz, oder der Login klappt, aber das Betreten der Spielwelt schlägt fehl - Symptome: Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Nur ich / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: bei Blockade den Grund anzeigen (Login-Seite noch nicht bestätigt, UDP gesperrt usw.), bei gesperrtem UDP automatisch auf einen Ausweichweg umschalten. Server: Ausweichweg wie TCP 443 anbieten. - Aufgaben Extern: Spielern empfehlen, sich in öffentlichen WLANs zuerst auf der Login-Seite anzumelden und an gesperrten Orten wie Firmennetzen ein anderes Netz zu nutzen. - Im Graphen: Nur einzelne Ausreißer (Verbindungsfehler (pro Netz)) - Wo nachsehen: Betroffene Spieler auf ein anderes Netz wie mobile Daten wechseln und erneut verbinden lassen, im Verbindungslog des Servers prüfen, ob das erste UDP-Paket ankam und ob die Verbindung über den Ausweichweg TCP 443 klappt - Spricht dafür: Fehler nur in bestimmten WLANs (Café, Firma), in anderen Netzen klappt es sofort. Login-Seite noch nicht bestätigt, oder nur UDP erreicht den Server nicht - Spricht dagegen: Fehler in jedem Netz: Konto, Server oder „DNS-Störung oder -Verzögerung“. Fehler bei einem ganzen Land oder Provider: „UDP-Beschränkung und Paketinspektion auf Landes- oder Providerebene“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [RFC 8952: Captive Portal Architecture](https://www.rfc-editor.org/rfc/rfc8952) · IETF · Captive Portal: Netz, das den Zugang einschränkt, bis Bedingungen wie die Zustimmung zu Nutzungsbedingungen oder eine Authentifizierung erfüllt sind - [RFC 9308: Applicability of the QUIC Transport Protocol](https://www.rfc-editor.org/rfc/rfc9308) · IETF · Laut Messstudien sperren 3–5 % der Netze UDP vollständig, daher brauchen UDP-basierte Apps einen Ausweichweg über TCP (TLS) ### L4 Internetleitung (14 Ursachen) #### isp-distance · Signallaufzeit (physische Entfernung) · Propagation delay Selbst Licht legt in Glasfaser nur etwa 200.000 km pro Sekunde zurück. Ein weit entfernter Server bleibt langsam, so gut er auch ist. - Warum → Folge → Auf dem Bildschirm: Server steht weit entfernt (Auslandsserver, anderer Kontinent) → Umlaufzeit wächst mit der Entfernung (mindestens 10 ms pro 1.000 km) → Gleichbleibender Input-Lag bei jeder Aktion, Nachteil bei der Trefferabfrage - Symptome: Input-Lag / Faktoren: Latenz - Wer: Bestimmte Region oder Provider / Wann: Immer - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Physikalische Grenzen lassen sich per Code nicht beheben, nur abmildern: Regionsauswahl anbieten, damit Spieler einen nahen Server wählen, Nachteile bei der Trefferabfrage per Lag-Compensation (Zurückspulen) verringern. - Aufgaben Infrastrukturteam: Server/OS: in Regionen mit vielen Spielern eigene regionale Server betreiben. Netzwerk: Zugangspunkte (Edge) nahe bei den Spielern aufbauen, Leitungen und Routen mit wenig Umwegen wählen. - Größenordnungen: Seoul–Tokio etwa 30 ms, Seoul–Singapur etwa 75 ms, Seoul–US-Westküste etwa 140 ms, Seoul–Europa etwa 230–270 ms (hin und zurück, über reale Routen). Auf der direkten Linie nach Europa liegen kaum große Kabel. Der Traffic läuft über Südostasien und Suez oder über die USA, daher liegt der Wert weit über dem, was die Entfernung allein ergibt. - Im Graphen: Von Anfang an dauerhaft hoch (RTT (nach Land und Region)) - Wo nachsehen: Verbindungs-IPs einem Land zuordnen und die RTT-Verteilung pro Land auswerten, dann von einer VM in der Cloud-Region vor Ort oder von RIPE-Atlas-Probes (nach Land und ASN ausgewählt) per ping und traceroute zum Server messen - Spricht dafür: RTT aus fernen Ländern ist unabhängig von der Tageszeit dauerhaft hoch und liegt nahe an der aus der Entfernung berechneten Mindestlatenz (10 ms hin und zurück pro 1.000 km) und an öffentlichen Latenzstatistiken - Spricht dagegen: Deutlich höher, als die Entfernung erklärt: „Umweg-Routing“. Steigt nur abends: „Überlast am Peering-Punkt zur Stoßzeit“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: riot-direct-2015 - Quellen: - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Planungswert für die Ausbreitungsverzögerung in Glasfaser: 5 µs/km (etwa 200.000 km/s, 10 ms hin und zurück pro 1.000 km) - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Gemessene Median-RTT ab Seoul (Korea Central): Tokio 30 ms, Singapur 68 ms, US-Westküste 124–136 ms, Europa 234–244 ms - [AAE-1 & SMW5 cable cuts impact millions of users across multiple countries](https://blog.cloudflare.com/aae-1-smw5-cable-cuts/) · Cloudflare · Traffic zwischen Europa und Asien läuft meist über Unterseekabel durch Ägypten (Suez) - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen #### isp-satellite · Satelliteninternet (LEO und geostationär) · Satellite internet (LEO, GEO) Beim Satelliteninternet muss das Funksignal durch den Weltraum hin und zurück. Bei geostationären Satelliten dauert allein der Round Trip über 0,5 s. LEO-Satelliten wie Starlink sind normalerweise schnell, doch im Moment der Routen-Neuzuweisung schwankt die Latenz, und die Verbindung kann kurz abreißen. - Warum → Folge → Auf dem Bildschirm: Verbindung zu Hause, auf dem Schiff oder im Flugzeug über geostationäres oder LEO-Satelliteninternet oder über satellitengestütztes Bord-WLAN → Geostationär: rund 36.000 km Höhe, schon der Weg selbst ist lang. LEO: Route zwischen Terminal, Satellit und Bodenstation wird in kurzen Abständen neu zugewiesen, dabei kurzzeitig höhere Latenz und Paketverlust → Geostationär: starker Input-Lag bei jeder Aktion. LEO: meist unauffällig, aber in festen Abständen Ruckeln und Teleportieren - Symptome: Input-Lag, Ruckeln, Teleportieren / Faktoren: Latenz, Jitter, Paketverlust - Wer: Nur ich, Gleicher Haushalt, Bestimmte Region oder Provider / Wann: Immer, In festen Abständen - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Interpolationspuffer je nach Jitter automatisch verlängern, Eingaben redundant senden, damit kurzer Paketverlust verkraftet wird, Verbindungsqualität anzeigen. Server: beim Festlegen von Zeitfenstern und Grenzen der Lag-Compensation die Latenz von Satellitenverbindungen berücksichtigen, Timeouts so wählen, dass eine Lücke von etwa 1 s nicht sofort zum Rauswurf führt. - Aufgaben Extern: Spieler darauf hinweisen, dass Satelliteninternet eine hohe oder periodisch ausschlagende Latenz haben kann, für kompetitive Inhalte nach Möglichkeit einen terrestrischen Festnetzanschluss empfehlen. - Größenordnungen: Bei geostationären Satelliten (36.000 km Höhe) braucht das Signal allein für die Strecke durch den Weltraum 260 ms pro Richtung, hin und zurück also über 520 ms (ITU-T G.114). Für das LEO-System Starlink nennen offizielle Angaben (Mittelwerte über 15 s) zur Stoßzeit in den USA einen Median von 33 ms, und selbst das schlechteste 1 % (p99) liegt unter 65 ms (2024). In Messstudien änderte sich die Latenz alle 15 s bei der Routen-Neuzuweisung, und es gab kurze Aussetzer unter 1 s. Eine Messung von Bord-Internet aus dem Jahr 2018 ergab für Satellitensysteme eine durchschnittliche Umlaufzeit von 750 ms. - Im Graphen: Nur einzelne Ausreißer (RTT und Jitter (nach ASN des Satelliteninternet-Anbieters)) - Wo nachsehen: Prüfen, ob die ASN der Verbindungs-IP zu einem Satelliteninternet-Anbieter gehört, und RTT-Verteilung und Zeitverlauf für dessen Spieler getrennt darstellen. Von RIPE-Atlas-Probes in dieser ASN einige Minuten am Stück per ping zum Server messen oder den Spieler ping laufen lassen und die Abstände der Ausschläge messen lassen - Spricht dafür: Bei geostationären Anbietern liegt die RTT stets über 500 ms. Bei LEO-Anbietern liegt sie normalerweise im zweistelligen Millisekundenbereich, springt aber etwa alle 15 s auf einen anderen Wert, oder die Verbindung reißt kurz ab - Spricht dagegen: Kein Satellitenanbieter, RTT trotzdem dauerhaft hoch: „Signallaufzeit (physische Entfernung)“ oder „Umweg-Routing“. Unregelmäßige Ausschläge: eher WLAN oder Mobilfunksignal - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Bei LEO-Satelliten ist der Weg zum Satelliten kurz (bei Starlink 1,8–3,6 ms pro Teilstrecke), sodass die normale Latenz der einer terrestrischen Leitung ähneln kann. Liegt jedoch der Übergabepunkt von der Bodenstation ins Internet (PoP) weit vom Spielserver entfernt, verlängert sich die Route entsprechend. Läuft der Traffic über Laserlinks zwischen Satelliten, kommt weitere Latenz hinzu. Messstudien führen die alle 15 s wiederkehrende Schwankung auf eine Routen-Neuzuweisung zurück, die weltweit zum selben Zeitpunkt stattfindet und mit dem Wechsel zwischen Satelliten nichts zu tun hat. Beim Bord-WLAN hängt die Latenz stark von der Technik ab (Satellit oder Funkmasten am Boden). Nutzt das System geostationäre Satelliten, entstehen die oben genannten langen Umlaufzeiten. - Quellen: - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Planungswerte für die einfache Signallaufzeit über Satellit: 400 km Höhe 12 ms, 14.000 km 110 ms, 36.000 km (geostationär) 260 ms - [Improving Starlink’s Latency](https://starlink.com/public-files/StarlinkLatency.pdf) · Starlink · Median zur Stoßzeit in den USA 48,5 ms → 33 ms, langsamstes 1 % (p99) über 150 ms → unter 65 ms (2024), Signallaufzeit pro Satellitenteilstrecke 1,8–3,6 ms, Umwege über Laserlinks erhöhen die Latenz, auch die Entfernung von der Bodenstation zum Internet-Übergabepunkt (PoP) trägt zur Latenz bei - [A Multifaceted Look at Starlink Performance (WWW 2024)](https://www.nitindermohan.com/documents/2024/pubs/starlinkWWW2024.pdf) · ACM · Starlink weist Routen alle 15 s weltweit zum selben Zeitpunkt neu zu. An diesen Grenzen schwanken Latenz und Durchsatz, und es gibt kurze Aussetzer unter 1 s (nicht verursacht durch den Wechsel zwischen Satelliten), Latenz auf der Strecke Terminal ↔ Satellit ↔ Bodenstation etwa 40 ms - [Mile High WiFi: A First Look at In-Flight Internet Connectivity (WWW 2018)](https://aqualab.cs.northwestern.edu/publication/2018/jrula-www18/) · ACM · 45 Stunden Messung von Bord-Internet: mittlere Umlaufzeit 200 ms bei Systemen mit Funkmasten am Boden, 750 ms bei Satellitensystemen, Median der Verlustrate bei Satellit 7 % - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen #### isp-routing · Umweg-Routing · Suboptimal routing Wegen der Verbindungsverträge zwischen Providern laufen Daten selbst zu nahen Servern über weit entfernte Umwege. - Warum → Folge → Auf dem Bildschirm: Eigener Provider und Provider des Servers sind nicht direkt verbunden → Route führt über andere Länder oder Städte, mehr Strecke und mehr Geräte → Nur Kunden eines bestimmten Providers haben auffällig hohen Ping - Symptome: Input-Lag / Faktoren: Latenz - Wer: Bestimmte Region oder Provider / Wann: Immer - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Extern (Extern) - Aufgaben Infrastrukturteam: An mehrere Provider anbinden (Multihoming), Ping pro Provider überwachen und Provider mit Umwegen finden, Routenanpassung mit dem Provider abstimmen. - Aufgaben Extern: Betroffenen Provider um Anpassung der Route bitten. - Größenordnungen: Selbst innerhalb eines Landes kann sich der Ping je nach Route um das Zwei- bis Dreifache unterscheiden. - Im Graphen: Von Anfang an dauerhaft hoch (RTT (nach Provider und ASN)) - Wo nachsehen: RTT pro Provider (ASN) vergleichen und per traceroute oder mtr von RIPE-Atlas-Probes des langsamen Providers oder von Spielern prüfen, über welche Länder und Städte die Route läuft. IPv4 und IPv6 getrennt messen (mtr -4, -6) - Spricht dafür: In derselben Region ist nur ein bestimmter Provider dauerhaft hoch, und die Route führt über andere Länder oder entfernte Städte. Oder nur eine Adressfamilie (IPv4 oder IPv6) ist hoch - Spricht dagegen: Alle Provider ähnlich hoch: „Signallaufzeit (physische Entfernung)“. Nur abends hoch: „Überlast am Peering-Punkt zur Stoßzeit“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: IPv4 und IPv6 werden getrennt geroutet. Zum selben Server kann deshalb nur eines der beiden einen weiten Umweg nehmen und langsam sein (APNIC-Messung 2016: Innerhalb eines Providers zeigten sich getrennte Nutzergruppen, bei denen IPv6 um 15 ms, 25 ms oder 75 ms langsamer war als IPv4). Apps, die Happy Eyeballs (RFC 8305) umsetzen, nutzen von IPv6 und IPv4 die Verbindung, die zuerst zustande kommt. Sie versuchen zuerst IPv6, und steht die IPv6-Verbindung innerhalb des empfohlenen Werts von 250 ms, versuchen sie IPv4 gar nicht erst. Deshalb landet die Verbindung leicht auf dem IPv6-Pfad, auch wenn er etwas langsamer ist. Ist der Ping nur bei einem bestimmten Provider hoch, lohnt es sich, IPv4 und IPv6 getrennt zu messen. - Reale Fälle: riot-direct-2015 - Quellen: - [Quantifying the Causes of Path Inflation (SIGCOMM 2003)](https://conferences.sigcomm.org/sigcomm/2003/papers/p113-spring.pdf) · ACM · Analyse von 65 ISPs: Peering-Richtlinien zwischen ISPs und Interdomain-Routing verlängern Routen deutlich - [The Internet at the Speed of Light (HotNets 2014)](https://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final111.pdf) · ACM · Reale Router-Pfade sind im Median etwa 1,5-mal so lang wie eine direkte Glasfaserverbindung auf der Luftlinie, teils laufen Pakete zwischen zwei nahen Orten über die andere Seite der Erde (Hairpinning) - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Mit -4 bzw. -6 wird die Route nur über IPv4 bzw. nur über IPv6 gemessen - [RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency](https://www.rfc-editor.org/rfc/rfc8305) · IETF · Einzelne Adressen oder Adressfamilien (IPv4, IPv6) können je nach Netz blockiert, gestört oder langsam sein, IPv6 wird zuerst versucht, bis zum nächsten Verbindungsversuch werden empfohlen 250 ms gewartet - [IPv6 Performance – Revisited](https://blog.apnic.net/2016/08/22/ipv6-performance-revisited/) · APNIC · Vergleich der IPv6- und IPv4-Umlaufzeiten derselben Dual-Stack-Nutzer: Manche Zugangsnetze behandeln IPv6-Pakete völlig anders, sodass innerhalb eines Providers Gruppen auftreten, bei denen IPv6 um 15 ms, 25 ms oder 75 ms langsamer ist #### isp-peak · Überlast am Peering-Punkt zur Stoßzeit · Peak-hour congestion at peering Abends zwischen etwa 21 und 23 Uhr schnellt der Video-Traffic in die Höhe, und die Übergänge zwischen Providern (Peering) sind dann leicht überlastet. - Warum → Folge → Auf dem Bildschirm: Abends ballen sich Streaming und Downloads → Warteschlangen und Paketverlust am Peering-Punkt → Nur abends Ruckeln und Teleportieren bei Kunden eines bestimmten Providers - Symptome: Ruckeln, Teleportieren, Rubberbanding / Faktoren: Jitter, Paketverlust, Latenz - Wer: Bestimmte Region oder Provider / Wann: Abendliche Stoßzeit - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Extern (Extern) - Aufgaben Infrastrukturteam: Direktverbindungen zum betroffenen Provider ausbauen, überlastete Routen umgehen, Paketverlust und Ping am Abend pro Provider überwachen. - Aufgaben Extern: Betroffenen Provider um Kapazitätserweiterung am Peering-Punkt bitten. - Im Graphen: Nur zu bestimmten Tageszeiten hoch (RTT und Paketverlust (nach Provider)) - Wo nachsehen: RTT und Paketverlust pro Provider (ASN) nach Tageszeit darstellen, von RIPE-Atlas-Probes dieses Providers oder von Spielern je einen mtr-Lauf am Abend und am Tag einholen und prüfen, ab welchem Abschnitt der Verlust beginnt - Spricht dafür: Nur bei einem bestimmten Provider steigen RTT und Paketverlust jeden Abend gegen 21–23 Uhr, und im mtr setzen sich Verlust und Verzögerung vom Übergang zwischen den Providern bis zum Ziel fort - Spricht dagegen: Alle Provider steigen gemeinsam: eigene Leitung oder eigene Server. Nur ein Haushalt abends schlecht: „Überlasteter WLAN-Kanal“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Inferring Persistent Interdomain Congestion (SIGCOMM 2018)](https://www.caida.org/catalog/papers/2018_inferring_persistent_interdomain_congestion/inferring_persistent_interdomain_congestion.pdf) · ACM · An einem Teil der Übergänge zwischen Providern wiederkehrende Überlast, bei der die Latenz täglich zur Stoßzeit steigt, in den Überlastzeiten steigt auch die Verlustrate - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen #### isp-cable · Störung an Unterseekabel oder Auslandsleitung · Submarine cable fault Reißt ein Unterseekabel, läuft der Traffic bis zur Reparatur wochenlang (im schlimmsten Fall monatelang) über weite Umweg-Routen, und die verbleibenden Leitungen sind überlastet. - Warum → Folge → Auf dem Bildschirm: Kabelbruch oder Geräteausfall → Traffic drängt sich auf weite Umweg-Routen und die verbleibenden Leitungen → Sprunghaft steigender Ping und Paketverlust bei Spielern aus dem Ausland, über Tage bis Wochen - Symptome: Input-Lag, Teleportieren / Faktoren: Latenz, Paketverlust - Wer: Bestimmte Region oder Provider / Wann: Immer - Hauptzuständig: Extern (Extern) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Leitungen über andere Routen sichern, bei einer Störung den Traffic auf diese Routen verlagern. - Aufgaben Extern: Spieler im Ausland über Ursache und voraussichtliche Wiederherstellung informieren, beim Leitungsbetreiber den Reparaturzeitplan erfragen. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (RTT der Auslandsverbindungen (nach Land)) - Wo nachsehen: Im Graphen von RTT und Paketverlust pro Land den Zeitpunkt des Anstiegs suchen, mit den Störungsübersichten von Cloudflare Radar und den Meldungen der Unterseekabel-Betreiber abgleichen, per traceroute prüfen, ob die Route über einen anderen Kontinent läuft - Spricht dafür: Ab einem bestimmten Zeitpunkt steigt die RTT für eine bestimmte Auslandsregion um eine Stufe und bleibt Tage bis Wochen dort, zur selben Zeit gibt es Meldungen über einen Kabelausfall. Die Route wechselt auf einen ungewohnten, weiten Umweg - Spricht dagegen: Innerhalb weniger Tage wieder normal und keine Störungsmeldung: „BGP-Routenwechsel und Konvergenz“ oder ein Abschnitt beim Provider - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [AAE-1 & SMW5 cable cuts impact millions of users across multiple countries](https://blog.cloudflare.com/aae-1-smw5-cable-cuts/) · Cloudflare · Die Reparatur eines Unterseekabels erfordert ein Reparaturschiff und dauert meist Tage bis Wochen (im Fall Tonga 38 Tage), bei einem Kabelbruch steigen Latenz und Paketverlust zwischen Europa und Asien - [Q2 2024 Internet disruption summary](https://blog.cloudflare.com/q2-2024-internet-disruption-summary/) · Cloudflare · Die im Februar 2024 beschädigten Kabel im Roten Meer waren im Juli noch in Reparatur (Konfliktgebiet), die Brüche von EASSy und Seacom im Mai waren nach 19 Tagen behoben - [Q1 2024 Internet disruption summary](https://blog.cloudflare.com/q1-2024-internet-disruption-summary/) · Cloudflare · Die Kabelbrüche vor Westafrika (14. März) waren nach 3–6 Wochen behoben, in der Zwischenzeit wurde der Traffic auf andere Kabel verlagert #### isp-bgp · BGP-Routenwechsel und Konvergenz · Route change / BGP convergence Ändern sich Routing-Informationen im Internet, gehen Pakete verloren, bis die Routen wieder konvergiert sind. Das dauert einige bis einige Dutzend Sekunden (selten einige Minuten). - Warum → Folge → Auf dem Bildschirm: Routing-Informationen in einem Providerabschnitt ändern sich → Für einige bis einige Dutzend Sekunden gehen Pakete verloren, oder der Traffic wechselt auf eine neue Route → Plötzlich einige Sekunden Freeze, danach ein anderer Ping-Wert (z. B. 40 → 70 ms) - Symptome: Freeze, Teleportieren / Faktoren: Paketverlust, Latenz - Wer: Bestimmte Region oder Provider / Wann: Gelegentlich, zufällig - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Extern (Extern) - Aufgaben Entwicklungsteam: Timeouts so wählen, dass kurze Aussetzer verkraftet werden (eine Verbindung, die einige Sekunden stillsteht, nicht sofort trennen). - Aufgaben Infrastrukturteam: Routen überwachen (Änderungen von Route und Ping für die eigenen IP-Bereiche), Ausfälle der eigenen Leitungen per BFD innerhalb von 1 s erkennen und umschalten (Standard-Hold-Time von BGP: 90–180 s), Traffic auf eine andere Leitung verlagern, wenn die Route auf einen weiten Umweg gewechselt ist und nicht zurückkehrt. - Aufgaben Extern: Bei Providerabschnitten mit häufigen Routenwechseln den Provider um Klärung der Ursache bitten. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (RTT, traceroute-Pfad) - Wo nachsehen: Routen per traceroute und mtr vor und nach dem Zeitpunkt der RTT-Änderung vergleichen, mit RIPEstat BGPlay den Verlauf der BGP-Routenänderungen für die eigenen Adressbereiche (Prefix) ansehen - Spricht dafür: Nach einem Freeze von einigen Sekunden springt die RTT auf einen anderen Wert, zur selben Zeit gibt es BGP-Updates und Änderungen des AS-Pfads - Spricht dagegen: Keine Routenänderungen protokolliert, Anstieg nur abends: „Überlast am Peering-Punkt zur Stoßzeit“. Nur einzelne Verbindungen schlecht: „Einzelner defekter ECMP-Pfad“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: cloudflare-2020, meta-2021, cloudflare-dns-2025 - Quellen: - [RFC 4271: A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271) · IETF · Empfohlener Standardwert der BGP-Hold-Time: 90 s (kommt in dieser Zeit keine Nachricht vom Nachbarn, wird die Session beendet) - [BGP updates in 2024](https://blog.apnic.net/2025/01/07/bgp-updates-in-2024/) · APNIC · Bis eine instabil gewordene Route wieder stabil ist, vergehen im Tagesmittel 25–35 s (IPv4) bzw. 40–50 s (IPv6) - [Delayed Internet Routing Convergence (SIGCOMM 2000)](https://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf) · ACM · Nach einem Routenausfall dauert die Konvergenz bis zu einigen Minuten, in dieser Zeit steigen Paketverlust und Latenz (Messung aus dem Jahr 2000) - [BGPlay (RIPEstat Data API)](https://stat.ripe.net/docs/data-api/api-endpoints/bgplay) · RIPE NCC · Zeigt für einen Adressbereich (Prefix) die BGP-Routen zum Startzeitpunkt, die im Zeitraum beobachteten BGP-Updates und die AS auf dem Pfad #### isp-ecmp · Einzelner defekter ECMP-Pfad · ECMP / link bundle member fault Provider und Rechenzentren halten mehrere Pfade zum selben Ziel vor und legen für jede Verbindung einen davon fest. Fällt nur ein Pfad aus, laggt es dauerhaft nur für die Spieler, die diesem Pfad zugewiesen sind. - Warum → Folge → Auf dem Bildschirm: In einem Abschnitt mit gebündelten Leitungen ist eine Leitung oder ein Gerät defekt oder überlastet → Pfad wird über die Kombination aus Adressen und Ports (Hash) bestimmt, nur die diesem Pfad zugewiesenen Verbindungen haben Paketverlust und Latenz → Gleiche Region, gleicher Provider, aber nur ein Teil der Spieler teleportiert ständig. Nach einem Reconnect ist es manchmal wieder gut - Symptome: Teleportieren, Rubberbanding, Ruckeln / Faktoren: Paketverlust, Jitter - Wer: Nur ich, Bestimmte Region oder Provider / Wann: Immer - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Extern (Extern) - Aufgaben Entwicklungsteam: Verlust- und Retransmission-Statistik pro Verbindung protokollieren, damit sich IP, Port und Zeitpunkt der Betroffenen ermitteln lassen (bei TCP aus der Retransmission-Zahl in TCP_INFO, bei UDP aus fehlenden Paket-Sequenznummern). - Aufgaben Infrastrukturteam: IP, Port und Zeitpunkt der Betroffenen sammeln und an Provider oder Rechenzentrum weitergeben, Paketverlust pro Pfad überwachen, Pfade mit demselben Protokoll und Port wie das Spiel messen (mtr --tcp oder --udp mit --port), liegt der Pfad auf eigenen Geräten, die defekte Leitung oder das defekte Gerät aus dem Bündel nehmen. - Aufgaben Extern: Provider um Prüfung und Austausch des defekten Pfads bitten, Spielern als vorläufigen Workaround einen Reconnect empfehlen (wenn sich der Port dabei ändert). - Größenordnungen: Bei 4 Pfaden ist nur etwa ein Viertel der Spieler betroffen. Ping-Messungen können über einen anderen Pfad als das Spiel laufen und dann unauffällig aussehen. - Im Graphen: Nur einzelne Ausreißer (Paketverlust und Retransmissions pro Verbindung (nach IP und Port)) - Wo nachsehen: Paketverlust und Retransmissions pro Verbindung nach Quell-IP und Quellport aufschlüsseln, mtr per UDP (-u) auf den Spielport (-P) mit festem Quellport (-L) messen und mit wechselnden Quellports mehrmals wiederholen. Mit -P ohne -L ändert sich der Quellport bei jeder Anfrage, und mehrere Pfade vermischen sich - Spricht dafür: Innerhalb derselben Region und desselben Providers zeigt nur eine bestimmte Kombination von Quellports (oder Adressen) dauerhaft Paketverlust, nach einem Reconnect mit neuem Port ist alles in Ordnung - Spricht dagegen: Auch mit anderen Ports alles schlecht: Überlast oder Störung im ganzen Abschnitt - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Damit die Pakete einer Verbindung nicht durcheinandergeraten, legen die Geräte jede Verbindung auf einen festen Pfad (ECMP, LAG). Den Pfad bestimmt ein Wert, der aus Adressen und Ports berechnet wird, je nach Gerätekonfiguration auch nur aus den Adressen. Wo nur die Adressen zählen, bleibt der Pfad auch nach einem Reconnect gleich, und es wird nicht besser. Kommen also Meldungen wie „Ping ist okay, aber nur das Spiel laggt“ und „Nach dem Reconnect war es besser“ zusammen, ist diese Ursache verdächtig. - Quellen: - [RFC 7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks](https://www.rfc-editor.org/rfc/rfc7424) · IETF · LAG und ECMP legen per Hash über Header-Felder für jeden Flow einen Link fest und erhalten so die Paketreihenfolge (Zuordnung Flow → Link: viele auf einen) - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Wonach Flows unterschieden werden, hängt von der Implementierung ab (nur Zieladresse, Adresspaar, auch Ports), bei Multipath sind Ergebnisse von ping und traceroute wenig verlässlich - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Optionen -u (UDP), -P (Zielport), -L (UDP-Quellport), nur mit -P wird die laufende Nummer der Anfrage in den Quellport eingerechnet, sodass er sich bei jeder Anfrage ändert #### isp-shaping · Drosselung und Traffic-Management durch den Provider · Traffic shaping, data caps Ist das Datenvolumen aufgebraucht oder verwaltet der Tarif bestimmten Datenverkehr gezielt, werden Pakete verzögert oder verworfen. - Warum → Folge → Auf dem Bildschirm: Drosselung nach aufgebrauchtem Datenvolumen oder Beschränkung bestimmten Datenverkehrs → Pakete warten oder werden verworfen → Lag ab einem bestimmten Verbrauch, besonders mobil - Symptome: Input-Lag, Teleportieren / Faktoren: Latenz, Paketverlust - Wer: Nur ich, Bestimmte Region oder Provider / Wann: Immer, Abendliche Stoßzeit - Hauptzuständig: Extern (Extern) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Spiel-Traffic reduzieren (Kompression, nur Nötiges senden). - Aufgaben Infrastrukturteam: Wird Spiel-Traffic nur bei einem bestimmten Provider verzögert oder verworfen, Belege sammeln und an den Provider eskalieren. - Aufgaben Extern: Spieler bitten zu prüfen, ob das Datenvolumen aufgebraucht oder gedrosselt ist und ob andere Apps auf demselben Smartphone Daten nutzen, beim Provider anfragen, ob Spiel-Traffic beschränkt wird. - Größenordnungen: In Korea drosseln Mobilfunktarife nach aufgebrauchtem Datenvolumen meist auf 1–5 Mbps, günstige Tarife auf einige hundert kbps. Das Spiel selbst braucht wenig Bandbreite. Nutzen aber andere Apps auf demselben Smartphone die Verbindung, staut sich vor dem Drosselgerät eine Warteschlange. - Im Graphen: Plateau am Limit (Durchsatz, RTT) - Wo nachsehen: Spieler in der App des Providers Restvolumen und Drosselung prüfen lassen und per Speedtest die Höchstgeschwindigkeit messen. Serverseitig Paketverlust und RTT pro Provider vergleichen - Spricht dafür: Durchsatz bleibt an einem festen Wert wie 1–5 Mbps oder einigen hundert kbps hängen, ab dann steigen RTT und Paketverlust, sobald andere Apps auf demselben Smartphone Daten nutzen. Nach Aufladen des Datenvolumens oder Wechsel ins WLAN verschwindet es - Spricht dagegen: Keine Drosselung, aber nur ein bestimmter Provider schlecht: „Überlast am Peering-Punkt zur Stoßzeit“ oder „Umweg-Routing“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시](https://news.sktelecom.com/180213) · SK텔레콤 · Beispiele für die Drosselung von 5G-Tarifen nach Verbrauch des Inklusivvolumens: höchstens 400 kbps, 1 Mbps, 3 Mbps - [SKT, 요금제 개편](https://news.sktelecom.com/225487) · SK텔레콤 · Auch nach Verbrauch des Inklusivvolumens weitere Nutzung mit höchstens 400 kbps (Option „Sorgenfreie Daten für alle“) #### isp-udp-block · UDP-Beschränkung und Paketinspektion auf Landes- oder Providerebene · UDP blocking, throttling and inspection by networks Manche Netze sperren bestimmte UDP-Adressen oder -Ports oder drosseln UDP, und Geräte zur Paketinspektion filtern Protokolle heraus, die sie nicht erkennen. Spiele, die über UDP kommunizieren, kommen in solchen Netzen nicht durch oder verlieren oft die Verbindung. - Warum → Folge → Auf dem Bildschirm: Verbindung aus einem Providernetz, das UDP drosselt, oder aus einem Netz mit Geräten zur Paketinspektion (Zensur) auf Landes- oder Providerebene → Bestimmte UDP-Adressen oder -Ports gesperrt, UDP zur Stoßzeit gedrosselt, Ports oder Protokolle außerhalb einer Allowlist ausgefiltert oder nur die ersten Pakete durchgelassen und dann gesperrt → Nur Spieler aus bestimmten Ländern oder bei bestimmten Providern: Kein Login / Endlos-Laden, Verbindungsabbruch kurz nach dem Verbinden, zur Stoßzeit Teleportieren durch Paketverlust - Symptome: Kein Login / Endlos-Laden, Verbindungsabbruch, Teleportieren / Faktoren: Paketverlust - Wer: Bestimmte Region oder Provider / Wann: Direkt nach Login oder Wartung, Immer, Abendliche Stoßzeit - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Client: steht die UDP-Verbindung nicht innerhalb weniger Sekunden, automatisch auf einen Fallback über TCP/TLS 443 umschalten, auch Fälle erkennen, in denen die Verbindung erst steht und kurz darauf abbricht, und dann über den Fallback neu versuchen, protokollieren, über welchen Weg die Verbindung zustande kam. Server: dasselbe Spielprotokoll auch über TCP 443 (TLS) annehmen, Timeouts anpassen, da der Fallback mehr Latenz haben kann. - Aufgaben Infrastrukturteam: Vor dem Start in einem neuen Land in den dortigen Providernetzen messen, ob UDP durchkommt und wie hoch der Verlust zur Stoßzeit ist, Relays oder Gateways für den Fallback über TCP 443 nahe vor Ort betreiben, Verbindungserfolgsrate für UDP und TCP pro Land und ASN überwachen, bei Providern mit nachgewiesener UDP-Drosselung Belege sammeln und eskalieren. - Aufgaben Extern: Beim betroffenen Provider oder der zuständigen Behörde nach den Kriterien der UDP-Beschränkung und nach Lockerungen fragen, Spieler bitten, zum Vergleich aus einem anderen Netz zu spielen. - Größenordnungen: Laut einer in einem IETF-Dokument zitierten Messung sperren 3–5 % der Netze UDP vollständig. Google stellte 2016 bei der Auswertung von QUIC (UDP-basiert) fest, dass 4,4 % der Clients QUIC nicht nutzen konnten, weil UDP oder QUIC gesperrt oder die Path-MTU zu klein war. Die meisten saßen hinter Firmen-Firewalls, eine providerweite Sperre wurde nicht beobachtet. 0,3 % befanden sich in Netzen, in denen der Verlust zur Stoßzeit stark stieg und UDP offenbar gedrosselt wurde. Durch Anfragen bei den Providern sank dieser Anteil von 1 % im Jahr 2015. - Im Graphen: Nur einzelne Ausreißer (UDP-Verbindungserfolgsrate (nach Land und ASN)) - Wo nachsehen: Erfolgsrate von UDP-Verbindungen und vom Fallback über TCP 443 getrennt nach Land und ASN auswerten. Von einer Cloud-VM im betroffenen Providernetz oder vom PC des Spielers Verbindungstests auf den UDP-Spielport und auf TCP 443 durchführen und mit mtr -u -P (Spielport) und mtr -T -P 443 vergleichen, ab welchem Abschnitt keine Antworten mehr kommen - Spricht dafür: Nur in bestimmten Ländern oder ASNs bleibt die erste UDP-Antwort aus oder die Verbindung bricht nach einigen Sekunden ab, während TCP 443 vom selben Ort normal funktioniert. Bei Drosselung steigt der UDP-Verlust nur zur Stoßzeit deutlich, TCP ist weniger betroffen - Spricht dagegen: TCP scheitert ebenfalls: eher Routenstörung, IP-Sperre oder „DNS-Störung oder -Verzögerung“. In allen Ländern gleich: Konfiguration der eigenen Server oder Firewall. Verlust nur bei kurzzeitig hohem Sendevolumen, egal ob UDP oder TCP: „Policer verwirft Überschuss“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Laut einem Übersichtsdokument der IRTF sperren Geräte zur Paketinspektion UDP-Flows gezielt nach Adresse, Port und Protokoll, oder sie sperren alles außer ausdrücklich erlaubten Protokollen (Allowlist). Entscheidet ein Gerät nur anhand einzelner Felder im Paket, kann schon eine kleine Protokolländerung zur Sperre führen. In der Anfangszeit von QUIC ließ eine Firewall nach der Änderung von 1 Bit im Header die ersten Pakete durch und sperrte die folgenden. Dadurch griff die Logik nicht, mit der der Client auf TCP umschalten sollte. Beim Start in einem neuen Land kann sich das Problem durch Meldungen wie „Im Inland läuft alles, aber bei einigen Providern dort kommt keine Verbindung zustande“ zeigen. Ist nur das Netz eines bestimmten Ortes wie eines Cafés oder einer Firma betroffen, lesen Sie den Eintrag „Einschränkungen in öffentlichen WLANs und Firmennetzen“. - Quellen: - [RFC 9308: Applicability of the QUIC Transport Protocol](https://www.rfc-editor.org/rfc/rfc9308) · IETF · Laut Messstudien sperren 3–5 % der Netze UDP vollständig, UDP-basierte Apps müssen daher Verbindungsfehler hinnehmen oder einen Fallback über TCP (TLS) vorsehen, Ports ohne Zuordnung zu einem registrierten Dienst können von Firewalls gesperrt werden - [The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf) · ACM · 2016: 4,4 % der Clients konnten QUIC (UDP) nicht nutzen (UDP oder QUIC gesperrt oder Path-MTU zu klein, meist hinter Firmen-Firewalls, keine providerweite Sperre beobachtet), 0,3 % in Netzen mit vermutlicher UDP-Drosselung (mehr Verlust zur Stoßzeit, nach Anfragen bei Providern gesunken von 1 % im Jahr 2015), Fall einer Firewall, die nach Änderung von 1 Bit im Header nur die ersten Pakete durchließ, danach sperrte und so die TCP-Fallback-Logik aushebelte - [RFC 9505: A Survey of Worldwide Censorship Techniques](https://www.rfc-editor.org/rfc/rfc9505) · IRTF · Inspektionsgeräte im Netz können TCP- und UDP-Flows gezielt nach Adresse, Port und Protokoll sperren (bei QUIC wurde das Sperren von UDP-Endpunkten beobachtet), Allowlists, die alle nicht erlaubten Protokolle sperren, führen zu Overblocking, auch die Drosselung bestimmten Datenverkehrs kommt vor - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Mit -u werden UDP-Pakete, mit -T TCP-SYNs gesendet, -P legt den Zielport fest, so wird die Route mit demselben Protokoll und Port wie das Spiel gemessen #### isp-line · Schlechte Leitungsqualität · Faulty last-mile line / modem Wackelkontakte an Anschlüssen, alte Leitungen oder ein defektes Modem verursachen dauerhaften Paketverlust und wiederkehrende Leitungsabbrüche. - Warum → Folge → Auf dem Bildschirm: Beschädigtes Kabel, Wackelkontakt, Störung an Modem oder Glasfaser-Endgerät (ONT) → Bitfehler führen zum Verwerfen von Paketen, gelegentlich ist die Leitung beim Neuaufbau einige Sekunden bis etwa 1 Minute getrennt → Ständiger leichter Paketverlust, gelegentlich einige Sekunden Freeze oder Verbindungsabbruch - Symptome: Teleportieren, Freeze, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Gleicher Haushalt / Wann: Gelegentlich, zufällig - Hauptzuständig: Extern (Extern) - Aufgaben Extern: Spieler prüfen lassen, ob auch andere Spiele oder Videoanrufe abbrechen, und in dem Fall empfehlen, eine Prüfung beim Provider anzufordern. - Im Graphen: Vereinzelte Spitzen ohne Muster (Verlustrate, Protokoll der Leitungs-Neuverbindungen) - Wo nachsehen: Mit pathping (oder mtr) einige Minuten lang den Verlust bis zum ersten Abschnitt beim Provider messen, im Verbindungsprotokoll für Internet (WAN) in der Router-Oberfläche die Zeitpunkte der Neuverbindungen ansehen - Spricht dafür: Auch bei wenig Last auf der Leitung tritt ab dem ersten Providerabschnitt ständig Verlust auf, und die Neuverbindungen im Router-Protokoll fallen mit den Freezes und Abbrüchen zusammen. Andere Spiele und Videoanrufe brechen ebenfalls ab - Spricht dagegen: Verlust beginnt schon auf der Funkstrecke zum Router: „WLAN-Funkstörungen und schwaches Signal“. Beginnt er erst weiter hinten im Providernetz: Route des Providers - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · Frames, die die Prüfsumme (FCS) nicht bestehen, werden als FCS-Fehler (dot3StatsFCSErrors) gezählt und zu den Eingangsfehlern (ifInErrors) addiert - [Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017)](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/CorrOpt_SIGCOMM2017.pdf) · ACM · Hauptursachen für beschädigte Pakete sind defekte optische Module, beschädigte Fasern, verschmutzte Stecker und fehlerhafte Installation, die Verlustrate durch Beschädigung ist unabhängig von der Auslastung konstant - [pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) · Microsoft · Sendet über einen bestimmten Zeitraum Pings an jeden Abschnitt, berechnet die Verlustrate pro Router und Link und zeigt so, in welchem Abschnitt Verlust entsteht #### isp-dns · DNS-Störung oder -Verzögerung · DNS failure / slowness Ist das DNS, das Servernamen in Adressen übersetzt, langsam oder fällt aus, werden Login- und Patch-Server nicht gefunden. - Warum → Folge → Auf dem Bildschirm: Störung oder Fehlkonfiguration des Provider-DNS → Adressen von Login- und Patch-Server werden nicht gefunden → Nach Klick auf „Verbinden“ lange Wartezeit oder kein Login. Wer bereits verbunden ist, spielt normal weiter - Symptome: Kein Login / Endlos-Laden / Faktoren: Latenz, Paketverlust - Wer: Bestimmte Region oder Provider, Nur ich / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Adressen cachen (letzte erfolgreich verbundene Serveradresse merken), mehrere DNS-Server vorsehen (fällt einer aus, bei einem anderen erneut abfragen). - Aufgaben Extern: Spielern empfehlen, testweise einen anderen DNS-Server einzutragen, etwa einen öffentlichen DNS. - Im Graphen: Nur einzelne Ausreißer (Fehlgeschlagene Logins (nach Provider), DNS-Abfragezeit) - Wo nachsehen: Mit Resolve-DnsName -Server (oder nslookup) den Namen des Login-Servers beim Provider-DNS und bei einem öffentlichen DNS abfragen und Antwortzeit und Ergebnis vergleichen - Spricht dafür: Nur das Provider-DNS antwortet nicht oder braucht lange, mit öffentlichem DNS klappt der Login sofort. Bereits verbundene Spieler sind nicht betroffen - Spricht dagegen: Jedes DNS liefert die Adresse sofort, Login klappt trotzdem nicht: Route, Firewall oder Server - Prüfmittel: Prüfung in der Umgebung des Spielers - Reale Fälle: meta-2021, cloudflare-dns-2025, aws-2025 - Quellen: - [Cloudflare 1.1.1.1 Incident on July 14, 2025](https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/) · Cloudflare · Als ein öffentlicher DNS-Resolver 62 Minuten lang ausfiel, waren für Nutzer, die keine Namen mehr auflösen konnten, praktisch alle Internetdienste unerreichbar - [RFC 8767: Serving Stale Data to Improve DNS Resiliency](https://www.rfc-editor.org/rfc/rfc8767) · IETF · Verfahren, bei dem abgelaufene Cache-Einträge weiter genutzt werden, solange die autoritativen Server nicht erreichbar sind, um Störungen zu überbrücken (serve-stale) - [Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) · Microsoft · Fragt einen Namen ab, wobei -Server den zu befragenden DNS-Server festlegt - [nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup) · Microsoft · Befehl, mit dem sich Namen direkt bei einem DNS-Server abfragen lassen #### isp-ddos-path · Vollauslastung gemeinsamer Leitungen durch DDoS · DDoS saturating shared links Ein massiver Angriff auf den Spielebetreiber oder auf ein anderes Ziel im selben Netz lastet gemeinsam genutzte Leitungen voll aus. - Warum → Folge → Auf dem Bildschirm: Massiver Angriffs-Traffic → Auch legitimer Traffic auf derselben Leitung wird verdrängt und verworfen → Viele Spieler gleichzeitig: Teleportieren, Verbindungsabbruch, kein Login - Symptome: Teleportieren, Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Paketverlust, Latenz - Wer: Ganzer Server, Bestimmte Region oder Provider / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Extern (Extern) - Aufgaben Infrastrukturteam: DDoS-Schutzdienst nutzen, Traffic bei Angriffen umleiten, Serveradressen verbergen (Server hinter Schutzsysteme stellen und die echten Adressen nicht preisgeben). - Aufgaben Extern: Gilt der Angriff einem anderen Ziel im selben Netz, den Provider bitten, ihn weiter vorgelagert zu blockieren. - Im Graphen: Plateau am Limit (Empfangsvolumen der Leitung (bps, pps), Interface-Drops) - Wo nachsehen: Empfangsvolumen und verworfene Pakete an den Interfaces der eigenen Leitungen und Geräte sowie die Angriffserkennung des DDoS-Schutzdienstes mit den Zeitpunkten gehäufter Abbrüche abgleichen - Spricht dafür: Das Empfangsvolumen liegt flach an der Leitungskapazität an, die Drops steigen, und zur selben Zeit teleportieren Spieler aus mehreren Regionen und von mehreren Providern gleichzeitig oder verlieren die Verbindung - Spricht dagegen: Leitung hat Reserven, aber nur einige Provider schlecht: Überlast oder Routenproblem im Providerabschnitt - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Infrastructure layer attacks](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/infrastructure-layer-attacks.html) · AWS · Volumenangriffe wie UDP-Reflection oder SYN-Floods überlasten die Netzkapazität oder binden Ressourcen von Firewalls und Load-Balancern - [Obfuscating AWS resources (BP1, BP4, BP5)](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/obfuscating-aws-resources-bp1-bp4-bp5.html) · AWS · Edge-Dienste wie CloudFront oder Load-Balancer vor den Ursprungsserver stellen, um seine direkte Erreichbarkeit aus dem Internet zu verringern - [RFC 7999: BLACKHOLE Community](https://www.rfc-editor.org/rfc/rfc7999) · IETF · BLACKHOLE-Community, mit der per BGP benachbarte Provider gebeten werden, Traffic zu einer bestimmten Adresse zu verwerfen #### isp-cgnat · Geteilte Provider-IP (CGNAT) · Carrier-grade NAT In Mobilfunknetzen und bei manchen Providern teilen sich viele Kunden eine IP-Adresse, und die Mappings von Idle-Verbindungen werden schon nach kurzer Zeit gelöscht. - Warum → Folge → Auf dem Bildschirm: Gerät des Providers verwaltet die Session-Tabelle für sehr viele Kunden → Begrenzte Session-Tabelle, kurzes Idle-Timeout → Verbindungsabbruch nach Inaktivität, False Positives, bei denen alle Spieler mit derselben IP gemeinsam gesperrt werden - Symptome: Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Bestimmte Region oder Provider / Wann: Nach Inaktivität - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (im Mobilfunknetz teils nur etwa 30 s), und zwar vom Client aus (das CGNAT-Mapping des Providers wird nur durch ausgehende Pakete zuverlässig erneuert), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Spieler per Session-Token als denselben Spieler weiterführen, auch wenn sich Adresse und Port durch ein neues Mapping ändern, IP-basierte Sperren mit Vorsicht einsetzen, da sich viele eine IP teilen können (zusammen mit Konto- und Gerätemerkmalen bewerten). - Aufgaben Infrastrukturteam: Limits für Verbindungen pro IP und neue Verbindungen pro Sekunde in Firewalls und DDoS-Schutz an geteilte Provider-IPs anpassen (für Adressbereiche von Mobilfunkanbietern Schwellen anheben oder Ausnahmen definieren). - Größenordnungen: Im Mobilfunknetz liegt das UDP-Idle-Timeout teils bei nur etwa 30 s. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungsabbrüche (Heartbeat-Timeout), Idle-Zeit vor dem Abbruch (nach Provider)) - Wo nachsehen: Im Verbindungslog die Zahl gleichzeitig über eine IP verbundener Konten und den Provider (ASN) ansehen, die Idle-Zeit von Verbindungen, die nach Inaktivität abbrachen, pro Provider sammeln. Beim Spieler die Internetadresse (WAN) in der Router-Oberfläche prüfen - Spricht dafür: In Adressbereichen von Mobilfunkanbietern hängen mehrere Konten an einer IP, und die Idle-Zeit vor dem Abbruch häuft sich bei kurzen Werten um 30–60 s. Die WAN-Adresse des Routers liegt in 100.64.0.0/10 (gemeinsamer Adressbereich für Provider-NAT) oder weicht von der Adresse ab, die der Server sieht - Spricht dagegen: Häuft sich unabhängig vom Provider bei Spielern mit eigenem Router zu Hause: „Ablauf des NAT-Mappings“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [A Multi-perspective Analysis of Carrier-Grade NAT Deployment (IMC 2016)](https://www.icir.org/vern/papers/cgn-imc16.pdf) · ACM · Gemessene Haltedauer von UDP-Mappings in NATs: 10–200 s, 74 % höchstens 1 Minute, Median bei CGN: Mobilfunknetz 65 s, Festnetz 35 s - [RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs)](https://www.rfc-editor.org/rfc/rfc6888) · IETF · CGNs müssen Limits für externe Ports pro Kunde und für die Rate neu angelegter Mappings unterstützen - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Teilen sich viele eine Adresse, trifft eine IP-basierte Sperre (Penalty Box) auch andere Kunden mit derselben Adresse - [RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space](https://www.rfc-editor.org/rfc/rfc6598) · IETF · 100.64.0.0/10 ist der gemeinsame Adressbereich zwischen dem NAT-Gerät des Providers (CGN) und dem Router des Kunden #### isp-vpn · Umweg über VPN oder Ping-Booster · VPN / game accelerator detour Mit aktivem VPN oder Ping-Booster laufen die Pakete über die Relay-Server des Anbieters. Sind diese weit entfernt oder überlastet, wird die Verbindung sogar langsamer. - Warum → Folge → Auf dem Bildschirm: VPN oder Ping-Booster leitet alle Spielpakete über Relay-Server um → Entfernung und Überlast bis zum Relay-Server kommen hinzu, und durch den Tunnel-Header sinkt auch die MTU (maximale Paketgröße pro Sendung) → Höherer Ping und Paketverlust, kein Login, weil die Sperre alle Nutzer derselben Relay-Adresse trifft - Symptome: Input-Lag, Teleportieren, Kein Login / Endlos-Laden / Faktoren: Latenz, Paketverlust - Wer: Nur ich / Wann: Immer, Direkt nach Login oder Wartung - Hauptzuständig: Extern (Extern) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: UDP-Pakete auf höchstens 1.200 Byte begrenzen (damit sie auch bei durch Tunnel-Header verringerter MTU nicht fragmentiert werden), bei IP-basierten Sperren die gemeinsam genutzten Relay-Adressen von VPNs und Ping-Boostern berücksichtigen und zusammen mit Konto- und Gerätemerkmalen bewerten. - Aufgaben Infrastrukturteam: Bei vielen Spielern im Ausland eigene Zugangspunkte in ihrer Nähe aufbauen, bei Providern mit gehäuften Meldungen wie „Mit Ping-Booster ist es besser“ die Route prüfen. - Aufgaben Extern: Spieler bitten, VPN oder Ping-Booster zum Vergleich auszuschalten. - Größenordnungen: Ein naher Relay-Server kostet einige ms, ein Umweg über ein anderes Land einige Dutzend bis über 100 ms. - Im Graphen: Nur einzelne Ausreißer (RTT (pro Spieler), Anbieter der Verbindungs-IP) - Wo nachsehen: Prüfen, ob die ASN der Verbindungs-IP zu einem VPN-, Ping-Booster- oder Hosting-Anbieter gehört, Spieler VPN oder Ping-Booster ausschalten und Ping und traceroute vergleichen lassen - Spricht dafür: Nur mit aktivem VPN oder Ping-Booster steigen RTT und Paketverlust oder der Login scheitert, und im traceroute ist ein Abschnitt über den Relay-Server zu sehen - Spricht dagegen: Ein- und ausgeschaltet gleich: Leitung oder Providerabschnitt. Mit aktivem VPN oder Ping-Booster besser: Problem der normalen Provider-Route („Umweg-Routing“, „Überlast am Peering-Punkt zur Stoßzeit“) - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Umgekehrt kann ein Ping-Booster bei schlechter Provider-Route einen besseren Weg nehmen und den Ping senken. Meldungen wie „Mit Ping-Booster ist es besser“ sind deshalb ein Hinweis auf Routenprobleme beim Provider wie Umweg-Routing oder abendliche Überlast. - Quellen: - [RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling](https://www.rfc-editor.org/rfc/rfc4459) · IETF · Fragmentierungs- und Path-MTU-Probleme, weil der Kapselungs-Header von Tunneln im Netz die nutzbare Paketgröße verringert - [RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports](https://www.rfc-editor.org/rfc/rfc8899) · IETF · Für Datagramm-Transporte wie UDP werden 1.200 Byte als sichere Grundgröße (BASE_PLPMTU) empfohlen - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Größenordnung der zusätzlichen Umlaufzeit bei einem Umweg über Standorte in anderen Ländern: Seoul–Tokio 30 ms, Seoul–Hongkong 39 ms, Seoul–Singapur 68 ms ### L5 Netzwerkgeräte im Rechenzentrum (11 Ursachen) #### dc-firewall · Volle Session-Tabelle der Firewall · Firewall session table exhaustion Die Firewall verfolgt jede durchgelassene Verbindung in ihrer Session-Tabelle. Ist die Tabelle voll, kann sie keine neuen Verbindungen mehr annehmen. - Warum → Folge → Auf dem Bildschirm: Ansturm beim Login oder Angriff, die Zahl der Sessions erreicht das Limit → Kein freier Eintrag für neue Verbindungen, sie werden abgelehnt → Wer neu verbinden will: Kein Login / Endlos-Laden. Auch bei einigen bestehenden Verbindungen Verbindungsabbruch - Symptome: Kein Login / Endlos-Laden, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Direkt nach Login oder Wartung, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Ansturm per Login-Warteschlange dosieren, Verbindungen wiederverwenden, damit nicht ständig neue kurze Verbindungen entstehen, Verbindungen ohne Heartbeat von sich aus aufräumen (damit tote Verbindungen die Session-Tabelle nicht lange belegen). Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden, bei Abbruch automatischer Reconnect mit wachsenden, zufällig gestreuten Wiederholungsabständen (damit nicht alle gleichzeitig zurückkommen). - Aufgaben Infrastrukturteam: Session-Tabelle vergrößern, kurz beendete Verbindungen schnell aufräumen (Timeout für beendete Sessions verkürzen), beim Verkürzen des Idle-Timeouts für Sessions den neuen Wert dem Entwicklungsteam mitteilen und das Heartbeat-Intervall anpassen, Angriffe blockieren, Alarm auf die Auslastung der Session-Tabelle. - Im Graphen: Plateau am Limit (Anzahl Firewall-Sessions, fehlgeschlagene neue Verbindungen) - Wo nachsehen: Gleichzeitige Sessions der Firewall zusammen mit dem Session-Limit als Graph ansehen und im Geräte-Log nach Paketen suchen, die verworfen wurden, weil keine Session angelegt werden konnte. Bei einer Linux-Firewall nf_conntrack_count mit nf_conntrack_max vergleichen und in dmesg nach „nf_conntrack: table full, dropping packet“ suchen, bei AWS-Instanzen conntrack_allowance_exceeded in ethtool -S prüfen - Spricht dafür: Ab dem Zeitpunkt, an dem die Session-Zahl flach am Limit liegt, steigen die fehlgeschlagenen neuen Verbindungen, und Log-Einträge zu gescheiterter Session-Erstellung oder Drop-Zähler steigen mit - Spricht dagegen: Session-Zahl weit unter dem Limit, Login klappt trotzdem nicht: „Überlauf der Verbindungswarteschlange (Backlog)“ oder Login-Server. Nur Idle-Verbindungen brechen ab: „Ablauf des Connection Trackings in Cloud-Security-Groups“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Maximale Zahl der Einträge in der Connection-Tracking-Tabelle (nf_conntrack_max), Haltedauer für Verbindungen im Abbau (TIME_WAIT, FIN_WAIT, Standard 120 s), für aufgebaute TCP-Verbindungen standardmäßig 5 Tage, aktuelle Zahl der Einträge (nf_conntrack_count) - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Wird die Zahl der pro Instanz verfolgbaren Verbindungen überschritten, werden Pakete neuer Verbindungen verworfen, Idle-Verbindungen können die Tracking-Tabelle erschöpfen - [Infrastructure layer attacks](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/infrastructure-layer-attacks.html) · AWS · Angriffe wie SYN-Floods binden Ressourcen von Servern, Firewalls und Load-Balancern - [net/netfilter/nf_conntrack_core.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_core.c?h=v6.12) · Linux kernel · Ist die Connection-Tracking-Tabelle voll, wird „nf_conntrack: table full, dropping packet“ protokolliert, und Pakete neuer Verbindungen werden verworfen - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · conntrack_allowance_exceeded: Zahl der Pakete, die wegen Überschreitung des Connection-Tracking-Limits der Instanz verworfen wurden, abrufbar mit ethtool -S #### dc-ddos · Umweg über DDoS-Schutz und False Positives · DDoS scrubbing latency, false positives Wird der Traffic zur Abwehr eines Angriffs über ein Scrubbing-Center umgeleitet, wird die Route länger, und legitime Spieler werden manchmal fälschlich als Angreifer blockiert. - Warum → Folge → Auf dem Bildschirm: Nach Erkennung eines Angriffs (oder dauerhaft) wird eingehender Traffic über ein Scrubbing-Center umgeleitet → Route wird länger, einige legitime Pakete werden als Angriff eingestuft → Ping steigt für alle, nur bestimmte Regionen oder Provider: kein Login - Symptome: Input-Lag, Kein Login / Endlos-Laden, Teleportieren / Faktoren: Latenz, Paketverlust - Wer: Ganzer Server, Bestimmte Region oder Provider / Wann: Bei großem Andrang, Gelegentlich, zufällig - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Muster des Spiel-Traffics (Ports, Paketgrößen, Pakete pro Sekunde) dokumentieren und mit dem Infrastrukturteam teilen, UDP-Pakete auf höchstens 1.200 Byte begrenzen. - Aufgaben Infrastrukturteam: Schutzregeln auf die Muster des Spiel-Traffics abstimmen, regionale Scrubbing-Standorte nutzen, TCP-Paketgröße auf Tunnelstrecken verringern (MSS-Clamping), False Positives anhand der Verbindungsfehlerrate pro Region und Provider erkennen. - Größenordnungen: Liegt der Scrubbing-Standort im selben Land, kommen einige ms hinzu, bei einem Standort im Ausland 30–100 ms und mehr. Meist wird nur der eingehende Traffic umgeleitet, die Antworten des Servers gehen direkt hinaus. Kommt der gefilterte Traffic per Tunnel zurück, sinkt außerdem die maximale Paketgröße pro Sendung (MTU). Das kann dazu führen, dass nur große Pakete verschwinden. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (RTT (Ping), Verbindungsfehlerrate nach Region und Provider) - Wo nachsehen: Beginn und Ende der Umleitung (Scrubbing) und die Sperr-Logs der Schutzsysteme oder -dienste auf dieselbe Zeitachse legen wie den RTT-Graphen und die Verbindungsfehlerrate pro Region und Provider. Aus der betroffenen Region per mtr oder traceroute prüfen, ob ein Scrubbing-Standort in der Route liegt - Spricht dafür: Mit Beginn der Umleitung steigt die RTT um eine Stufe, bleibt dort und fällt nach dem Abschalten zurück. Oder in den Sperr-Logs stehen Adressen legitimer Spieler, und nur in dieser Region oder bei diesem Provider steigt die Verbindungsfehlerrate - Spricht dagegen: RTT steigt zu Zeiten ohne Umleitung oder Sperre: „Umweg-Routing“ oder „BGP-Routenwechsel und Konvergenz“. Nur große Pakete verschwinden: „MTU-Mismatch (nur große Pakete verschwinden)“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Eingehender Traffic wird nach der Filterung über einen GRE-Tunnel (MTU 1.476) zugestellt, ausgehende Antworten gehen direkt ins Internet (DSR), Empfehlung: TCP-MSS auf höchstens 1.436 begrenzen, sonst werden große Pakete verworfen oder fragmentiert - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Größenordnung der Umlaufzeit je nach Standort: Seoul–Region Busan 8 ms, Seoul–Tokio 30 ms, Seoul–Singapur 68 ms #### dc-lb-idle · Idle-Timeout des Load-Balancers · Load balancer idle timeout Load-Balancer löschen Idle-Verbindungen nach einer bestimmten Zeit. Das Spiel hält die Verbindung weiter für bestehend, bis es zum Verbindungsabbruch kommt. - Warum → Folge → Auf dem Bildschirm: Spieler sendet eine Weile kein einziges Paket (Chatfenster, AFK) → Load-Balancer räumt die Idle-Verbindung ab (übliche Standardwerte 60–350 s) → Verbindungsabbruch, sobald sich der Spieler wieder bewegt - Symptome: Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich, Ganzer Server / Wann: Nach Inaktivität - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (hinter einem ALB mit 60 s also höchstens alle 30 s), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten, Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Session per Session-Token fortsetzen. - Aufgaben Infrastrukturteam: Idle-Timeouts der Load-Balancer auf der Route prüfen, dem Entwicklungsteam mitteilen und bei Bedarf erhöhen. - Größenordnungen: Standardwerte: AWS ALB 60 s, NLB 350 s für TCP und 120 s für UDP, Azure Load Balancer 4 Minuten für TCP. Die TCP-Werte von ALB und NLB lassen sich ändern, die 120 s für UDP beim NLB nicht. Der ALB schließt nach Ablauf auch die Verbindung zum Server. Der NLB löscht sie stillschweigend, sodass der Server oft nichts davon merkt. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungsabbrüche, Idle-Zeit vor dem Abbruch) - Wo nachsehen: Idle-Timeout-Einstellung der Load-Balancer auf der Route prüfen und für jede abgebrochene Verbindung die Zeit vom letzten Paket bis zum Abbruch sammeln. Bei AWS NLB auch TCP_ELB_Reset_Count in CloudWatch ansehen (vom Load-Balancer gesendete RSTs) - Spricht dafür: Die Idle-Zeit abgebrochener Verbindungen häuft sich knapp über dem eingestellten Wert (ALB 60 s, NLB TCP 350 s usw.), und wer länger als diese Zeit untätig bleibt und sich dann bewegt, löst den Abbruch reproduzierbar aus. Beim NLB steigt zur selben Zeit TCP_ELB_Reset_Count - Spricht dagegen: Abbrüche ohne Zusammenhang mit der Idle-Zeit: nicht diese Ursache. Häufung um 350 s bei Servern ohne Load-Balancer: „Ablauf des Connection Trackings in Cloud-Security-Groups“. Liegt es am Router beim Spieler zu Hause: „Ablauf des NAT-Mappings“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Edit attributes for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html) · AWS · Idle-Timeout des ALB standardmäßig 60 s (1–4.000 s), ist die Verbindung zu Client oder Ziel so lange still, schließt der Load-Balancer sie - [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) · AWS · TCP-Idle-Timeout des NLB standardmäßig 350 s (60–6.000 s), danach endet nur das Tracking, und auf später eintreffende Daten folgt ein RST, die 120 s für UDP-Flows sind nicht änderbar - [Configure load balancer TCP reset and idle timeout](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout) · Microsoft Azure · Idle-Timeout des Azure Load Balancer standardmäßig 4 Minuten (4–100 Minuten), danach keine Garantie, dass die Session erhalten bleibt, TCP-Reset optional - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · TCP_ELB_Reset_Count: Zahl der vom Load-Balancer erzeugten und gesendeten RST-Pakete #### dc-cloud-conntrack · Ablauf des Connection Trackings in Cloud-Security-Groups · Cloud security group connection tracking timeout Auch die Firewall einer Cloud-Instanz (Security Group) verfolgt Verbindungen, und Tracking-Einträge von Idle-Verbindungen laufen nach einer festen Zeit ab. Deshalb können auch Spieler, die ohne Load-Balancer direkt mit dem Server verbunden sind, nach einer Ruhephase die Verbindung verlieren. - Warum → Folge → Auf dem Bildschirm: Security Group ist so konfiguriert, dass sie Spielverbindungen verfolgt (nur bestimmte Adressen erlaubt, eingeschränkte Ausgangsregeln, Weg über NLB usw.) → Tracking-Eintrag einer länger inaktiven Verbindung läuft ab, danach eintreffende Pakete verwirft die Security Group stillschweigend → Nach AFK keine Reaktion beim Weiterspielen, dann Verbindungsabbruch. Das Serverprogramm merkt lange nichts - Symptome: Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich, Ganzer Server / Wann: Nach Inaktivität - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (bei 350 s für TCP höchstens alle 175 s, bei 180 s für UDP-Streams höchstens alle 90 s), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten, Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Session per Session-Token fortsetzen. - Aufgaben Infrastrukturteam: Connection-Tracking-Timeout der Instanz (TcpEstablishedTimeout) prüfen und bei Bedarf erhöhen (für UDP sind 180 s das Maximum), eine Security-Group-Konfiguration ohne Tracking prüfen (Spielport für alle Adressen öffnen, alle ausgehenden Verbindungen erlauben, Verbindungen über einen NLB werden trotzdem verfolgt), beim Umzug auf eine neue Instanzgeneration Idle-Tests fahren. - Größenordnungen: Bei AWS löschen Instanztypen mit Nitro v6 Tracking-Einträge inaktiver TCP-Verbindungen standardmäßig nach 350 s (andere Typen nach 5 Tagen). Für UDP gelten standardmäßig 180 s bei Flows mit mehreren Anfrage-Antwort-Wechseln (Stream) und 30 s bei Flows, die nur in eine Richtung liefen oder nur aus einer Anfrage und einer Antwort bestanden. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungsabbrüche, Idle-Zeit vor dem Abbruch) - Wo nachsehen: Connection-Tracking-Timeout der Instanz und die Regeln der Security Group prüfen (entsteht überhaupt Tracking?), Idle-Zeiten abgebrochener Verbindungen sammeln. Direkt nach einem Abbruch auf dem Server mit ss -tnoi prüfen, ob die Verbindung noch als ESTABLISHED besteht, der Retransmission-Timer (timer:(on,…)) läuft und backoff wächst - Spricht dafür: Die Idle-Zeit abgebrochener Verbindungen häuft sich knapp über 350 s (TCP), 180 s (UDP-Stream) oder 30 s (UDP in eine Richtung), und der Socket auf dem Server bleibt als ESTABLISHED stehen, ohne den Abbruch zu bemerken (hat der Server Daten zu senden, wiederholt er nur Retransmissions) - Spricht dagegen: Security Group ohne Tracking konfiguriert (Spielport für alle Adressen offen, alle ausgehenden Verbindungen erlaubt, kein NLB): nicht diese Ursache. Läuft die Verbindung über einen NLB: Werte mit „Idle-Timeout des Load-Balancers“ vergleichen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · TCP-Idle-Tracking standardmäßig 350 s (Nitro v6, sonst 432.000 s = 5 Tage), UDP in eine Richtung 30 s, Stream 180 s (Maximum 180), bei Regeln, die alle Adressen erlauben, kein Tracking, Verbindungen über einen NLB werden immer verfolgt - [Update the TCP idle timeout for your Network Load Balancer listener](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/update-idle-timeout.html) · AWS · Ist das Idle-Timeout des NLB länger als das Connection-Tracking-Timeout der Zielinstanz, verwirft die Instanz den Verbindungszustand zuerst und stillschweigend - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · timer:(on,…) bei -o ist der Retransmission-Timer, backoff bei -i gibt an, wie oft die Wartezeit für Retransmissions verdoppelt wurde #### dc-nat-gateway · Verbindungs- und Portlimits des Cloud-NAT-Gateways · Cloud NAT gateway connection / port limits Verbindungen von Servern in einem privaten Subnetz nach außen (Plattform-Authentifizierung, Zahlung, externe APIs) laufen über ein NAT-Gateway, das Adresse und Port umschreibt. Übersteigen die gleichzeitigen Verbindungen zum selben Ziel das Port-Limit des Gateways, schlagen neue Verbindungen fehl. - Warum → Folge → Auf dem Bildschirm: Server öffnen viele kurze Verbindungen zur selben externen Adresse, etwa für Plattform-Authentifizierung oder Zahlung, oder halten Verbindungen lange offen → NAT-Gateway kann für dieses Ziel keine weiteren Quellports vergeben, neue Verbindungen schlagen fehl → Im Spiel selbst läuft alles, nur Funktionen mit externen Aufrufen wie Login, Zahlung oder Belohnungsvergabe scheitern oder hängen (Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback) - Symptome: Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback / Faktoren: Paketverlust, Latenz - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Direkt nach Login oder Wartung, Abendliche Stoßzeit, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Verbindungen zu externen APIs wiederverwenden (HTTP Keep-Alive, Connection-Pool) und nicht für jede Anfrage eine neue Verbindung öffnen, Idle-Verbindungen im Pool in kürzeren Abständen als das NAT-Idle-Timeout (AWS 350 s) per Keepalive aktiv halten oder vorher schließen, nach Fehlern mit wachsenden, zufällig gestreuten Abständen erneut versuchen, Fehlerrate und Latenz pro externem Aufruf protokollieren. - Aufgaben Infrastrukturteam: Dem NAT-Gateway IP-Adressen hinzufügen (ein öffentliches AWS NAT Gateway nimmt standardmäßig nur 2 Elastic IPs auf, für mehr eine Kontingenterhöhung beantragen), Gateways nach Availability Zone und Subnetz aufteilen, Alarm auf Metriken für fehlgeschlagene Portzuweisung (AWS ErrorPortAllocation, Azure SNAT Connection Count mit Status Failed, Google Cloud dropped_sent_packets_count mit OUT_OF_RESOURCES), bei Google Cloud NAT die Mindestzahl an Ports pro VM erhöhen oder dynamische Portzuweisung nutzen. - Größenordnungen: Ein AWS NAT Gateway kann pro IP-Adresse bis zu 55.000 gleichzeitige Verbindungen zum selben Ziel (IP, Port, Protokoll) öffnen, mit bis zu 8 IPs lässt sich das erweitern. Verbindungen, die 350 s still sind, werden gelöscht, und Pakete, die danach über diese Verbindung gesendet werden, erhalten ein RST. Azure NAT Gateway bietet 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs). Google Cloud NAT verteilt 64.512 Ports pro NAT-IP auf die VMs. Da die Mindestzahl an Ports pro VM standardmäßig 64 beträgt (statische Zuweisung), ist eine VM mit Standardeinstellungen meist auf 64 gleichzeitige Verbindungen zum selben Ziel begrenzt. - Im Graphen: Plateau am Limit (Gleichzeitige Verbindungen des NAT-Gateways, fehlgeschlagene Portzuweisungen) - Wo nachsehen: Bei AWS die NAT-Gateway-Metriken ErrorPortAllocation, ActiveConnectionCount und PacketsDropCount in CloudWatch (Azure: SNAT Connection Count gefiltert auf Status Failed und Dropped Packets, Google Cloud: dropped_sent_packets_count mit reason OUT_OF_RESOURCES) neben die Zeitpunkte legen, an denen externe Aufrufe des Spielservers scheitern - Spricht dafür: Zum Zeitpunkt der gescheiterten externen Aufrufe ist ErrorPortAllocation (Azure: SNAT Connection Count mit Status Failed, Google Cloud: Drops mit OUT_OF_RESOURCES) größer als 0, und die Fehler betreffen Aufrufe zu ein, zwei Zielen mit vielen Verbindungen wie Authentifizierungs- oder Zahlungsservern - Spricht dagegen: Fehlgeschlagene Portzuweisungen bei 0, aber connect auf dem Spielserver scheitert mit EADDRNOTAVAIL, und TIME_WAIT nähert sich dem Bereich der ephemeren Ports: „Erschöpfte ephemere Ports bei Verbindungen zwischen Servern“. Verbindung klappt, nur die Antwort ist langsam: „Abhängigkeit von externen Diensten“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Bei „Erschöpfte ephemere Ports bei Verbindungen zwischen Servern“ gehen einem einzelnen Server die ephemeren Ports aus. Hier liegt das Limit beim NAT-Gateway, und alle Server dahinter teilen es sich (Google Cloud NAT teilt es pro VM auf). Haben TIME_WAIT und der Bereich der ephemeren Ports auf dem Server noch Reserven und scheitern trotzdem nur externe Aufrufe, liegt diese Ursache vor. Auch Ports geschlossener Verbindungen werden nicht sofort wieder für dasselbe Ziel verwendet (Azure: Cooldown, Google Cloud: während TIME_WAIT gesperrt). Je öfter kurze Verbindungen aufgebaut werden, desto schneller ist das Limit erreicht. - Quellen: - [NAT gateway basics](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html) · AWS · Pro IPv4-Adresse 55.000 gleichzeitige Verbindungen zum selben Ziel (Ziel-IP, Port, Protokoll), mit bis zu 8 IPs erweiterbar (Elastic IPs eines öffentlichen NAT Gateways standardmäßig 2, mehr per Kontingenterhöhung), die Bandbreite skaliert automatisch von 5 auf 100 Gbps und der Durchsatz von 1 Million auf 10 Millionen Pakete pro Sekunde, darüber hinaus werden Pakete verworfen - [NAT gateway metrics and dimensions](https://docs.aws.amazon.com/vpc/latest/userguide/metrics-dimensions-nat-gateway.html) · AWS · ErrorPortAllocation: Zahl der Fälle, in denen kein Quellport vergeben werden konnte (größer als 0 heißt: zu viele gleichzeitige Verbindungen), ActiveConnectionCount, IdleTimeoutCount (nach 350 s Inaktivität aufgeräumte Verbindungen), PacketsDropCount - [Troubleshoot NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html) · AWS · Nach 350 s Inaktivität läuft die Verbindung ab, weiteres Senden wird mit RST beantwortet, Keepalive in kürzeren Abständen als 350 s empfohlen, bei Erreichen des Verbindungslimits Gateways pro Availability Zone oder zusätzliche IPs einrichten oder die Zahl der Verbindungen senken - [Source Network Address Translation (SNAT) with Azure NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-snat) · Microsoft Azure · 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs), jede Verbindung zum selben Ziel braucht einen eigenen Port, geschlossene Ports durchlaufen einen Cooldown, bevor sie wieder für dasselbe Ziel genutzt werden - [Metrics and alerts for Azure NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-metrics) · Microsoft Azure · Ist SNAT Connection Count gefiltert auf Status Failed größer als 0, sind die SNAT-Ports möglicherweise erschöpft, Dropped Packets - [IP addresses and ports](https://cloud.google.com/nat/docs/ports-and-addresses) · Google Cloud · Pro NAT-IP je 64.512 Ports für TCP und UDP, Standard-Mindestzahl an Ports pro VM 64 (statische Zuweisung) bzw. 32 (dynamische Zuweisung), die für eine VM reservierten Ports begrenzen die gleichzeitigen Verbindungen zum selben Ziel, geschlossene Verbindungen sind während TIME_WAIT nicht nutzbar - [Logs and metrics](https://cloud.google.com/nat/docs/monitoring) · Google Cloud · dropped_sent_packets_count mit reason OUT_OF_RESOURCES: Pakete, die verworfen wurden, weil NAT-IPs oder Ports nicht reichten #### dc-lb-imbalance · Load-Balancer-Schieflast und fehlerhafte Health-Checks · LB imbalance, bad health checks Verbindungen landen alle auf einem Server, oder Spieler werden weiter zu einem Server geschickt, der längst ausgefallen ist. - Warum → Folge → Auf dem Bildschirm: Verteilungsregel passt nicht, oder der Health-Check erkennt den tatsächlichen Zustand nicht → Nur ein Server überlastet oder Verbindungsversuche zu einem ausgefallenen Server → Nur in einigen Kanälen oder für einige Spieler: Zeitlupe, Kein Login / Endlos-Laden - Symptome: Zeitlupe, Kein Login / Endlos-Laden / Faktoren: Stillstand, Paketverlust - Wer: Bestimmter Ort oder Kanal / Wann: Direkt nach Login oder Wartung, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Health-Check implementieren, der auf Anfragen des Load-Balancers anhand des tatsächlichen Spielzustands antwortet (Tick läuft, DB-Verbindung steht), dabei auch die Serverlast melden. - Aufgaben Infrastrukturteam: Health-Checks auf die Prüfung echter Spielantworten umstellen, lastbasiert verteilen, Unterschiede in der Verbindungszahl pro Server überwachen. - Im Graphen: Nur einzelne Ausreißer (Verbindungen und CPU-Auslastung pro Server) - Wo nachsehen: Verbindungen (ss -s) und CPU-Auslastung jedes Servers hinter dem Load-Balancer in einem Graphen übereinanderlegen und den Health-Status der Ziele im Load-Balancer (bei AWS HealthyHostCount und UnHealthyHostCount in CloudWatch) mit dem tatsächlichen Zustand der Spielserver vergleichen - Spricht dafür: Nur ein, zwei Server haben deutlich mehr Verbindungen und CPU-Last als die übrigen, oder ein Server mit stehendem Tick bleibt im Health-Status „healthy“ und nimmt weiter neue Verbindungen an - Spricht dagegen: Verbindungen gleichmäßig verteilt, nur ein Kanal langsam: Last innerhalb dieses Kanals („Überlastetes Gebiet auf einem einzelnen Thread (Hotspot)“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: aws-2025 - Quellen: - [Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/) · Google · Einfaches Round Robin lässt die CPU-Last zwischen Tasks um bis zum Faktor 2 auseinanderklaffen, gewichtete Verteilung, bei der Backends ihre Last in Antworten und Health-Checks mitsenden, Lame-Duck-Zustand, in dem ein Backend keine Anfragen mehr annehmen will - [Health checks for Network Load Balancer target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) · AWS · Health-Checks standardmäßig alle 30 s, nach 2 Fehlschlägen wird das Ziel herausgenommen, UDP-Dienste werden per TCP- oder HTTP-Health-Check geprüft, daher wird eine Konfiguration empfohlen, die den tatsächlichen Dienstzustand widerspiegelt - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · HealthyHostCount, UnHealthyHostCount: Zahl der als gesund bzw. nicht gesund eingestuften Ziele #### dc-microburst · Microbursts am Switch · Switch microburst drops Senden mehrere Server im selben Moment Pakete an Tausende Spieler, läuft der kleine Puffer am Switch-Port, an dem dieser Traffic zusammenläuft, in weniger als 1 ms über. - Warum → Folge → Auf dem Bildschirm: Weltboss erscheint, großflächige Skills, oder die Ticks mehrerer Server fallen auf denselben Moment und senden gleichzeitig → Puffer (einige hundert KB bis einige MB pro Port) an Stellen, an denen mehrere Ports in einen münden oder ein schneller Port auf einen langsameren trifft, ist kurzzeitig voll → Ein Teil der Pakete wird verworfen, viele Spieler gleichzeitig: Teleportieren, verschluckte Skills - Symptome: Teleportieren, Verschluckte Aktion / Rollback / Faktoren: Paketverlust - Wer: Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Senden innerhalb des Ticks gleichmäßig verteilen (Pacing), Tick-Startzeitpunkte der Server leicht gegeneinander versetzen. - Aufgaben Infrastrukturteam: Netzwerk: Switches mit großen Puffern, Traffic verteilen (Server auf mehrere Switches und Ports aufteilen), Drop-Zähler pro Switch-Port überwachen. Server/OS: Senderate des gesamten Servers begrenzen (Linux-tc-Shaper). - Größenordnungen: Ein 10-Gbps-Port kann in 1 ms etwa 1,25 MB ausgeben. Läuft der Traffic zweier Ports gleichzeitig auf einen Port, stauen sich jede Millisekunde 1,25 MB auf. Auch wenn die über 1 s gemittelte Auslastung nur 10 % beträgt, kann der Puffer in 1-ms-Auflösung überlaufen. - Im Graphen: Steigt mit Spielerzahl und Last (Ausgangsdrops am Switch-Port) - Wo nachsehen: Ausgangsdrop-Zähler (ifOutDiscards, je nach Gerät output drops) am Switch-Port des Servers und am Port, an dem dieser Traffic zusammenläuft, in möglichst kurzen Intervallen erfassen und mit den Zeitpunkten von Boss-Spawns und Großschlachten abgleichen. In Graphen mit Mittelwerten über 1 s oder 1 Minute ist das nicht zu sehen - Spricht dafür: Durchschnittliche Auslastung niedrig, aber jedes Mal, wenn sich Spieler an einem Ort ballen, steigen die Ausgangsdrops, und gleichzeitig melden mehrere Spieler Teleportieren und verschluckte Skills - Spricht dagegen: Drops steigen stetig in Zeiten hoher Durchschnittsauslastung: „Vollauslastung der Rechenzentrumsanbindung“. Eingangsfehler (CRC) steigen: „Defekte Kabel und Portfehler“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [High-Resolution Measurement of Data Center Microbursts (IMC 2017)](https://conferences.sigcomm.org/imc/2017/papers/imc17-final60.pdf) · ACM · Über 70 % der Bursts im Rechenzentrum enden innerhalb einiger Dutzend µs, auch an Ports mit etwa 9 % Durchschnittsauslastung verwerfen Bursts Pakete - [Data Center TCP (DCTCP) (SIGCOMM 2010)](https://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p63.pdf) · ACM · Standard-Switches haben flache Puffer (48 Ports teilen sich 4 MB, ein Port nutzt bis zu etwa 700 KB), laufen mehrere Flows kurzzeitig auf einen Port, gehen Pakete verloren - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifOutDiscards: Zahl der Pakete, die ohne Fehler verworfen wurden und nicht gesendet werden konnten, etwa um Pufferplatz freizugeben #### dc-uplink · Vollauslastung der Rechenzentrumsanbindung · Uplink saturation Nutzen Patch-Verteilung, Log-Übertragung oder Backups dieselbe Leitung wie das Spiel, läuft die Leitung voll. - Warum → Folge → Auf dem Bildschirm: Große Übertragungen belegen dieselbe Leitung → Warteschlange und Paketverlust auf der Leitung steigen → Höherer Ping und Teleportieren auf dem ganzen Server - Symptome: Input-Lag, Teleportieren / Faktoren: Latenz, Paketverlust - Wer: Ganzer Server / Wann: In festen Abständen, Bei großem Andrang - 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: - [RFC 4594: Configuration Guidelines for DiffServ Service Classes](https://www.rfc-editor.org/rfc/rfc4594) · IETF · Interaktiven Echtzeit-Traffic wie Spiele und große Übertragungen wie Backups in getrennten Serviceklassen behandeln - [RFC 7567: IETF Recommendations Regarding Active Queue Management](https://www.rfc-editor.org/rfc/rfc7567) · IETF · Kommt mehr in ein Gerät hinein, als es ausgeben kann, bilden sich Warteschlangen, übermäßige Warteschlangen sind eine Hauptursache für Latenz - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifHCInOctets, ifHCOutOctets: über das Interface empfangene bzw. gesendete Bytes (64 Bit), ifOutDiscards: Zahl der Pakete, die nicht gesendet werden konnten und verworfen wurden #### dc-failover · Failover von Netzwerkgeräten · Network device failover Fällt ein Router oder eine Firewall aus und wird auf das Ersatzgerät umgeschaltet (Failover), haben alle Spieler einige Sekunden lang einen Freeze. - Warum → Folge → Auf dem Bildschirm: Umschalten auf das Ersatzgerät wegen Ausfall oder Wartung → Umschalten dauert einige Sekunden, ohne synchronisierte Session-Informationen werden Verbindungen zurückgesetzt → Alle Spieler des Servers gleichzeitig im Freeze, massenhaft Verbindungsabbrüche - Symptome: Freeze, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Timeouts, die kurze Aussetzer (einige Sekunden) verkraften, nach einem Abbruch die Session beim Reconnect per Session-Token fortsetzen. Client: bei Abbruch automatischer Reconnect (Wiederholungsabstände zufällig streuen, damit nicht alle gleichzeitig kommen). - Aufgaben Infrastrukturteam: Redundanz mit geteiltem Verbindungszustand, Ausfälle per BFD innerhalb von 1 s erkennen, Failover regelmäßig testen. - Größenordnungen: Erkennt das Gerät den Ausfall sofort, dauert es etwa 1–3 s. Ohne schnelle Ausfallerkennung (BFD), allein mit den Standard-Timern von BGP, kann die Route 90–180 s lang unterbrochen sein, bis Nachbargeräte den Ausfall bemerken. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungszahl, Sende- und Empfangsvolumen des ganzen Servers) - Wo nachsehen: Event-Logs von Routern und Firewalls (Rollenwechsel bei VRRP, Ausfall von BFD- oder BGP-Sessions, Failover-Einträge) mit Verbindungszahl und Sende- und Empfangsvolumen des ganzen Servers zur selben Zeit vergleichen - Spricht dafür: Zum Failover-Zeitpunkt im Geräte-Log fällt der Traffic aller Server hinter diesem Gerät für einige Sekunden auf 0, oder die Verbindungszahlen brechen gleichzeitig ein - Spricht dagegen: Nur die Verbindungen eines Servers brechen ein: „Serverabsturz“ oder „Probleme mit NIC-Treiber oder -Firmware“. Geräte-Logs sauber und der stehengebliebene Server ist eine einzelne Cloud-VM: „Wartung des Cloud-Hosts und Live-Migration“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 5880: Bidirectional Forwarding Detection (BFD)](https://www.rfc-editor.org/rfc/rfc5880) · IETF · Hello-Mechanismen von Routing-Protokollen brauchen mindestens 1 s zur Ausfallerkennung, BFD wurde für eine schnellere Erkennung entwickelt - [RFC 7938: Use of BGP for Routing in Large-Scale Data Centers](https://www.rfc-editor.org/rfc/rfc7938) · IETF · Wer sich nur auf BGP-Keepalives verlässt, konvergiert langsam. Wird ein Link-Down sofort übernommen und die Session beendet, erfolgen Erkennung und erneute Konvergenz im Millisekundenbereich - [RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6](https://www.rfc-editor.org/rfc/rfc5798) · IETF · VRRP-Advertisements standardmäßig alle 1 s, das Ersatzgerät übernimmt, wenn etwa das 3-Fache dieses Intervalls ohne Advertisement verstreicht (mit Standardeinstellungen gut 3 s) #### dc-bad-cable · Defekte Kabel und Portfehler · Bad cable / optics (CRC errors) Sind optische Module oder Kabel defekt, wird ein fester Anteil der Pakete auf diesem Pfad beschädigt. - Warum → Folge → Auf dem Bildschirm: Bitfehler durch defekte optische Module oder Kabel → Beschädigte Pakete verwirft das Gerät stillschweigend → Nur einige Server oder Spieler auf diesem Pfad: ständiger Paketverlust, Teleportieren und Rubberbanding - Symptome: Teleportieren, Rubberbanding / Faktoren: Paketverlust - Wer: Bestimmter Ort oder Kanal / Wann: Immer - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Portfehler-Zähler (CRC) überwachen und alarmieren, Komponenten wie optische Module oder Kabel tauschen, bis zum Tausch den betroffenen Link herausnehmen und umgehen. - Im Graphen: Nur einzelne Ausreißer (CRC-Fehler pro Port, Verlustrate pro Server und Pfad) - Wo nachsehen: CRC-Zähler an beiden Enden des Links prüfen. Am Switch FCS-Fehler (dot3StatsFCSErrors) und Eingangsfehler (ifInErrors) des Ports, am Server crc unter RX errors in ip -s -s link (Kernel-Statistik rx_crc_errors) - Spricht dafür: CRC-Fehler eines Ports steigen stetig, unabhängig von Traffic-Menge und Tageszeit, und nur Server und Spieler hinter diesem Port haben Paketverlust - Spricht dagegen: Keine CRC-Fehler, nur Ausgangsdrops steigen: Überlast („Microbursts am Switch“, „Vollauslastung der Rechenzentrumsanbindung“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017)](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/CorrOpt_SIGCOMM2017.pdf) · ACM · Analyse von 350.000 Links in Rechenzentren: Ursachen für Beschädigung sind defekte optische Module, beschädigte Fasern und verschmutzte Stecker, die Beschädigungsrate ist unabhängig von der Auslastung konstant, betroffene Links werden unter Wahrung der Pfadanzahl herausgenommen und repariert - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · Zähler für Frames mit fehlgeschlagener Prüfsumme (FCS): dot3StatsFCSErrors, diese Fehler werden zu den Eingangsfehlern (ifInErrors) addiert - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · rx_crc_errors: Zahl der mit CRC-Fehler empfangenen Pakete, Aufschlüsselung nach Fehlerart mit ip -s -s link #### dc-mtu · MTU-Mismatch (nur große Pakete verschwinden) · MTU black hole Ist die MTU (maximale Paketgröße pro Sendung) auf einem Abschnitt unterwegs kleiner und wird die Meldung „Paket zu groß“ blockiert, verschwinden ständig nur die großen Pakete. - Warum → Folge → Auf dem Bildschirm: MTU sinkt auf Tunnel- oder VPN-Strecken → Meldung „Paket zu groß“ (ICMP) wird von einer Firewall blockiert, der Sender erfährt nichts davon → Nur beim Öffnen großer Ansichten wie Inventar oder Charakterliste ein Freeze, dann Verbindungsabbruch - Symptome: Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Bestimmte Region oder Provider, Nur ich / Wann: Bei bestimmten Aktionen, Direkt nach Login oder Wartung - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Um die Größe serverseitig selbst zu senken, die maximale Segmentgröße des Sockets (TCP_MAXSEG) setzen (Nachrichten im Spielcode klein zu stückeln reicht allein nicht), UDP-Pakete auf höchstens 1.200 Byte begrenzen. - Aufgaben Infrastrukturteam: Netzwerk: TCP-Paketgröße auf Tunnelstrecken verringern (MSS-Clamping), „Paket zu groß“-Meldungen (ICMP) in Firewalls und Netzwerk-ACLs der Cloud erlauben. Server/OS: „Paket zu groß“-Meldungen (ICMP) auch in der Server-Firewall und in Cloud-Security-Groups erlauben, MTU-Probing im Server-Kernel aktivieren (tcp_mtu_probing=1, letztes Sicherheitsnetz, das erst nach einigen Sekunden Stillstand greift). - Größenordnungen: Meist 1.500 Byte, nach einem Tunnel nur noch etwa 1.400. - Im Graphen: Nur einzelne Ausreißer (Verbindungsabbrüche nach Region und Provider, fehlgeschlagene große Antworten) - Wo nachsehen: Vom PC des betroffenen Spielers Pings mit gesetztem Don't-Fragment-Bit (DF) und wechselnder Größe an den Server senden. Unter Windows ping /f /l 1472 SERVER_IP, unter Linux ping -M do -s 1472 SERVER_IP (1.472 ist MTU 1.500 minus 20 Byte IP-Header und 8 Byte ICMP-Header). Größe schrittweise verringern, bis die größte durchgehende Größe gefunden ist, und prüfen, ob Security Group und Firewall auf Serverseite die ICMP-Meldung „Paket zu groß“ (Fragmentation Needed) erlauben - Spricht dafür: Kleine Pings gehen durch, DF-Pings mit 1.472 Byte scheitern (keine Antwort oder Fehlermeldung, dass Fragmentierung nötig ist), und die größte durchgehende Größe liegt nur bei etwa 1.400. Spieler derselben Region haben nur beim Öffnen großer Ansichten einen Freeze - Spricht dagegen: Auch DF-Pings mit 1.472 Byte gehen durch: kein Path-MTU-Problem. Auch kleine Pings gehen nicht durch: ICMP ist komplett blockiert, mit dieser Methode nicht beurteilbar - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [RFC 2923: TCP Problems with Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc2923) · IETF · Blockiert eine Firewall ICMP (Fragmentation Needed), scheitert die Path-MTU-Discovery, und nur große Pakete verschwinden immer wieder (Blackhole), da Pings und kleine Übertragungen funktionieren, ist die Diagnose schwierig - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Path-MTU im Internet 1.500, nach einem GRE-Tunnel 1.476, Empfehlung: TCP-MSS auf höchstens 1.436 begrenzen - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_mtu_probing=1 ist normalerweise inaktiv und schaltet die TCP-Path-MTU-Discovery ein, sobald ein ICMP-Blackhole erkannt wird - [ping(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ping.8.html) · iputils · -M do setzt das DF-Bit und lehnt Pakete ab, die größer als die Path-MTU sind, -s legt die Datengröße fest (Standard 56 Byte plus 8 Byte ICMP-Header) - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /f setzt das DF-Bit und dient zur Suche nach Path-MTU-Problemen, /l legt die Datengröße fest ### L6 Netzwerkkarte des Servers (9 Ursachen) #### nic-irq · NIC-Interrupts auf nur einem Kern · Single-queue NIC / no RSS Schickt die NIC die Interrupts für eintreffende Pakete nur an einen CPU-Kern, wird dieser Kern zum Engpass. - Warum → Folge → Auf dem Bildschirm: Nur eine Empfangs-Queue oder RSS (Verteilung auf mehrere Kerne) deaktiviert → Ein Kern läuft auf 100 % und holt Pakete nicht rechtzeitig ab → Bei großem Andrang Paketverlust und Latenz auf dem ganzen Server (Teleportieren, Input-Lag) - Symptome: Teleportieren, Rubberbanding, Input-Lag / Faktoren: Paketverlust, Latenz - Wer: Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: RSS (Verteilung durch die NIC) und RPS (Verteilung durch den Kernel) konfigurieren, Interrupts auf mehrere Kerne verteilen, für UDP die Queue-Verteilung auch nach Ports einstellen (rx-flow-hash udp4 sdfn bei ethtool -N), Kerne für die Interrupt-Verarbeitung und Kerne für den Tick-Thread des Spiels trennen, %soft pro Kern überwachen. - Größenordnungen: Ein einzelner Kern schafft über den Kernel je nach Paketgröße und Konfiguration grob einige hunderttausend Pakete pro Sekunde. Konzentriert sich in der Auslastung pro Kern der Anteil der Empfangsverarbeitung (%soft in mpstat) auf einen einzigen Kern, liegt dieser Fall vor. - Im Graphen: Plateau am Limit (%soft pro Kern, empfangene Pakete pro Sekunde) - Wo nachsehen: Mit mpstat -P ALL 1 %soft pro Kern (Anteil der Software-Interrupt-Verarbeitung) prüfen, in /proc/interrupts nachsehen, an welche Kerne die Interrupts der einzelnen NIC-Queues gehen, mit ethtool -l die Zahl der Queues und mit ethtool -S die Pakete pro Queue prüfen (Namen je nach Treiber verschieden) - Spricht dafür: Nur ein Kern hängt bei %soft dauerhaft nahe 100 %, die übrigen sind frei, Interrupts und Pakete ballen sich in einer Queue. Ab dann steigen die empfangenen Pakete pro Sekunde nicht weiter - Spricht dagegen: %soft gleichmäßig auf mehrere Kerne verteilt: nicht diese Ursache. CPU frei, trotzdem Paketverlust: „Überschrittenes PPS-Limit in der Cloud“ oder „Zu kleiner Ringpuffer“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch bei mehreren Queues landet der Traffic in einer einzigen Queue, wenn er größtenteils von wenigen Adressen kommt, etwa von Gateways oder Proxys. Bei UDP verteilt die NIC-Standardeinstellung mitunter nur nach Adressen. Erst wenn auch die Ports einbezogen werden, verteilt sich die Last gleichmäßig. - Quellen: - [Scaling in the Linux Networking Stack](https://docs.kernel.org/networking/scaling.html) · Linux kernel · RSS (NIC verteilt auf mehrere Empfangs-Queues) und RPS (Kernel verteilt), Konfiguration mit eigenem Interrupt pro Queue, verteilt auf mehrere Kerne, RSS empfohlen, wenn die Verarbeitung von Empfangs-Interrupts der Engpass ist - [How to receive a million packets per second](https://blog.cloudflare.com/how-to-receive-a-million-packets/) · Cloudflare · Messung: Geht eine Empfangs-Queue nur an einen Kern, stößt dieser bei etwa 350.000–430.000 Paketen pro Sekunde an seine Grenze, Fall einer NIC, die UDP nur nach IP-Adresse hashte, sodass alles in einer Queue landete - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Option ethtool -N rx-flow-hash udp4, mit der auch die Ports (f, n) in den UDP-Hash einfließen - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · %soft: Anteil der Zeit, den die CPU für Software-Interrupts aufwendet, pro Kern mit -P ALL #### nic-ring · Zu kleiner Ringpuffer · RX ring buffer overflow Ist der Ringpuffer klein, in dem die NIC Pakete kurz ablegt, läuft er bei kurzen Lastspitzen über, und Pakete werden verworfen. - Warum → Folge → Auf dem Bildschirm: Ringpuffer steht auf dem kleinen Standardwert (je nach Treiber 256–2.048 Slots) → Bei einem Burst läuft der Puffer über, bevor die CPU die Pakete abholt → Paketverlust nur im Moment des Bursts (Teleportieren, verschluckte Skills). In den Logs des Spielservers keine Spur - Symptome: Teleportieren, Verschluckte Aktion / Rollback / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Ringpuffer vergrößern (ethtool -G), Drop-Zähler überwachen (z. B. rx_missed_errors in ethtool -S, Namen je nach Treiber verschieden). - Größenordnungen: Bei 1 Million Paketen pro Sekunde sind 1.024 Slots in etwa 1 ms voll. Kommt die CPU in dieser Zeit nur ein einziges Mal zu spät, läuft der Puffer über. Die meisten NICs lassen sich auf mehrere tausend Slots vergrößern. - Im Graphen: Vereinzelte Spitzen ohne Muster (Empfangsdrop-Zähler der NIC) - Wo nachsehen: Empfangsdrop-Zähler in ethtool -S (rx_missed_errors, rx_fifo_errors usw., Namen je nach Treiber verschieden) und missed in ip -s -s link in kurzen Intervallen erfassen, mit ethtool -g aktuelle und maximale Ringgröße prüfen - Spricht dafür: Im Moment des Bursts steigen die Drop-Zähler, und die aktuelle Ringgröße liegt weit unter dem Maximum. Mit größerem Ring sinken die Drops - Spricht dagegen: Drop-Zähler unverändert, trotzdem Paketverlust: nächste Stufe im Kernel („Zu kleine Socket-Puffer im Kernel“) oder Netzwerkabschnitt. %soft eines Kerns bei 100 %: „NIC-Interrupts auf nur einem Kern“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Linux Base Driver for Intel(R) Ethernet Network Connection (e1000)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000.html) · Linux kernel · e1000: standardmäßig 256 Empfangsdeskriptoren (Ring-Slots), auf bis zu 4.096 erweiterbar - [drivers/net/ethernet/intel/ice/ice.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ice/ice.h?h=v6.12) · Linux kernel · ice-Treiber: standardmäßig 2.048 Empfangsdeskriptoren, maximal 8.160 - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · Pakete, die das Gerät mangels Puffer verwirft, werden als rx_missed_errors gezählt, treiberspezifische Statistiken mit ethtool -S abrufen - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · -g zeigt die Ringgröße (aktuell und maximal), -G ändert sie, -S zeigt treiberspezifische Statistiken #### nic-coalesce · Zu starkes Interrupt-Coalescing · Interrupt coalescing Sammelt die NIC Pakete, um die CPU zu entlasten, und meldet sie gebündelt, verzögern sie sich um die Sammelzeit. - Warum → Folge → Auf dem Bildschirm: NIC sammelt für eine bestimmte Zeit oder Anzahl und meldet dann → Pakete warten während des Sammelns → Geringfügig höhere Latenz. Meist klein, bei zu starker Einstellung im Millisekundenbereich - Symptome: Input-Lag / Faktoren: Latenz - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Adaptives Coalescing nutzen, Werte auf den Spielserver abstimmen (ethtool -C). - Größenordnungen: Üblicherweise einige Dutzend bis einige hundert µs. Für Spiele meist vernachlässigbar, bei zu starker Einstellung aber bis in den Millisekundenbereich. - Im Graphen: Von Anfang an dauerhaft hoch (Umlaufzeit innerhalb desselben Rechenzentrums) - Wo nachsehen: Mit ethtool -c die aktuellen Coalescing-Einstellungen prüfen (adaptive-rx, rx-usecs, rx-frames) und die ping-Umlaufzeit zu anderen Servern im selben Rechenzentrum vor und nach der Änderung vergleichen - Spricht dafür: rx-usecs ist hoch eingestellt (mehrere hundert µs oder mehr), und eine Senkung verringert die Umlaufzeit im selben Rechenzentrum entsprechend - Spricht dagegen: Umlaufzeit bleibt trotz Senkung gleich: nicht diese Ursache - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Linux Driver for Intel(R) Ethernet Network Connection (e1000e)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000e.html) · Linux kernel · Standard ist adaptive Interrupt-Moderation mit 4.000–20.000 Interrupts pro Sekunde (Abstand 50–250 µs), weniger Interrupts sparen CPU, erhöhen aber die Latenz - [Linux Base Driver for Intel(R) Ethernet Network Connection (e1000)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000.html) · Linux kernel · Mit RxIntDelay lassen sich Empfangs-Interrupts in Schritten von 1,024 µs um bis zu 65.535 Einheiten (etwa 67 ms) verzögern, höhere Werte erhöhen die Empfangslatenz - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Einstellungen adaptive-rx, rx-usecs und rx-frames bei ethtool -C #### nic-cloud-pps · Überschrittenes PPS-Limit in der Cloud · Cloud PPS / bandwidth allowance Cloud-Server haben je nach Typ Limits für Pakete pro Sekunde und Bandbreite. Was darüber hinausgeht, wird stillschweigend verworfen. - Warum → Folge → Auf dem Bildschirm: Mehr gleichzeitige Spieler: Die Pakete pro Sekunde übersteigen das Limit der Instanz → Cloud-Netz verwirft den Überschuss → Teleportieren und verschluckte Skills durch unerklärlichen Paketverlust. Server-CPU hat Reserven - Symptome: Teleportieren, Verschluckte Aktion / Rollback / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Bei großem Andrang, Abendliche Stoßzeit - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Extern (Extern) - Aufgaben Entwicklungsteam: Pakete bündeln (Nachrichten eines Ticks in ein Paket), nicht häufig sehr kleine Pakete senden. - Aufgaben Infrastrukturteam: Zähler für Limitüberschreitungen prüfen (bei AWS pps_allowance_exceeded, conntrack_allowance_exceeded usw.) und alarmieren, größere Instanz wählen, das Connection-Tracking-Limit durch eine Security-Group-Konfiguration ohne Tracking umgehen. - Aufgaben Extern: Beim Cloud-Anbieter die Limits für Pakete pro Sekunde und Connection Tracking je Instanztyp erfragen. - Größenordnungen: Die Limits hängen von der Instanzgröße ab, und Limits für Pakete pro Sekunde werden oft nicht veröffentlicht. Die „bis zu 10 Gbps“ kleiner Instanzen sind eine Burst-Rate, die nur verfügbar ist, solange Credits übrig sind (meist 5–60 Minuten). Die normale Basisrate liegt deutlich darunter. - Im Graphen: Plateau am Limit (Pakete pro Sekunde, Allowance-Überschreitungszähler) - Wo nachsehen: ENA-Zähler pps_allowance_exceeded, bw_in_allowance_exceeded, bw_out_allowance_exceeded und conntrack_allowance_exceeded aus ethtool -S in kurzen Intervallen erfassen und zusammen mit den Paketen pro Sekunde betrachten. Mit dem CloudWatch-Agenten lassen sich diese Zähler auch an CloudWatch senden und mit Alarmen versehen - Spricht dafür: Zum Zeitpunkt des Paketverlusts steigen die Allowance-Zähler, und die Pakete pro Sekunde kommen über einen festen Wert nicht hinaus. Server-CPU hat Reserven - Spricht dagegen: Überschreitungszähler unverändert: nicht diese Ursache. %soft eines Kerns bei 100 %: „NIC-Interrupts auf nur einem Kern“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: conntrack_allowance_exceeded bedeutet, dass die Connection-Tracking-Tabelle voll war und neue Verbindungen verworfen wurden. Hat die Tabelle Reserven und brechen nur Idle-Verbindungen ab, weil ihr Tracking abläuft, lesen Sie den Eintrag „Ablauf des Connection Trackings in Cloud-Security-Groups“. - Quellen: - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Jede Instanz hat Limits für Bandbreite, PPS und Connection Tracking, Überschuss wird in Queues gepuffert und dann verworfen, Zähler pps_allowance_exceeded und conntrack_allowance_exceeded - [Amazon EC2 instance network bandwidth](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) · AWS · Die „bis zu N Gbps“ bei Instanzen mit höchstens 16 vCPUs sind ein Burst über Netzwerk-I/O-Credits (meist 5–60 Minuten), sind die Credits aufgebraucht, gilt wieder die Basisbandbreite #### nic-saturate · Vollauslastung der NIC-Bandbreite · NIC bandwidth saturation Wird eine 1-Gbps- oder 10-Gbps-Karte bis an ihre Grenze ausgelastet, wächst die Sende-Queue, und am Ende werden Pakete verworfen. - Warum → Folge → Auf dem Bildschirm: Mehr Broadcasts, die Sendemenge erreicht die Grenze der Karte → Sende-Queue wird länger, bei Überlauf werden Pakete verworfen → Latenz und Paketverlust auf dem ganzen Server (Input-Lag, Teleportieren) - Symptome: Input-Lag, Teleportieren / Faktoren: Latenz, Paketverlust - Wer: Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Sendemenge reduzieren (nur Sichtbereich, Kompression, nur Änderungen). - Aufgaben Infrastrukturteam: Karte aufrüsten (schnellere NIC, in der Cloud größere Instanz), Alarm auf die NIC-Auslastung. - Im Graphen: Plateau am Limit (NIC-Sendevolumen, Sendedrops) - Wo nachsehen: txkB/s und %ifutil (Auslastung relativ zur Interface-Geschwindigkeit) aus sar -n DEV 1 mit der NIC-Geschwindigkeit und der Instanzbandbreite vergleichen, dazu TX dropped in ip -s link prüfen - Spricht dafür: Sendevolumen bleibt flach nahe der Bandbreite von NIC oder Instanz, ab dann steigen Sendedrops und Latenz auf dem ganzen Server - Spricht dagegen: Bandbreite hat Reserven: nicht diese Ursache. Viele kleine Pakete und trotzdem Paketverlust: „Überschrittenes PPS-Limit in der Cloud“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · tx_dropped: Zahl der Pakete, die beim Senden mangels Ressourcen verworfen wurden - [Amazon EC2 instance network bandwidth](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) · AWS · Die für eine Instanz verfügbare Bandbreite richtet sich nach der Zahl der vCPUs (Instanzgröße) - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · rxkB/s, txkB/s und %ifutil (Auslastung relativ zur Interface-Geschwindigkeit) bei -n DEV #### nic-noisy · Virtualisierungs-Overhead und Noisy Neighbor · Noisy neighbors in virtualization Nutzen andere VMs auf demselben physischen Server viel Netzwerk oder CPU, verzögert sich die Verarbeitung auf dem eigenen Server unregelmäßig. - Warum → Folge → Auf dem Bildschirm: Andere VMs auf demselben physischen Server verbrauchen viele Ressourcen → Paketverarbeitung der eigenen VM verzögert sich unregelmäßig → Ohne erkennbaren Grund gelegentlich Jitter (Schwankung der Ankunftsabstände), es ruckelt - Symptome: Ruckeln / Faktoren: Jitter - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Extern (Extern) - Aufgaben Infrastrukturteam: Dedizierte Hosts oder Instanzen mit garantierter Leistung nutzen, Instanzen mit anhaltendem Jitter stoppen und neu starten, um sie auf einen anderen Host zu verschieben. - Aufgaben Extern: Problematischen Host beim Cloud-Anbieter melden. - Im Graphen: Vereinzelte Spitzen ohne Muster (Jitter der Umlaufzeit im selben Rechenzentrum, %steal) - Wo nachsehen: Dauerhaft ping an andere Server im selben Rechenzentrum senden, den Jitter der Umlaufzeit protokollieren und zusammen mit %steal aus mpstat mit anderen Instanzen gleicher Konfiguration vergleichen - Spricht dafür: Nur bei dieser Instanz schlagen Jitter der Umlaufzeit oder %steal unregelmäßig aus, andere Instanzen gleicher Konfiguration bleiben ruhig. Nach Stoppen und Neustart auf einem anderen Host ist es weg - Spricht dagegen: Alle Instanzen gleicher Konfiguration schlagen gleich aus: kein Host-Problem. Last auf dem Spielserver oder den Netzwerkabschnitt prüfen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [How EC2 instance stop and start works](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-stop-start-works.html) · AWS · Wird eine Instanz gestoppt und wieder gestartet, landet sie meist auf einem neuen Host (außer bei dedizierten Hosts) - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · %steal: Anteil der Zeit, in der diese virtuelle CPU zwangsweise warten musste, während der Hypervisor eine andere virtuelle CPU bediente #### nic-host-maintenance · Wartung des Cloud-Hosts und Live-Migration · Cloud host maintenance / live migration Wartet der Cloud-Anbieter einen physischen Server (Host), verschiebt er die VMs auf einen anderen Host (Live-Migration) oder hält sie kurz an. Währenddessen steht der ganze Server still, und dauert der Stillstand lange, brechen Verbindungen ab. - Warum → Folge → Auf dem Bildschirm: Anbieter verschiebt die VM wegen Host-Wartung oder vorhergesagtem Ausfall auf einen anderen Host oder pausiert sie kurz → Während der Verschiebung werden CPU, Arbeitsspeicher und Netzwerk langsamer, am Ende steht die VM kurz komplett still (je nach Anbieter und Verfahren unter 1 s bis etwa 30 s) → Alle auf dem Server gleichzeitig im Freeze, danach Zeitraffer und Teleportieren. Dauert der Stillstand länger als das Timeout: massenhaft Verbindungsabbrüche - Symptome: Freeze, Zeitraffer, Teleportieren, Verbindungsabbruch / Faktoren: Stillstand, Paketverlust - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Extern (Extern) - Aufgaben Entwicklungsteam: Timeouts so wählen, dass einige Sekunden Stillstand verkraftet werden, Zahl der nachzuholenden Ticks nach einem Stillstand begrenzen, verstrichene Zeit mit der Monotonic Clock messen, Ablauf festlegen, der bei einer Wartungsankündigung den Spielstand sichert und Spieler auf andere Server verschiebt. - Aufgaben Infrastrukturteam: Wartungsankündigungen abonnieren und alarmieren (Google Cloud maintenance-event, geplante Ereignisse von AWS und AWS Health, Azure Scheduled Events), nach einer Ankündigung den Server vorab zu einer Zeit mit wenigen Spielern austauschen, Wartungszeitpunkt verschieben, sofern der Anbieter das erlaubt (Azure Maintenance Configuration, je nach Typ geplante Ereignisse bei AWS), Wartungsprotokolle mit Störungsberichten abgleichen. - Aufgaben Extern: Beim Cloud-Anbieter Wartungsplan und Auswirkungen erfragen, wiederholte Stillstände derselben Instanz melden. - Größenordnungen: Laut Google ist die Pause bei einer Live-Migration in Compute Engine meist deutlich kürzer als 1 s, dabei kann die Systemuhr um bis zu 5 s vorspringen. Der Metadatenwert maintenance-event ändert sich 60 s vor der Verschiebung (sofern dieser Wert vorher mindestens einmal abgefragt wurde). Bei Azure dauern Wartungen, die keinen Neustart erfordern, fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migrationen meist höchstens 5 s. Azure Scheduled Events kündigt solche Pausen (Freeze) mindestens 15 Minuten vorher an. Fällt die Host-Hardware jedoch plötzlich aus, beginnt die Wiederherstellung sofort und ohne Ankündigung. - Im Graphen: Lücke, dann alles auf einmal (Gesendete und empfangene Pakete des Servers, Tick-Intervall) - Wo nachsehen: Zeitpunkt des Stillstands mit den Aufzeichnungen des Anbieters abgleichen. Google Cloud: compute.instances.migrateOnHostMaintenance im Audit-Log, AWS: geplante Ereignisse in describe-instance-status und AWS Health, Azure: Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll (Activity Log) und der Zeitpunkt, an dem die VM-Verfügbarkeitsmetrik (VmAvailabilityMetric) auf 0 fiel. Auf dem Server prüfen, ob Metriken und Logs während des Stillstands leer sind und die Uhr direkt danach gesprungen ist (Log der Zeitsynchronisation) - Spricht dafür: Der Stillstand des ganzen Servers fällt mit einem vom Anbieter protokollierten Wartungs- oder Migrationszeitpunkt zusammen, und in diesen Sekunden sind alle Metriken und Logs auf dem Server leer - Spricht dagegen: Nicht in den Aufzeichnungen des Anbieters, kurze Stillstände wiederholen sich häufig: „CPU-Steal (virtuelle Maschine)“. Kernel-Log enthält einen NIC-Reset: „Probleme mit NIC-Treiber oder -Firmware“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: AWS kündigt Wartungen über geplante Ereignisse (Scheduled Events) an. system-reboot bedeutet einen Neustart mit Umzug auf einen neuen Host, system-maintenance bedeutet, dass Netzwerk- oder Stromwartungen kurz Auswirkungen haben können. Selbst wenn der Stillstand nur einige Sekunden dauert, verdoppeln Clients, die in dieser Zeit keine ACKs für an den Server gesendete Pakete erhalten, ihre Wartezeit für Retransmissions immer weiter. Deshalb kann eine TCP-Verbindung auch nach dem Ende des Stillstands noch länger hängen („TCP-RTO und exponentielles Backoff“). Nach dem Aufwachen springt die Uhr, was zu „Sprung der Systemuhr (NTP-Step)“ führen kann, und Health-Checks des Load-Balancers können scheitern, sodass der Server vorübergehend herausgenommen wird. Instanzen, die sich nicht verschieben lassen (etwa Bare-Metal-Instanzen in Google Cloud), werden bei Wartungen gestoppt oder neu gestartet. - Quellen: - [Live migration process during maintenance events](https://cloud.google.com/compute/docs/instances/live-migration-process) · Google Cloud · Die Pause bei einer Live-Migration ist meist deutlich kürzer als 1 s, die Systemuhr springt dabei um bis zu 5 s vor, während der Verschiebung sinkt die Leistung von Disk, CPU, Arbeitsspeicher und Netzwerk kurzzeitig, VMs ohne Live-Migration werden bei Wartungen beendet (Bare-Metal-Instanzen unterstützen sie nicht) - [Query metadata server for maintenance event notices](https://cloud.google.com/compute/docs/metadata/getting-live-migration-notice) · Google Cloud · Der Metadatenwert maintenance-event ändert sich 60 s vor einer Live-Migration (sofern Live-Migration eingestellt ist und der Wert seit der letzten Wartung mindestens einmal abgefragt wurde) - [Monitor and plan for a host maintenance event](https://cloud.google.com/compute/docs/instances/monitor-plan-host-maintenance-event) · Google Cloud · Bei Wartungen erscheint im Audit-Log das Systemereignis compute.instances.migrateOnHostMaintenance - [Scheduled events for Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html) · AWS · Arten geplanter Ereignisse (system-reboot: Neustart mit Umzug auf einen neuen Host, system-maintenance: kurze Auswirkungen durch Netzwerk- oder Stromwartung), Benachrichtigung per E-Mail und AWS Health, Abfrage mit describe-instance-status, Zeitpunkt je nach Typ verschiebbar - [Maintenance and updates](https://learn.microsoft.com/en-us/azure/virtual-machines/maintenance-and-updates) · Microsoft Azure · Wartungen ohne Neustart pausieren fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migration meist höchstens 5 s, nach der Pause automatische Uhrsynchronisation, lange TCP-Verbindungen können abbrechen, oder die Gegenseite sendet Daten an die pausierte VM per exponentiellem Backoff erneut, was die Erholung verzögern kann, Health-Checks des Load-Balancers stufen die VM innerhalb von etwa 10 s als nicht gesund ein, Nachweis über Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll und die während der Pause auf 0 fallende VmAvailabilityMetric, Wahl des Zeitpunkts per Maintenance Configuration - [Scheduled Events for Linux VMs in Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/linux/scheduled-events) · Microsoft Azure · Freeze (Pause von einigen Sekunden, CPU und Netzwerk können stehen bleiben) wird mindestens 15 Minuten vorher angekündigt, bei Ausfall der Host-Hardware beginnt die Wiederherstellung sofort ohne Vorlaufzeit #### nic-reset · Probleme mit NIC-Treiber oder -Firmware · NIC hang / reset Hängt sich die Karte durch einen Treiberfehler oder eine fehlerhafte Funktion auf und startet neu, ist währenddessen jedes Senden und Empfangen unterbrochen. - Warum → Folge → Auf dem Bildschirm: Treiberfehler, fehlerhafte Offload-Funktion → NIC hängt und startet neu (einige Sekunden) → Alle auf diesem Server gemeinsam im Freeze, danach Teleportieren oder Verbindungsabbruch - Symptome: Freeze, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Gelegentlich, zufällig, Je länger es läuft - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Kernel-Log auf „transmit queue … timed out“ und „Link is Down“ prüfen und alarmieren, Treiber und Firmware aktualisieren, problematische Funktionen (Offload usw.) abschalten. - Im Graphen: Lücke, dann alles auf einmal (Gesendete und empfangene Pakete des Servers) - Wo nachsehen: Mit dmesg im Kernel-Log nach „NETDEV WATCHDOG … transmit queue N timed out“, Treiber-Resets sowie „Link is Down“ und „Link is Up“ suchen und die gesendeten und empfangenen Pakete des Servers zu diesem Zeitpunkt prüfen - Spricht dafür: Zum Zeitpunkt des Freezes stehen im Kernel-Log ein Sende-Queue-Timeout oder Link-Down/Up, und in diesen Sekunden sind gesendete und empfangene Pakete 0 - Spricht dagegen: Kernel-Log sauber und Switch-Port in Ordnung: Stillstand im Spielserverprozess („Stop-the-World-GC-Pause auf dem Server“, „Deadlock“) oder „Failover von Netzwerkgeräten“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [net/sched/sch_generic.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/sched/sch_generic.c?h=v6.12) · Linux kernel · Bleibt eine Sende-Queue hängen, protokolliert der Watchdog des Kernels „NETDEV WATCHDOG … transmit queue N timed out“ und ruft die Reset-Funktion des Treibers auf - [drivers/net/ethernet/intel/ixgbe/ixgbe_main.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?h=v6.12) · Linux kernel · Der ixgbe-Treiber setzt bei hängendem Senden den Adapter zurück und protokolliert bei Verbindungsverlust „NIC Link is Down“ - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Option ethtool -K, mit der sich Offload-Funktionen einzeln abschalten lassen #### nic-offload · Verzögerung durch GRO/LRO-Zusammenfassung · GRO/LRO batching Diese Funktion fasst mehrere Pakete zu einem zusammen, um die CPU zu entlasten. Je nach Einstellung wartet ein kleines Spielpaket dabei kurz auf das nächste Paket, mit dem es zusammengefasst werden kann. - Warum → Folge → Auf dem Bildschirm: NIC oder Kernel fasst eingetroffene Pakete zusammen und verarbeitet sie gebündelt → Ist hardwareseitiges Zusammenfassen (LRO) oder eine Wartezeit fürs Zusammenfassen aktiv, wartet das Paket kurz auf das nächste → Geringfügig höhere Latenz (meist höchstens einige Dutzend µs) - Symptome: Input-Lag / Faktoren: Latenz - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Auf den Spiel-Traffic abstimmen (LRO abschalten, Wartezeit fürs Zusammenfassen prüfen), da der Effekt meist klein ist, erst nach anderen Ursachen prüfen. - Im Graphen: Von Anfang an dauerhaft hoch (Umlaufzeit innerhalb desselben Rechenzentrums) - Wo nachsehen: Mit ethtool -k den Status von lro und gro prüfen, den sysfs-Wert gro_flush_timeout des Geräts ansehen und die Umlaufzeit kleiner Pakete im selben Rechenzentrum vor und nach der Änderung vergleichen - Spricht dafür: LRO ist aktiv oder gro_flush_timeout größer als 0, und nach Abschalten bzw. Setzen auf 0 sinkt die Umlaufzeit kleiner Pakete - Spricht dagegen: Unterschied nach der Änderung höchstens einige µs: nicht diese Ursache - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [NAPI](https://docs.kernel.org/networking/napi.html) · Linux kernel · Ein großer Wert für gro_flush_timeout bündelt die Verarbeitung, verursacht dafür aber bei geringer Last Latenz - [Linux Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Adapters (ixgbe)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/ixgbe.html) · Linux kernel · GRO fasst eingehenden Traffic zu großen Blöcken zusammen, um CPU zu sparen, und ist eine Weiterentwicklung von LRO - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Einstellungen gro und lro on|off bei ethtool -K ### L7 Server-OS (Kernel) (14 Ursachen) #### so-backlog · Überlauf der Verbindungswarteschlange (Backlog) · Listen backlog / SYN queue overflow Melden sich direkt nach einer Wartung Zehntausende gleichzeitig an, läuft die Verbindungswarteschlange (Backlog) des Kernels über, und Verbindungsversuche werden verworfen. - Warum → Folge → Auf dem Bildschirm: Nach Wartungsende strömen Verbindungen schneller herein, als der Spielserver sie per accept annimmt → Verbindungswarteschlange des Kernels (Backlog: der kleinere Wert aus dem listen-Argument im Servercode und dem Kernel-Limit) ist voll → Verbindungsversuche werden verworfen und immer wieder wiederholt: kein Login oder Endlos-Laden - Symptome: Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: listen-Wert im Code erhöhen, dafür sorgen, dass der Thread, der Verbindungen annimmt, nicht durch andere Arbeit aufgehalten wird, Login-Warteschlange einführen. Client: Abstände zwischen Verbindungsversuchen vergrößern (zufällig streuen). - Aufgaben Infrastrukturteam: somaxconn im Kernel erhöhen (wirkt nur, wenn auch der listen-Wert im Servercode steigt), SYN-Cookies aktiviert lassen, Überläufe überwachen (TcpExtListenOverflows in nstat). - Größenordnungen: Das Kernel-Limit (somaxconn) liegt unter Linux seit 5.4 standardmäßig bei 4096 (davor 128). Übergibt der Servercode listen einen kleineren Wert, gilt dieser als Grenze. Ist die Warteschlange voll, verwirft Linux Verbindungsanfragen still und ohne Fehlermeldung. Das Client-OS sendet die Anfrage nach 1 s und danach noch einige Male erneut. Für den Spieler sieht das deshalb eher nach langem Laden aus als nach „Verbindung fehlgeschlagen“. Ein Windows-Server schickt eine Ablehnung zurück, und der Client zeigt sofort „Verbindung fehlgeschlagen“. - Im Graphen: Ansturm direkt nach Login oder Wartung (Überläufe der Verbindungswarteschlange (ListenOverflows), Verbindungsversuche) - Wo nachsehen: Zuwachs von TcpExtListenOverflows und TcpExtListenDrops in nstat -az prüfen, mit ss -ltn Recv-Q (Verbindungen, die auf accept warten) und Send-Q (Backlog-Limit) des Listen-Sockets vergleichen - Spricht dafür: Zum Zeitpunkt des Ansturms steigt ListenOverflows, und Recv-Q des Listen-Sockets klebt am Wert von Send-Q - Spricht dagegen: ListenOverflows unverändert: diese Ursache scheidet aus. Verbindung steht, aber das Laden endet nicht: „Login-Ansturm und N+1-Queries“. Blockiert exakt ab einer bestimmten Spielerzahl: „Dateideskriptor-Limit“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Der Backlog von listen wird oberhalb von somaxconn stillschweigend gekürzt, somaxconn standardmäßig 4096 (seit 5.4, davor 128), bei voller Warteschlange darf die Anfrage ignoriert und die Wiederholung dem Client überlassen werden - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_syn_retries: Die Verbindungsanfrage (SYN) wird mehrmals erneut gesendet, erste Wartezeit vor der Retransmission 1 s, tcp_abort_on_overflow standardmäßig aus (keine Ablehnung bei Überlauf), tcp_syncookies standardmäßig an - [listen function (winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen) · Microsoft · Unter Windows erhält der Client bei voller Warteschlange den Fehler WSAECONNREFUSED - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtListenOverflows: Anzahl der Verbindungsanfragen (SYN), die verworfen wurden, weil die accept-Warteschlange voll war, dabei steigt auch TcpExtListenDrops - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=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 #### so-fd · Dateideskriptor-Limit · File descriptor limit (ulimit) Jede Verbindung braucht einen Dateideskriptor (fd, die Nummer, die das OS einer geöffneten Datei oder einem Socket zuweist). Wie viele fd ein Prozess öffnen darf, ist begrenzt. - Warum → Folge → Auf dem Bildschirm: Zahl gleichzeitiger Verbindungen erreicht das Dateideskriptor-Limit des Prozesses → Server nimmt keine neuen Verbindungen mehr an (Too many open files). Auch das Öffnen von Logs und DB-Verbindungen schlägt fehl → Ab einer exakten Spielerzahl kommt niemand mehr hinein: kein Login oder Endlos-Laden - Symptome: Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Direkt nach Login oder Wartung, Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Sockets beim Beenden einer Verbindung zuverlässig schließen (fd-Leck vermeiden), wenn accept mit EMFILE (keine fd frei) scheitert, kurz keine Verbindungen mehr annehmen oder sie mit einem vorab reservierten fd annehmen und sofort schließen (damit nicht dieselbe Verbindungsmeldung immer wieder verarbeitet und CPU verschwendet wird). - Aufgaben Infrastrukturteam: ulimit und Dienstkonfiguration (LimitNOFILE in systemd) prüfen, Alarm bei Annäherung an das Limit. - Größenordnungen: Ohne eigene Dienstkonfiguration liegt das Limit unter Linux noch oft bei 1024. Spielserver setzen es meist auf Zehntausende bis Hunderttausende hoch. Windows hat kein so niedriges Standardlimit. - Im Graphen: Plateau am Limit (Offene fd des Prozesses, gleichzeitige Verbindungen) - Wo nachsehen: Mit pidstat -v fd-nr (Zahl offener Dateideskriptoren) des Spielserver-Prozesses und in /proc/PID/limits das Limit für offene Dateien prüfen, im Serverlog nach accept-Fehlern suchen (EMFILE, Too many open files) - Spricht dafür: Zahl der fd bildet am Limit ein Plateau, ab diesem Zeitpunkt scheitert accept mit EMFILE - Spricht dagegen: fd-Zahl weit unter dem Limit: diese Ursache scheidet aus. Verbindungsanfragen werden schon im Kernel verworfen: „Überlauf der Verbindungswarteschlange (Backlog)“. Problem beim Connection Tracking: „Volle conntrack-Tabelle auf dem Server“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Nicht angenommene Verbindungen bleiben in der Verbindungswarteschlange (Backlog) des Kernels liegen. Je nach Servercode erhält der Server deshalb ständig die Meldung „neue Verbindung wartet“ und verschwendet CPU-Zeit. - Quellen: - [systemd-system.conf(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd-system.conf.5.html) · systemd · Standardwert von DefaultLimitNOFILE für Dienste ist 1024:524288 (Soft-Limit 1024) - [accept(2) — Linux manual page](https://man7.org/linux/man-pages/man2/accept.2.html) · Linux man-pages · Erreicht ein Prozess sein fd-Limit, scheitert accept mit EMFILE - [Maximum Number of Sockets Supported](https://learn.microsoft.com/en-us/windows/win32/winsock/maximum-number-of-sockets-supported-2) · Microsoft · Winsock unter Windows begrenzt die Zahl der Sockets nur durch den verfügbaren Speicher - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · fd-nr bei -v: Zahl der vom Prozess geöffneten Dateideskriptoren - [proc_pid_limits(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_pid_limits.5.html) · Linux man-pages · /proc/PID/limits enthält Soft- und Hard-Werte der Ressourcenlimits pro Prozess #### so-sockbuf · Zu kleine Socket-Puffer im Kernel · Small socket buffers Sind Sende- und Empfangspuffer zu klein, werden bei Burst-Traffic per UDP empfangene Pakete verworfen, und das Senden per TCP blockiert, weil im Puffer kein Platz mehr ist. - Warum → Folge → Auf dem Bildschirm: SO_SNDBUF und SO_RCVBUF auf Standardwert oder zu klein → Bei einem Burst oder während der Empfangs-Thread kurz stillsteht, läuft der UDP-Empfangspuffer über, und Pakete werden verworfen. TCP wartet, weil im Sendepuffer kein Platz ist → Teleportieren (UDP-Paketverlust) oder Zeitraffer (TCP wartet) - Symptome: Teleportieren, Zeitraffer / Faktoren: Paketverlust, Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Puffergrößen (SO_SNDBUF, SO_RCVBUF) im Code passend zum Traffic setzen, bei TCP beachten, dass eine fest gesetzte Größe das automatische Tuning von Linux abschaltet, Puffer nicht zu groß wählen, weil sich sonst veraltete Daten stauen und die Latenz steigt, Empfangs-Thread nicht blockieren lassen. - Aufgaben Infrastrukturteam: Kernel-Obergrenzen (rmem_max, wmem_max; auch im Code gesetzte Puffergrößen können sie nicht überschreiten) und Standardwert (rmem_default) anpassen, Zähler für Pufferüberläufe (RcvbufErrors) überwachen. - Größenordnungen: Der Standard-Empfangspuffer für UDP liegt unter Linux bei etwa 208 KB. Selbst ein kleines Paket belegt deutlich mehr Kernelspeicher als seine eigentliche Größe, deshalb ist der Puffer schon nach einigen Dutzend bis einigen hundert Paketen voll. Bei einem Server, der 100.000 Pakete pro Sekunde empfängt, reicht ein Stillstand des Empfangs-Threads von wenigen Millisekunden für einen Überlauf. - Im Graphen: Vereinzelte Spitzen ohne Muster (Überläufe des UDP-Empfangspuffers (UdpRcvbufErrors)) - Wo nachsehen: Zuwachs von UdpRcvbufErrors in nstat -az und skmem in ss -uamn prüfen (rb: Größe des Empfangspuffers, d: Pakete, die verworfen wurden, weil sie nicht mehr in den Socket passten), bei TCP in skmem von ss -tm prüfen, ob der Sendepuffer-Speicher (w) die Größe des Sendepuffers (tb) erreicht - Spricht dafür: Bei einem Burst oder Stillstand des Empfangs-Threads steigt UdpRcvbufErrors (oder d am Socket), rb liegt nahe am Standardwert (ca. 208 KB). Bei TCP klebt w an tb, und send blockiert - Spricht dagegen: Zähler unverändert, trotzdem Paketverlust: NIC-Ebene („Zu kleiner Ringpuffer“) oder Netzwerkstrecke - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Standardwerte von SO_RCVBUF und SO_SNDBUF sind rmem_default und wmem_default, Obergrenzen rmem_max und wmem_max, der Kernel verdoppelt den gesetzten Wert - [include/net/sock.h (Linux v6.18)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/sock.h?h=v6.18) · Linux kernel · Standard-Socket-Puffer definiert als 256 Pakete zu 256 Byte einschließlich sk_buff-Overhead (SKB_TRUESIZE(256)×256), auch kleine Frames zählen mit sk_buff+MTU (die ca. 208 KB sind ein für x86-64 berechneter Wert) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rmem, tcp_wmem: Wer SO_RCVBUF oder SO_SNDBUF selbst setzt, schaltet das automatische Tuning für diesen Socket ab - [net/ipv4/udp.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/udp.c?h=v6.12) · Linux kernel · Übersteigt die UDP-Empfangswarteschlange die Größe des Socket-Puffers, werden Pakete sofort verworfen, und RcvbufErrors steigt - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Von nstat angezeigte Zählernamen: RcvbufErrors und SndbufErrors der Gruppe Udp - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · skmem bei -m: rb Größe des Empfangspuffers, tb Größe des Sendepuffers, w Sendepuffer-Speicher, d Pakete, die vor dem Einreihen in den Socket verworfen wurden #### so-context · Zu viele Threads und Kontextwechsel · Thread oversubscription, context switching Laufen weit mehr Threads als Kerne, verbraucht das OS CPU-Zeit allein damit, sie abwechselnd auszuführen. - Warum → Folge → Auf dem Bildschirm: Hunderte bis Tausende Threads, etwa ein eigener Thread pro Verbindung → Mehr Aufwand für Kontextwechsel (Wechsel des laufenden Threads) und mehr Cache-Misses → CPU ausgelastet, aber geringer Durchsatz und unregelmäßige Ticks: Ruckeln und Zeitlupe - Symptome: Ruckeln, Zeitlupe / Faktoren: Stillstand, Jitter - Wer: Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Thread-Zahl an die Kernzahl anpassen, asynchrone I/O (epoll, IOCP). - Aufgaben Infrastrukturteam: Zahl der Kontextwechsel und der auf CPU-Zeit wartenden Threads überwachen (cs und r in vmstat). - Größenordnungen: Ein Kontextwechsel kostet einige µs, mit den anschließenden Cache-Misses noch mehr. - Im Graphen: Steigt mit Spielerzahl und Last (Kontextwechsel pro Sekunde, auf CPU-Zeit wartende Threads) - Wo nachsehen: In vmstat 1 cs (Kontextwechsel pro Sekunde) und r (laufende oder auf CPU-Zeit wartende Prozesse) mit der Kernzahl vergleichen, mit pidstat -w -t freiwillige (cswch/s) und unfreiwillige (nvcswch/s) Kontextwechsel pro Thread des Spielservers prüfen - Spricht dafür: Mit steigender Spielerzahl wächst r weit über die Kernzahl, cs schießt mit hoch, und Hunderte Threads haben viele unfreiwillige Kontextwechsel - Spricht dagegen: r bleibt höchstens bei der Kernzahl: diese Ursache scheidet aus. Nur viele freiwillige Wechsel: Threads warten auf Locks oder I/O („Lock-Contention“, „Blockierende I/O-Architektur“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Quantifying The Cost of Context Switch (ExpCS 2007)](https://www.usenix.org/legacy/events/expcs07/papers/2-li.pdf) · ACM · Direkte Kosten eines Kontextwechsels ca. 3,8 µs, indirekte Kosten einschließlich Cache-Effekten von einigen µs bis über 1.000 µs (in der Messumgebung) - [vmstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/vmstat.8.html) · procps-ng · Spalten cs (Kontextwechsel pro Sekunde) und r (Zahl der laufenden oder auf Ausführung wartenden Prozesse) - [I/O Completion Ports](https://learn.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports) · Microsoft · Viele asynchrone I/O-Vorgänge mit einem vorab erzeugten Thread-Pool und IOCP abwickeln, Zahl gleichzeitig laufender Threads an die Parallelität der CPU anpassen - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · cswch/s bei -w: freiwillige Kontextwechsel, bei denen ein Thread beim Warten auf Ressourcen selbst anhält, nvcswch/s: unfreiwillige Kontextwechsel, erzwungen nach Ablauf der Zeitscheibe, -t: pro Thread #### so-steal · CPU-Steal (virtuelle Maschine) · CPU steal time Während der physische Server (Hypervisor) die CPU-Zeit einer virtuellen Maschine kurz an eine andere VM vergibt (CPU-Steal), steht der Spielserver still. - Warum → Folge → Auf dem Bildschirm: Andere VM auf demselben Host verbraucht viel CPU → Eigene VM kommt immer wieder für einige bis einige Dutzend ms nicht zum Zug → Unerklärliche Sprünge der Tick-Zeit: Ruckeln und Freezes - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Extern (Extern) - Aufgaben Infrastrukturteam: Steal-Metrik überwachen (st in top und vmstat), dedizierte Kerne oder Hosts nutzen, Burstable-Instanzen meiden, die nach aufgebrauchten CPU-Credits langsamer werden, Instanzen mit dauerhaft hohem Steal stoppen und neu starten, damit sie auf einen anderen Host wechseln. - Aufgaben Extern: Hosts mit dauerhaft hohem Steal an den Cloud-Anbieter melden. - Im Graphen: Vereinzelte Spitzen ohne Muster (%steal, Server-Tick-Zeit) - Wo nachsehen: %steal aus mpstat -P ALL 1 auf derselben Zeitachse wie die Server-Tick-Zeit darstellen - Spricht dafür: Zu den Tick-Spitzen schlägt auch %steal aus, nach Stoppen und Neustart auf einem anderen Host geht der Wert zurück - Spricht dagegen: %steal nahe 0, Tick springt trotzdem: Ursache im Spielserver selbst („Stop-the-World-GC-Pause auf dem Server“, „Lock-Contention“). Im Container: „CPU-Throttling im Container (CFS-Quota)“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal: Zeit, die in virtualisierten Umgebungen verloren geht, weil ein anderes Betriebssystem ausgeführt wird - [Standard mode for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) · AWS · Burstable-Instanzen überschreiten die Basisleistung mit Credits, sind die Credits aufgebraucht, sinkt die CPU-Auslastung auf das Basisniveau - [How EC2 instance stop and start works](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-stop-start-works.html) · AWS · Wird eine Instanz gestoppt und wieder gestartet, landet sie meist auf einem neuen Host - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · %steal: Anteil der Zeit, in der diese virtuelle CPU zwangsweise warten musste, während der Hypervisor eine andere virtuelle CPU bediente #### so-cpu-quota · CPU-Throttling im Container (CFS-Quota) · Container CPU throttling (CFS quota) Hat ein Container ein CPU-Limit und verbraucht er sein Kontingent innerhalb der festen Periode (meist 100 ms), wird er für den Rest der Periode zwangsweise angehalten (Throttling). - Warum → Folge → Auf dem Bildschirm: CPU-Limit (limit) für den Spielserver-Container, etwa in Kubernetes → Bei einer Häufung von Tick-Berechnungen ist das Kontingent aufgebraucht, Stillstand von einigen Dutzend ms bis zur nächsten Periode → Durchschnittliche CPU niedrig, aber der Tick schlägt periodisch aus: Ruckeln und Zeitlupe - Symptome: Ruckeln, Zeitlupe / Faktoren: Stillstand, Jitter - Wer: Ganzer Server / Wann: Bei großem Andrang, Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Zahl der Worker-Threads an das CPU-Limit anpassen (damit die Runtime nicht so viele Threads erzeugt, wie der ganze Host Kerne hat). - Aufgaben Infrastrukturteam: CPU-Limit großzügig bemessen oder weglassen und dedizierte Kerne zuweisen, Zahl der Throttling-Ereignisse (nr_throttled) überwachen. - Größenordnungen: Arbeiten auf einem Server mit einem Limit von 2 Kernen 8 Threads gleichzeitig, ist das Kontingent der 100-ms-Periode nach 25 ms verbraucht, und es folgen 75 ms Stillstand. - Im Graphen: Steigt mit Spielerzahl und Last (Throttling-Ereignisse (nr_throttled), Server-Tick-Zeit) - Wo nachsehen: Zuwachs von nr_throttled und throttled_usec (cgroup v1: nr_throttled und throttled_time) in cpu.stat der Container-cgroup zusammen mit der Server-Tick-Zeit prüfen - Spricht dafür: Durchschnittliche CPU-Auslastung liegt unter dem Limit, trotzdem steigen nr_throttled und throttled_usec ständig, zeitgleich mit den Tick-Spitzen - Spricht dagegen: nr_throttled steigt nicht: diese Ursache scheidet aus. Gerät die VM selbst ins Hintertreffen: „CPU-Steal (virtuelle Maschine)“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [CFS Bandwidth Control](https://docs.kernel.org/scheduler/sched-bwc.html) · Linux kernel · Ist das pro Periode zugeteilte Kontingent aufgebraucht, halten die Threads bis zur nächsten Periode an (Throttling), Standardperiode 100 ms, Statistik nr_throttled - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · cpu.max hat das Format „$MAX $PERIOD“ (Kontingent, Periode), Standardwert „max 100000“ (Periode 100 ms) - [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) · Kubernetes · Das CPU-Limit eines Containers ist eine harte Grenze, die der Kernel per CPU-Throttling durchsetzt #### so-cstate · Latenzspitzen durch Energieverwaltung des Servers (C-States und Frequenzskalierung) · CPU power management latency (C-states, frequency scaling) Ungenutzte CPU-Kerne gehen zum Stromsparen in tiefe Energiesparzustände (C-States) und senken ihren Takt. Kommt ein Paket oder ein Timer, brauchen sie Zeit zum Aufwachen und Hochtakten, und die Verarbeitung kleiner Pakete verzögert sich. - Warum → Folge → Auf dem Bildschirm: Frequenzrichtlinie (Governor) des OS oder Energieeinstellungen im BIOS erlauben tiefe C-States und niedrige Taktfrequenzen → Ein ruhender Kern braucht beim Aufwachen aus einem tiefen Energiesparzustand jedes Mal bis zu mehrere hundert µs, und bei dauerhaft niedrigem Takt wird schon die Tick-Berechnung langsamer → Meist kaum spürbar, bei vielen Aufrufen zwischen Servern summiert es sich aber: Input-Lag, gerade wenn wenig los ist. Bei dauerhaft niedrigem Takt geraten die Ticks bei großem Andrang in Verzug: Zeitlupe - Symptome: Input-Lag, Zeitlupe / Faktoren: Latenz, Jitter, Stillstand - Wer: Ganzer Server / Wann: Immer, Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Energieeinstellungen im BIOS auf Leistung stellen, OS-Governor auf performance setzen (scaling_governor von cpufreq), auf latenzkritischen Servern tiefe C-States begrenzen (tuned-Profil latency-performance, /dev/cpu_dma_latency von PM QoS, Kernelparameter intel_idle.max_cstate), nach der Änderung Umlaufzeit innerhalb des Rechenzentrums, Jitter der Tick-Zeit und Stromverbrauch gemeinsam vergleichen. - Größenordnungen: Laut der Tabelle des Treibers intel_idle in Linux 6.12 braucht der flache C1-Zustand von Intel-Server-CPUs 1–2 µs zum Aufwachen, der tiefe C6-Zustand 133 µs (Skylake-SP) bis 290 µs (Sapphire Rapids). Einzeln ist das wenig, doch läuft eine Anfrage über mehrere Server, summiert es sich entsprechend. Der Kernel wählt umso tiefere Zustände, je länger die erwartete Leerlaufzeit ist. Deshalb tritt das Problem auf ruhigen Servern, bei denen Pakete nur vereinzelt eintreffen, häufiger auf. Der Governor powersave des generischen cpufreq fixiert die niedrigste erlaubte Frequenz (der gleichnamige Algorithmus von intel_pstate regelt dagegen lastabhängig). - Im Graphen: Von Anfang an dauerhaft hoch (Umlaufzeit innerhalb des Rechenzentrums, Kerntaktfrequenz) - Wo nachsehen: Mit cpupower monitor den Anteil der Verweildauer in den C-States und die tatsächliche Frequenz pro Kern prüfen, unter /sys/devices/system/cpu/cpu0/cpuidle/ für jeden state name, latency (Aufwachzeit in µs) und usage ablesen, scaling_governor von cpufreq und mit tuned-adm active das aktive Profil prüfen - Spricht dafür: Bei wenig Last verweilen Kerne lange im tiefsten C-State oder hängen nahe am Mindesttakt fest, mit performance-Governor und flachen C-States sinken Umlaufzeit und Jitter kleiner Anfragen - Spricht dagegen: Unterschied nach der Änderung höchstens einige Dutzend µs: diese Ursache ist vernachlässigbar. Spitzen im Millisekundenbereich: „CPU-Steal (virtuelle Maschine)“ oder eine andere Schicht - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Bei Bare-Metal-Servern im Rechenzentrum sind die Energieeinstellungen im BIOS (Firmware) und die OS-Einstellungen gemeinsam zu prüfen. In der Cloud kann das OS C-States und Taktfrequenz nur bei einigen Instanztypen ändern. Bei AWS steht die Standardeinstellung auf maximaler Leistung, man kann sie also meist unverändert lassen. Das tuned-Profil latency-performance der Red-Hat-Familie setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States. Abgeschaltetes Stromsparen erhöht den Stromverbrauch, deshalb nur auf latenzkritischen Servern anwenden. - Quellen: - [CPU Idle Time Management](https://docs.kernel.org/admin-guide/pm/cpuidle.html) · Linux kernel · Jeder Energiesparzustand hat eine Aufwachzeit (exit latency) und eine Mindestverweildauer (target residency), der tiefe Zustand wird passend zur erwarteten Leerlaufzeit gewählt, latency, usage und time pro state in sysfs, tiefe Zustände per PM QoS (/dev/cpu_dma_latency) und intel_idle.max_cstate begrenzen - [drivers/idle/intel_idle.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/idle/intel_idle.c?h=v6.12) · Linux kernel · Aufwachzeiten von Intel-Server-CPUs je C-State: Skylake-SP C1 2 µs, C1E 10 µs, C6 133 µs, Ice Lake C6 170 µs, Sapphire Rapids C1 1 µs, C6 290 µs - [CPU Performance Scaling](https://docs.kernel.org/admin-guide/pm/cpufreq.html) · Linux kernel · Governor mit scaling_governor prüfen und ändern, performance fordert die höchste erlaubte Frequenz an, powersave die niedrigste - [intel_pstate CPU Performance Scaling Driver](https://docs.kernel.org/admin-guide/pm/intel_pstate.html) · Linux kernel · Der Algorithmus powersave von intel_pstate regelt im Unterschied zum generischen powersave-Governor lastabhängig (ähnlich wie schedutil und ondemand) - [Chapter 2. Getting started with TuneD](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/getting-started-with-tuned_monitoring-and-managing-system-status-and-performance) · Red Hat · Das Profil latency-performance schaltet Stromsparfunktionen ab, setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States, aktives Profil mit tuned-adm active prüfen - [tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/power/cpupower/man/cpupower-monitor.1?h=v6.12) · Linux kernel · cpupower monitor: Frequenz und Statistik der Energiesparzustände pro Kern - [Processor state control for Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) · AWS · Nur bei einigen Instanztypen kann das OS C-States und P-States steuern und zur Latenzsenkung ändern, die Standardeinstellung ist maximale Leistung und passt für die meisten Workloads, Graviton hat eine feste Frequenz, die das OS nicht steuert #### so-oom · OOM-Killer · Out-of-memory killer Geht der Arbeitsspeicher aus, wählt Linux den Prozess mit dem größten Speicherverbrauch und beendet ihn zwangsweise. Meist trifft es den Spielserver. - Warum → Folge → Auf dem Bildschirm: Speicher durch ein Leck oder einen sprunghaften Anstieg erschöpft, oder Speicherlimit des Containers erreicht → Kernel beendet den Spielserver-Prozess zwangsweise → Verbindungsabbruch für alle auf diesem Server gleichzeitig, der jüngste Spielfortschritt geht per Rollback möglicherweise verloren - Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Je länger es läuft, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Leck beheben, Obergrenze für den Speicherverbrauch festlegen und bei Annäherung speichern und geordnet herunterfahren. - Aufgaben Infrastrukturteam: Speicheralarme einrichten, Speicherlimit des Containers an den tatsächlichen Verbrauch anpassen, steuern, welcher Prozess zuerst beendet wird (oom_score_adj). - Größenordnungen: Im Kernel-Log (dmesg) steht „Out of memory: Killed process“, in Kubernetes erscheint der Status OOMKilled. Windows hat keinen OOM-Killer. Dort scheitert eine Speicherzuweisung, und der Server stürzt häufig mit einem Fehler ab. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungen, Speicherverbrauch) - Wo nachsehen: Eintrag „Out of memory: Killed process“ in dmesg, bei Kubernetes OOMKilled im Pod-Status, bei cgroup v2 den Zuwachs von oom_kill in memory.events mit dem Zeitpunkt der Verbindungsabbrüche abgleichen - Spricht dafür: Zum Zeitpunkt der gleichzeitigen Verbindungsabbrüche ist das Beenden des Spielserver-Prozesses protokolliert, kurz davor stieg der Speicherverbrauch bis zum Limit - Spricht dagegen: Kein OOM-Eintrag, Prozess trotzdem beendet: Absturzlog und Core-Dump wie unter „Serverabsturz“ beschrieben prüfen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [mm/oom_kill.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/oom_kill.c?h=v6.12) · Linux kernel · Der Prozess mit dem größten Speicherverbrauch erhält die höchste Punktzahl (unter Berücksichtigung von oom_score_adj), beim Beenden wird „Out of memory: Killed process …“ protokolliert - [Assign Memory Resources to Containers and Pods](https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/) · Kubernetes · Überschreitet ein Container dauerhaft sein Speicherlimit (limit), wird er beendet und mit dem Status OOMKilled angezeigt - [Pushing the Limits of Windows: Virtual Memory](https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-virtual-memory) · Microsoft · Unter Windows scheitern bei erreichtem Commit-Limit Zuweisungen, die Speicher fest zusagen (committen), das kann zu Anwendungsfehlern oder Systemstörungen führen - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · oom_kill in memory.events: Zahl der Prozesse, die der OOM-Killer in dieser cgroup beendet hat #### so-reclaim · Stillstand durch Speicherrückgewinnung (Reclaim) und Compaction · Memory compaction / reclaim stalls (THP) Während das OS den Speicher kompaktiert, um große Seiten (Huge Pages) zu erzeugen, oder freien Speicher zurückgewinnt, steht der Prozess still. - Warum → Folge → Auf dem Bildschirm: Freier Speicher wird knapp, oder die Funktion für große Seiten (THP) startet eine Compaction → Thread, der Speicher anfordert, wartet, bis Reclaim oder Compaction fertig sind → Unregelmäßige Stillstände des Servers (einige bis mehrere hundert ms) - Symptome: Freeze, Ruckeln / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Je länger es läuft, Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Große Speicherzuweisungen zur Laufzeit reduzieren (beim Start vorab reservieren und wiederverwenden). - Aufgaben Infrastrukturteam: Große Seiten (THP) nur dort nutzen lassen, wo sie gebraucht werden (madvise), Schwelle für freien Speicher anheben (vm.min_free_kbytes u. a.). - Im Graphen: Vereinzelte Spitzen ohne Muster (Server-Tick-Zeit, Speicher-PSI) - Wo nachsehen: some und full in /proc/pressure/memory (Anteil der Zeit, in der Tasks auf Speicher warten und stillstehen) und den Zuwachs von compact_stall in /proc/vmstat zusammen mit der Server-Tick-Zeit prüfen, Einstellung /sys/kernel/mm/transparent_hugepage/defrag kontrollieren - Spricht dafür: Zu den Tick-Spitzen steigt die Speicher-PSI, und compact_stall nimmt zu. defrag steht auf always - Spricht dagegen: PSI und compact_stall unverändert: diese Ursache scheidet aus. Steigt die Swap-Nutzung: „Swap“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Transparent Hugepage Support](https://docs.kernel.org/admin-guide/mm/transhuge.html) · Linux kernel · Bei defrag=always werden Reclaim und Compaction direkt ausgeführt, wenn eine THP-Zuweisung scheitert, und der Prozess hält so lange an, bei madvise gilt das nur für angeforderte Bereiche - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · min_free_kbytes: Mindestmenge an freiem Speicher (Watermark), die der Kernel vorhält - [PSI - Pressure Stall Information](https://docs.kernel.org/accounting/psi.html) · Linux kernel · some (Anteil der Zeit, in der einige Tasks auf Speicher warten und stillstehen) und full (Anteil der Zeit, in der alle Tasks stillstehen) in /proc/pressure/memory #### so-timejump · Sprung der Systemuhr (NTP-Step) · Wall-clock jump (NTP step) Wird die Serveruhr auf einen Schlag um einige Sekunden vor- oder zurückgestellt, lösen Timer, die von der Systemuhr abhängen, gesammelt aus oder bleiben stehen. - Warum → Folge → Auf dem Bildschirm: Zeitsynchronisation stellt die Uhr auf einen Schlag stark um → Timer lösen gesammelt aus oder bleiben stehen, Timeouts werden falsch erkannt → Fehler bei Buffs und Cooldowns, Verbindungsabbrüche bei allen zugleich, Zeitraffer - Symptome: Zeitraffer, Verbindungsabbruch, Verschluckte Aktion / Rollback / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Verstrichene Zeit, Timeouts und Cooldowns mit einer Monotonic Clock berechnen, die weder springt noch zurückläuft, die Wall Clock nur für Anzeige und Protokollierung nutzen. - Aufgaben Infrastrukturteam: Uhr langsam nachführen (makestep von chrony nur direkt nach dem Start), Zustand der Zeitsynchronisation (Uhrenabweichung) überwachen. - Größenordnungen: ntpd stellt die Uhr bei einer Abweichung über 0,128 s auf einen Schlag. Kleinere Abweichungen gleicht er langsam aus, und zwar so langsam, dass 1 s Abweichung gut 30 Minuten braucht. Das heute verbreitete chrony stellt mit der empfohlenen Einstellung (makestep) nur einige Male direkt nach dem Start auf einen Schlag und gleicht danach langsam aus. Auch wenn eine virtuelle Maschine kurz angehalten wird und wieder aufwacht, springt die Uhr. - Im Graphen: Vereinzelte Spitzen ohne Muster (Ausgelöste Timer und Verbindungsabbrüche, Protokoll der Uhrenkorrekturen) - Wo nachsehen: Im Log des Zeitsynchronisationsdienstes nach großen sprunghaften Korrekturen suchen und mit dem Zeitpunkt der Auffälligkeit abgleichen. chrony schreibt Korrekturen, die größer als der Wert von logchange sind (Standard 1 s), ins syslog - Spricht dafür: Zum Zeitpunkt der Fehler bei Buffs und Cooldowns, der gleichzeitigen Verbindungsabbrüche oder des Zeitraffers ist eine Uhrenkorrektur protokolliert, und ihre Größe entspricht etwa dem Ausmaß der Auffälligkeit - Spricht dagegen: Keine Uhrenkorrektur protokolliert: diese Ursache scheidet aus. Bei VMs auch prüfen, ob sie angehalten wurden und wieder aufgewacht sind („Wartung des Cloud-Hosts und Live-Migration“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [ntpd - Network Time Protocol (NTP) daemon](https://www.ntp.org/documentation/4.2.8-series/ntpd/) · Network Time Foundation · Abweichungen über der Step-Schwelle von 128 ms werden auf einen Schlag korrigiert, kleinere langsam mit 0,5 ms pro Sekunde, sodass 1 s Abweichung 2.000 s (ca. 33 Minuten) braucht - [chrony – Frequently Asked Questions](https://chrony-project.org/faq.html) · chrony · Empfohlen ist, Steps nur einige Male direkt nach dem Start zu erlauben, etwa mit makestep 1 3, eine angehaltene und fortgesetzte VM kann mit falscher Uhrzeit aufwachen - [clock_gettime(2) — Linux manual page](https://man7.org/linux/man-pages/man2/clock_gettime.2.html) · Linux man-pages · CLOCK_MONOTONIC ist von unstetigen Sprüngen der Systemuhr nicht betroffen und läuft nie rückwärts - [chrony.conf(5)](https://chrony-project.org/doc/4.6/chrony.conf.html) · chrony · logchange: Korrekturen der Uhr, die größer als dieser Wert sind (Standard 1 s), werden ins syslog geschrieben #### so-cron · Zeitgesteuerte Jobs · Cron jobs (log rotation, backup, scans) Log-Komprimierung, Backups und Sicherheitsscans, die jeden Tag zur selben Zeit laufen, belegen CPU und Datenträger. - Warum → Folge → Auf dem Bildschirm: OS-Jobs starten zu festen Zeiten → Spielserver muss sich CPU und Datenträger mit ihnen teilen → Ruckeln und Zeitlupe zu festen Uhrzeiten, etwa jeden Tag um 4 Uhr morgens - Symptome: Ruckeln, Zeitlupe / Faktoren: Stillstand - Wer: Ganzer Server / Wann: In festen Abständen - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Startzeiten der Jobs verteilen, Priorität senken (nice, ionice), vom Spielserver trennen (auf einem eigenen Server ausführen). - Im Graphen: Spitzen in festen Abständen (CPU-Auslastung, Disk-Warteschlange, Server-Tick-Zeit) - Wo nachsehen: Startzeiten der Jobs aus crontab und systemctl list-timers sammeln, zum Zeitpunkt der Tick-Spitzen mit pidstat -u -d prüfen, welche Prozesse CPU und Datenträger belegen - Spricht dafür: Tick schlägt jeden Tag (oder jede Stunde) zur selben Zeit aus, und zu dieser Zeit belegen Job-Prozesse CPU und Datenträger - Spricht dagegen: Spitzen passen zu keiner festen täglichen Uhrzeit: diese Ursache scheidet aus. Spitzen alle paar Sekunden oder Minuten: „Stop-the-World-GC-Pause auf dem Server“, „Gleichzeitig auslösende Timer“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [ionice(1) — Linux manual page](https://man7.org/linux/man-pages/man1/ionice.1.html) · util-linux · Jobs der Klasse idle erhalten nur dann I/O, wenn kein anderes Programm auf den Datenträger zugreift - [systemd.timer(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.timer.5.html) · systemd · RandomizedDelaySec verzögert Jobs um einen zufälligen Wert und verringert so Lastspitzen - [systemctl(1) — Linux manual page](https://man7.org/linux/man-pages/man1/systemctl.1.html) · systemd · list-timers: zeigt Timer-Units sortiert nach der nächsten Ausführung - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -u zeigt CPU, -d Disk-I/O pro Prozess #### so-os-update · Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update · Performance regression after OS / kernel / driver / firmware update Der Spielcode ist unverändert, doch nach einem Update von Server-OS, Kernel, Treibern oder Firmware wird es langsamer. Updates können Standardwerte, den Scheduler, die Schutzmaßnahmen gegen CPU-Sicherheitslücken (Mitigations) und das Verhalten von Treibern ändern. - Warum → Folge → Auf dem Bildschirm: Kernel, Treiber oder Firmware ändern sich durch regelmäßige Sicherheitspatches oder ein neues Server-Image → Geänderte Standardwerte oder Scheduler oder neu aktivierte Mitigations: Dieselbe Arbeit kostet mehr CPU-Zeit, und Threads bekommen in anderer Reihenfolge CPU-Zeit → Ein bisher problemloser Server ist ab dem Update-Tag dauerhaft etwas langsamer: Input-Lag, bei großem Andrang Ruckeln und Zeitlupe - Symptome: Input-Lag, Ruckeln, Zeitlupe / Faktoren: Latenz, Stillstand, Jitter - Wer: Ganzer Server / Wann: Immer, Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Updates zuerst auf einigen Servern einspielen, Tick-Zeit, Latenz und CPU-Auslastung mit der Vorversion vergleichen und erst dann ausweiten, nicht am selben Tag wie Spiel-Patches ausrollen, Kernel-, Treiber- und Firmware-Versionen sowie wichtige sysctl-Werte vor und nach dem Update festhalten, bei Problemen zum Vergleich mit dem vorherigen Kernel booten, über das Abschalten der Mitigations (mitigations=off) erst nach Abwägung des Sicherheitsrisikos entscheiden. - Größenordnungen: Mit der Kernelversion ändert sich auch das Standardverhalten. Linux begann zum Beispiel mit 6.6, den Scheduler von CFS auf EEVDF umzustellen, und der Standardwert für das Limit der Verbindungswarteschlange (somaxconn) stieg mit 5.4 von 128 auf 4096. Mitigations gegen CPU-Sicherheitslücken verursachen zusätzliche Arbeit, etwa das Leeren CPU-interner Puffer beim Rücksprung vom Kernel ins Programm (nach jedem Systemaufruf) sowie bei Kontextwechseln und VM-Wechseln. Netzwerkserver, die für jedes Paket einen Systemaufruf machen, trifft das besonders. Manche Lücken lassen sich nur vollständig schließen, wenn SMT (ein Kern arbeitet wie zwei Threads) abgeschaltet wird, und ohne SMT sinkt die Leistung je nach Workload deutlich. Der Kernelparameter mitigations=off schaltet alle diese Mitigations ab und holt die Leistung zurück, lässt die Lücken aber offen. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (Server-Tick-Zeit, CPU-Auslastung, Latenz bei gleicher Last) - Wo nachsehen: Update-Verlauf des Paketmanagers und Neustartzeitpunkte, Kernelversion aus uname -r und NIC-Treiberinformationen aus ethtool -i mit dem Zeitpunkt des Latenzanstiegs abgleichen. Aktualisierte und nicht aktualisierte Server bei gleicher Last mit mpstat und pidstat vergleichen, ebenso den Zustand der Mitigations unter /sys/devices/system/cpu/vulnerabilities/ - Spricht dafür: Latenz und CPU-Auslastung steigen ab dem Neustart nach dem Update um eine Stufe und bleiben dort, bei gleicher Last sind nur die aktualisierten Server höher. Mit dem vorherigen Kernel oder Treiber gebootet, normalisieren sich die Werte - Spricht dagegen: Aktualisierte und nicht aktualisierte Server bei gleicher Last gleich langsam: diese Ursache scheidet aus. Wurde am selben Tag auch ein Spiel-Patch ausgerollt und haben sich Zahl oder Größe der Pakete pro Spieler geändert: „Patch verändert das Traffic-Muster“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Den Zustand der Mitigations zeigen die Dateien unter /sys/devices/system/cpu/vulnerabilities/. Der Standard (mitigations=auto) schützt bei eingeschaltetem SMT. Mit auto,nosmt wird SMT auf anfälligen CPUs abgeschaltet, und nach dem Kernel-Update kann sich die Zahl der logischen Kerne halbieren. Wird das OS am selben Tag wie ein Spiel-Patch aktualisiert, lässt sich die Ursache schwer eingrenzen. Beides deshalb getrennt ausrollen. - Quellen: - [The kernel’s command-line parameters](https://docs.kernel.org/admin-guide/kernel-parameters.html) · Linux kernel · mitigations=: off schaltet alle Mitigations gegen CPU-Sicherheitslücken ab und erhöht die Leistung, lässt die Lücken aber offen, Standard auto schützt bei eingeschaltetem SMT, auto,nosmt schaltet SMT bei Bedarf ab - [MDS - Microarchitectural Data Sampling](https://docs.kernel.org/admin-guide/hw-vuln/mds.html) · Linux kernel · Mitigations leeren CPU-Puffer beim Rücksprung vom Kernel in den User Space und beim Eintritt in eine VM, Zustand von Lücken und Mitigations in den Dateien unter /sys/devices/system/cpu/vulnerabilities/, bei vielen CPUs ist für vollständigen Schutz das Abschalten von SMT nötig, was je nach Workload die Leistung stark beeinträchtigt - [Spectre Side Channels](https://docs.kernel.org/admin-guide/hw-vuln/spectre.html) · Linux kernel · Als Mitigation werden bei Kontextwechseln und VM-Wechseln die Puffer der Sprungvorhersage geleert, starke Mitigations erzeugen Overhead für alle Programme - [EEVDF Scheduler](https://docs.kernel.org/scheduler/sched-eevdf.html) · Linux kernel · Linux begann mit 6.6, von CFS auf den Scheduler EEVDF umzustellen - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Standardwert von somaxconn stieg mit Linux 5.4 von 128 auf 4096 - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Treiberinformationen eines Netzwerkgeräts mit ethtool -i abfragen #### so-conntrack · Volle conntrack-Tabelle auf dem Server · conntrack table full Die Linux-Firewall erfasst jede Verbindung in der Tabelle für Connection Tracking (conntrack). Erreicht diese Tabelle ihr Limit, werden neue Pakete verworfen. - Warum → Folge → Auf dem Bildschirm: Mehr Tracking-Einträge durch Verbindungsansturm und häufige kurze Verbindungen → Tabelle voll, neue Verbindungen und einzelne Pakete werden verworfen → Kein Login, Teleportieren durch unerklärlichen Paketverlust - Symptome: Kein Login / Endlos-Laden, Teleportieren / Faktoren: Paketverlust - Wer: Ganzer Server / Wann: Direkt nach Login oder Wartung, Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: kurze Verbindungen reduzieren (Verbindungen für Aufrufe zwischen Servern wiederverwenden). Client: bei gescheitertem oder abgebrochenem Verbindungsaufbau die Abstände für neue Versuche schrittweise vergrößern und zufällig streuen. - Aufgaben Infrastrukturteam: Tabellengröße (nf_conntrack_max) erhöhen, Spielports vom Tracking ausnehmen (NOTRACK in der raw-Tabelle), Alarm auf die Auslastung. - Größenordnungen: Das Standardlimit liegt je nach Speicherausstattung des Servers bei etwa 60.000 bis 260.000 Einträgen. Bei einem Überlauf erscheint im Kernel-Log „nf_conntrack: table full, dropping packet“. - Im Graphen: Plateau am Limit (conntrack-Einträge (nf_conntrack_count)) - Wo nachsehen: net.netfilter.nf_conntrack_count (aktuelle Einträge) aus sysctl im selben Graphen wie nf_conntrack_max darstellen, in dmesg nach „nf_conntrack: table full, dropping packet“ suchen - Spricht dafür: nf_conntrack_count bildet an max ein Plateau, ab diesem Zeitpunkt erscheint table full im Kernel-Log - Spricht dagegen: Einträge weit unter max: diese Ursache scheidet aus. Das Connection-Tracking-Limit der AWS-Instanz selbst über conntrack_allowance_exceeded prüfen (siehe „Überschrittenes PPS-Limit in der Cloud“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Standardwert von nf_conntrack_max entspricht der Zahl der Hash-Buckets (nf_conntrack_buckets), die sich nach der Speichergröße richtet - [net/netfilter/nf_conntrack_core.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_core.c?h=v6.12) · Linux kernel · Standardgröße 65.536 bei über 1 GB Speicher, 262.144 bei über 4 GB (64 Bit), bei voller Tabelle wird „nf_conntrack: table full, dropping packet“ protokolliert und das Paket verworfen - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · Mit CT --notrack in der raw-Tabelle vom Connection Tracking ausnehmen #### so-ports · Erschöpfte ephemere Ports bei Verbindungen zwischen Servern · Ephemeral port exhaustion (TIME_WAIT) Baut der Spielserver Verbindungen zur DB oder zu anderen Servern häufig nur kurz auf und wieder ab, belegen beendete Verbindungen ihren Port noch eine Weile, und neue Verbindungen lassen sich nicht mehr öffnen. - Warum → Folge → Auf dem Bildschirm: Für jede Anfrage wird eine neue Verbindung geöffnet und geschlossen → Die zuerst schließende Seite hält den Port etwa 60 s lang (Linux) im Zustand TIME_WAIT, freie Ports gehen aus → Interne Anfragen scheitern: Speichern schlägt fehl, Funktionen melden Fehler - Symptome: Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Ganzer Server, Nur eine bestimmte Funktion / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Verbindungen wiederverwenden (Connection-Pool), nicht für jede Anfrage eine neue Verbindung öffnen und schließen. - Aufgaben Infrastrukturteam: Portbereich erweitern (ip_local_port_range), Wiederverwendung von TIME_WAIT bei ausgehenden Verbindungen prüfen (tcp_tw_reuse unter Linux), Zahl der TIME_WAIT-Sockets überwachen. - Größenordnungen: Der Standard-Portbereich von Linux (32768–60999) umfasst etwa 28.000 Ports. Bei mehr als 470 neuen Verbindungen pro Sekunde zur selben Zieladresse ist er erschöpft. Windows hat standardmäßig etwa 16.000 Ports (49152–65535) und ein längeres TIME_WAIT, dort gehen die Ports also noch schneller aus. - Im Graphen: Plateau am Limit (TIME_WAIT-Sockets, gescheiterte interne Verbindungen) - Wo nachsehen: Mit ss -tan state time-wait die TIME_WAIT-Sockets pro Zieladresse zählen, im Spielserver-Log nach connect-Fehlern (EADDRNOTAVAIL) suchen - Spricht dafür: TIME_WAIT zum selben Ziel (DB o. Ä.) bildet nahe der Größe des ephemeren Portbereichs (standardmäßig ca. 28.000) ein Plateau, und connect scheitert mit EADDRNOTAVAIL - Spricht dagegen: Wenig TIME_WAIT, aber nur Verbindungen nach außen scheitern: „Verbindungs- und Portlimits des Cloud-NAT-Gateways“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Die 60 s für TIME_WAIT sind unter Linux fest im Kernel verankert. Wer das ähnlich benannte tcp_fin_timeout senkt, verkürzt TIME_WAIT damit nicht. - Quellen: - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · ip_local_port_range standardmäßig 32768–60999, tcp_tw_reuse, tcp_fin_timeout ist die Verweildauer im Zustand FIN_WAIT_2 - [include/net/tcp.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_TIMEWAIT_LEN (60*HZ): Die ca. 60 s TIME_WAIT sind eine Kernel-Konstante - [TCP/IP port exhaustion troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting) · Microsoft · Dynamische Ports unter Windows standardmäßig 49152–65535, geschlossene Verbindungen halten ihren Port standardmäßig 4 Minuten im Zustand TIME_WAIT - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · Mit dem Statusfilter state time-wait nur TIME_WAIT-Sockets anzeigen - [connect(2) — Linux manual page](https://man7.org/linux/man-pages/man2/connect.2.html) · Linux man-pages · EADDRNOTAVAIL: Alle Ports des ephemeren Portbereichs sind belegt, deshalb lässt sich keine Verbindung öffnen ### L8 Sockets und Protokolle (14 Ursachen) #### sk-hol · TCP-Head-of-Line-Blocking · Head-of-line blocking Um die Reihenfolge einzuhalten, gibt TCP später eingetroffene Pakete erst an das Spiel weiter, wenn ein verlorenes Paket erneut angekommen ist. - Warum → Folge → Auf dem Bildschirm: Ein einzelnes Paket geht verloren → Die nachfolgenden Pakete sind angekommen, warten aber im Empfangspuffer → Stillstand, dann löst sich alles auf einmal: Zeitraffer - Symptome: Freeze, Zeitraffer / Faktoren: Paketverlust, Stillstand - Wer: Nur ich / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Echtzeitpositionen per UDP, nur Unverzichtbares zuverlässig übertragen, auf mehrere Streams aufteilen. Client: Netzwerkverarbeitung auf dasselbe Verfahren wie beim Server umstellen (UDP, getrennte Kanäle). - Größenordnungen: Geht ein Paket verloren, dauert der Stillstand mindestens eine Umlaufzeit und etwas mehr. Geht auch die Retransmission verloren, sind es mehrere hundert ms bis einige Sekunden. - Im Graphen: Lücke, dann alles auf einmal (Empfangsvolumen pro Verbindung, Retransmissions) - Wo nachsehen: Per Paketmitschnitt auf dem Server (tcpdump, Wireshark) in der Verbindung des Spielers die Retransmissions und die Lücken davor und danach prüfen, für den ganzen Server den Zuwachs von TcpRetransSegs in nstat -az ansehen - Spricht dafür: Die Stillstandsphase beginnt mit der Retransmission eines einzelnen Pakets, direkt nach dessen Eintreffen werden die aufgestauten Daten auf einmal verarbeitet (Empfangsvolumen erst bei 0, dann ein Schwall) - Spricht dagegen: Spiel kommuniziert per UDP: trifft nicht zu. Stillstand ohne Retransmission: Server-Tick prüfen („Überschrittenes Tick-Budget“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · TCP ist ein zuverlässiger Bytestream-Dienst, der die Reihenfolge einhält - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Verlust wird an 3 doppelten ACKs erkannt und per Fast Retransmit behoben, sonst wird auf den Retransmission-Timer gewartet - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Backoff, das den Retransmission-Timer bei jedem Ablauf verdoppelt - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Von nstat angezeigte Zählernamen: RetransSegs der Gruppe Tcp (Zahl erneut gesendeter Segmente) #### sk-rto · TCP-RTO und exponentielles Backoff · RTO and exponential backoff Mit jeder weiteren gescheiterten Retransmission verdoppelt sich die Wartezeit, und aus einer kurzen Leitungsunterbrechung wird ein langer Stillstand. - Warum → Folge → Auf dem Bildschirm: Leitung kurz unterbrochen, auch die Retransmissions scheitern nacheinander → Wartezeit bis zum nächsten Versuch verdoppelt sich jeweils, etwa 0,3 → 0,6 → 1,2 → 2,4 s (bei 100 ms Ping) → Leitung 1 s unterbrochen, Spiel steht über 2 s still. Bei längerer Unterbrechung am Ende Verbindungsabbruch - Symptome: Freeze, Verbindungsabbruch / Faktoren: Paketverlust, Stillstand - Wer: Nur ich / Wann: Gelegentlich, zufällig, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (Aufgabezeitpunkt per TCP_USER_TIMEOUT verkürzen), Session per Session-Token fortsetzen, zuverlässiges UDP. Client: Heartbeats in kurzen Abständen senden und bei ausbleibender Antwort schnell neu verbinden, ohne auf die TCP-Retransmission zu warten. - Größenordnungen: Das RTO (Wartezeit bis zur Retransmission) beträgt unter Linux mindestens „Ping + 200 ms“, beim Verbindungsaufbau beginnt es bei 1 s. Mit der Standardeinstellung (tcp_retries2=15) gibt Linux die Verbindung selbst bei dauerhaft scheiternden Retransmissions erst nach etwa 15 Minuten auf. - Im Graphen: Lücke, dann alles auf einmal (RTO und Backoff pro Verbindung, abgelaufene RTOs) - Wo nachsehen: Hängende Verbindung mit ss -ti auf rto (Wartezeit bis zur Retransmission in ms) und backoff (Zahl aufeinanderfolgender Abläufe) prüfen, für den ganzen Server den Zuwachs von TcpExtTCPTimeouts (abgelaufene Retransmission-Timer) in nstat -az ansehen - Spricht dafür: backoff der hängenden Verbindung ist mindestens 1, rto liegt im Sekundenbereich, und zur selben Zeit steigt TCPTimeouts - Spricht dagegen: Retransmissions enden per Fast Retransmit, kein RTO-Ablauf: Stillstand nur kurz. Dann eher „TCP-Head-of-Line-Blocking“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Erstes RTO 1 s, bei jedem Ablauf des Timers wird das RTO verdoppelt (exponentielles Backoff) - [net/ipv4/tcp_input.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · Linux-RTO = geglättete RTT + RTT-Schwankung, die Untergrenze der Schwankung ist tcp_rto_min (200 ms), daher ist das RTO mindestens RTT + 200 ms - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rto_min_us standardmäßig 200 ms, erstes RTO einer Verbindungsanfrage 1 s, mit tcp_retries2=15 dauert es bis zur Aufgabe mindestens 924,6 s (ca. 15 Minuten) - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (Retransmission-Timer, ms) und backoff (Zahl der exponentiellen Backoffs) bei -i - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Von nstat angezeigte Zählernamen: TCPTimeouts der Gruppe TcpExt - [net/ipv4/tcp_timer.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · Bei jedem Ablauf des Retransmission-Timers steigt TCPTimeouts, backoff wird um eins erhöht und das RTO verdoppelt (bis zum Maximum) #### sk-nagle · Nagle-Algorithmus + Delayed ACK · Nagle + delayed ACK (TCP_NODELAY off) Der Nagle-Algorithmus sammelt kleine Pakete, Delayed ACK schickt die Bestätigung verzögert. Zusammen verzögern beide jede in Teilen geschriebene Nachricht um 40–200 ms. - Warum → Folge → Auf dem Bildschirm: Kleine Nachrichten werden in Teilen geschrieben, ohne dass TCP_NODELAY aktiviert ist → Sender wartet auf das ACK, Empfänger schickt das ACK verzögert → Niedriger Ping, aber jede Aktion gleichmäßig träge: Input-Lag - Symptome: Input-Lag / Faktoren: Latenz - Wer: Ganzer Server, Nur ich / Wann: Immer, Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: TCP_NODELAY aktivieren, Nachrichten eines Ticks sammeln und in einem Schreibvorgang senden, sich nicht darauf verlassen, Delayed ACK beim Empfänger abzuschalten (TCP_QUICKACK unter Linux wirkt nur kurz, unter Windows ist ein Registry-Eingriff auf jedem PC nötig), denn das Spiel hat das nicht sicher unter Kontrolle. Client: TCP_NODELAY aktivieren, Nachrichten eines Frames sammeln und in einem Schreibvorgang senden. - Größenordnungen: Delayed ACK dauert unter Linux meist 40 ms (je nach Situation bis zu 200 ms). Bei Windows waren es in älteren Versionen 200 ms, in aktuellen sind es 40 ms (Standardvorlage von Windows Server 2019: 40 ms). Über Delayed ACK entscheidet das Betriebssystem des Empfängers. Sendet der Server Nachrichten bei aktivem Nagle in Teilen, kann es deshalb je nach empfangendem PC zu 40–200 ms Verzögerung kommen. - Im Graphen: Von Anfang an dauerhaft hoch (Antwortzeit auf Aktionen (RTT im Spiel)) - Wo nachsehen: Im Paketmitschnitt auf dem Server (tcpdump, Wireshark) die Abstände zwischen Anfrage und Antwort prüfen, kontrollieren, ob Server- und Client-Code TCP_NODELAY aktivieren - Spricht dafür: Niedriger Ping, aber zwischen kleinen Paketen wiederholen sich Lücken von rund 40 ms (bei älteren Windows-Versionen 200 ms), die direkt nach dem Eintreffen des ACK der Gegenseite enden. Mit TCP_NODELAY verschwinden sie - Spricht dagegen: Antwortabstände ähnlich dem Ping: diese Ursache scheidet aus. Erzeugt der Spielserver seine Antworten selbst verspätet: Serververarbeitung („Rückstau in der Message-Queue“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Nagle hält kleine Daten zurück, solange unbestätigte Daten unterwegs sind, muss pro Verbindung abschaltbar sein, Delayed ACK unter 0,5 s, Problem des Zusammenspiels beider - [include/net/tcp.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Linux-Delayed-ACK mindestens TCP_DELACK_MIN (HZ/25 = 40 ms), höchstens TCP_DELACK_MAX (HZ/5 = 200 ms) - [TCP improvements in the Windows network stack (IETF 98 TCPM)](https://datatracker.ietf.org/meeting/98/materials/slides-98-tcpm-tcp-improvements-in-windows-01) · Microsoft · Standard-Timeout für Delayed ACK unter Windows auf 40 ms geändert (Ankündigung 2017) - [TCP Templates for Windows Server 2019 – How to tune your Windows Server Transports (Advanced users only 😉)](https://techcommunity.microsoft.com/blog/networkingblog/tcp-templates-for-windows-server-2019-8211-how-to-tune-your-windows-server-trans/339795) · Microsoft · Vorlage für Server 2019: DelayedAckTimeout 40 ms, MaxSynRetransmissions 2, InitialRto 3000 ms - [Design issues - Sending small data segments over TCP with Winsock](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/windows/win32/data-segment-tcp-winsock) · Microsoft · Ältere Windows-TCP-Versionen starten beim Datenempfang einen Delayed-ACK-Timer von 200 ms, Nagle ist standardmäßig aktiv, sodass kleine Pakete auf das ACK warten, Abhilfe mit TCP_NODELAY #### sk-block-send · Blockierendes Senden durch langsame Clients · Blocking send on a full socket Ist der Sendepuffer eines einzelnen Spielers mit langsamer Leitung voll und sendet der Server blockierend (der Aufruf kehrt erst zurück, wenn im Puffer wieder Platz ist), wartet der Server-Thread auf diesen einen Spieler. - Warum → Folge → Auf dem Bildschirm: Sendepuffer eines langsamen Clients voll → Wegen blockierendem Senden wartet der Server-Thread, bis im Puffer wieder Platz ist → Alle, die dieser Thread bedient: Freeze oder Zeitlupe - Symptome: Freeze, Zeitlupe / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Nicht blockierend senden, Obergrenze für die Sende-Queue pro Client, veraltete Updates verwerfen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Server-Tick-Zeit, Send-Q pro Verbindung) - Wo nachsehen: Mit ss -tn Verbindungen suchen, deren Send-Q (unbestätigte oder noch nicht gesendete Bytes) den Sendepuffer füllt, im Moment der Tick-Spitze im Thread-Dump (Stack) des Spielservers prüfen, ob Threads im send-Aufruf hängen - Spricht dafür: Bei einer langsamen Verbindung mit voller Send-Q hängt der zuständige Thread in send, und nur die Spieler dieses Threads stehen mit still - Spricht dagegen: Hängende Threads warten außerhalb von send (Lock, DB-Aufruf): „Lock-Contention“, „Synchrone Aufrufe im Game-Thread“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [send(2) — Linux manual page](https://man7.org/linux/man-pages/man2/send.2.html) · Linux man-pages · Ist im Sendepuffer kein Platz, blockiert send(), im nicht blockierenden Modus kehrt der Aufruf sofort mit EAGAIN zurück - [send function (winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-send) · Microsoft · Auch bei Winsock blockiert send ohne Pufferplatz, außer im nicht blockierenden Modus - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=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 #### sk-slow-client · Strategie für langsame Clients (Slow Consumer) · Slow-consumer policy Bei einem Client, für den sich immer mehr zu sendende Daten anstauen, verwirft der Server veraltete Updates oder trennt die Verbindung. - Warum → Folge → Auf dem Bildschirm: Leitung des Clients kommt mit der Datenmenge des Servers nicht mit → Server verwirft veraltete Updates oder trennt bei Überschreiten des Limits die Verbindung → Nur bei diesem Spieler Teleportieren oder Verbindungsabbruch - Symptome: Teleportieren, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Sendevolumen senken (Update-Frequenz nach Entfernung), mit reduzierter Qualität weitersenden, im Kernel gepufferte Menge begrenzen (TCP_NOTSENT_LOWAT unter Linux). - Größenordnungen: Bei 256 KB Sendepuffer stauen sich auf einer Leitung mit 30 KB/s Daten für über 8 s an. Linux vergrößert diesen Puffer automatisch teils auf mehrere MB. - Im Graphen: Nur einzelne Ausreißer (Send-Q pro Verbindung, verworfene Updates pro Client) - Wo nachsehen: Vom Spielserver protokollierte Länge der Sende-Queue, verworfene Updates und Trennungsgründe pro Client prüfen, auf dem Server mit ss -tni Send-Q und cwnd dieser Verbindung zusammen kontrollieren - Spricht dafür: Nur bei Spielern mit Sprüngen oder Abbrüchen bleibt die Send-Q ständig gefüllt, und das Spiel-Log verzeichnet für sie verworfene Updates oder Trennungen wegen überlaufender Sende-Queue - Spricht dagegen: Send-Q leer, trotzdem Teleportieren: kein Problem beim Senden des Servers. Eher Paketverlust auf der Leitung des Spielers („Verlust auf der Funkstrecke“) oder die Interpolation auf dem Bildschirm - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_wmem: Maximum des automatisch angepassten Sendepuffers standardmäßig 64 KB bis 4 MB (je nach Speicher), tcp_notsent_lowat bzw. TCP_NOTSENT_LOWAT begrenzt die Menge noch nicht gesendeter Daten - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=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 #### sk-keepalive · Keepalive-Standardwert von 2 Stunden · TCP keepalive defaults Verschwindet die Gegenseite ohne Abschlusssignal, bemerkt TCP das erst sehr spät. Keepalive (eine TCP-Funktion, die prüft, ob eine Idle-Verbindung noch lebt) ist standardmäßig aus und beginnt selbst eingeschaltet erst nach 2 Stunden Leerlauf mit der Prüfung. - Warum → Folge → Auf dem Bildschirm: Client verschwindet ohne Abschlusssignal, weil der Strom ausfällt oder die Leitung abbricht → Server hält die Verbindung für lebendig (Keepalive standardmäßig 7.200 s, waren noch Daten unterwegs, ca. 15 Minuten bis zur Aufgabe der Retransmission) → Geistercharakter bleibt zurück, beim Reconnect Fehler „Bereits angemeldet“ - Symptome: Kein Login / Endlos-Laden, Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ich / Wann: Nach Inaktivität, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (TCP_KEEPIDLE und TCP_USER_TIMEOUT anpassen), beim Reconnect die bestehende Session per Session-Token ersetzen und fortsetzen. Client: Heartbeats auf Spielebene alle paar Sekunden bis einige Dutzend Sekunden senden (höchstens halb so lang wie das kürzeste Idle-Timeout), nach einem Abbruch automatisch neu verbinden. - Aufgaben Infrastrukturteam: Für Sockets, bei denen der Code nichts festlegt, die Kernel-Standardwerte (tcp_keepalive_time u. a.) senken (gilt nur für Sockets mit aktiviertem SO_KEEPALIVE). - Größenordnungen: Unter Linux beginnt die Prüfung standardmäßig nach 7.200 s Leerlauf. Dann werden 9 Probes im Abstand von 75 s gesendet, und bleibt jede Antwort aus, wird die Verbindung getrennt. Insgesamt sind das etwa 2 Stunden 11 Minuten. Auch Windows beginnt standardmäßig erst nach 2 Stunden Leerlauf mit der Prüfung. - Im Graphen: Nur einzelne Ausreißer (Zeit seit dem letzten Empfang pro Verbindung) - Wo nachsehen: Mit ss -tnoi pro Verbindung lastrcv (ms seit dem letzten Empfang) und den Keepalive-Timer (timer:(keepalive,…)) prüfen und mit den Ablehnungen „Bereits angemeldet“ des Spielservers abgleichen - Spricht dafür: Es bleiben ESTABLISHED-Verbindungen mit lastrcv von einigen Minuten bis einigen Stunden bestehen, und der Reconnect dieses Kontos wird mit „Bereits angemeldet“ abgelehnt - Spricht dagegen: Keine lange stillen Verbindungen, trotzdem „Bereits angemeldet“: Code zum Aufräumen von Sessions im Spielserver - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · Nach 7.200 s Leerlauf 9 Probes im Abstand von 75 s (ca. 11 Minuten zusätzlich), nur für Sockets mit aktiviertem SO_KEEPALIVE, TCP_KEEPIDLE, TCP_USER_TIMEOUT - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Keepalive muss standardmäßig aus sein, das Standard-Leerlaufintervall beträgt mindestens 2 Stunden - [SO_KEEPALIVE socket option](https://learn.microsoft.com/en-us/windows/win32/winsock/so-keepalive) · Microsoft · Standard-Timeout für TCP-Keepalive unter Windows: 2 Stunden - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · lastrcv bei -i (ms seit dem letzten Empfang), timer:(keepalive,…) bei -o #### sk-fragment · IP-Fragmentierung von UDP-Paketen · IP fragmentation of large UDP UDP-Pakete, die größer als die MTU (die maximale Größe, die auf einmal gesendet werden kann) sind, werden auf IP-Ebene fragmentiert. Geht nur ein Fragment verloren, wird das ganze Paket verworfen. - Warum → Folge → Auf dem Bildschirm: Snapshots aus belebten Gebieten überschreiten 1.500 Byte → In mehrere Fragmente aufgeteilt übertragen, fehlt eines, wird alles verworfen → Große Pakete gehen um ein Mehrfaches häufiger verloren. Teleportieren nur in belebten Gebieten - Symptome: Teleportieren / Faktoren: Paketverlust - Wer: Bestimmter Ort oder Kanal, Bestimmte Region oder Provider / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Pakete selbst auf höchstens 1.200 Byte aufteilen, nur Änderungen senden. - Größenordnungen: Auf einer Leitung mit 2 % Paketverlust gehen von Paketen, die in 4 Fragmente aufgeteilt sind, etwa 8 % verloren. Manche Firewalls und Provider verwerfen fragmentierte Pakete komplett. Betroffene Spieler erhalten dann kein einziges großes Paket. - Im Graphen: Steigt mit Spielerzahl und Last (Erzeugte IP-Fragmente (IpFragCreates), Snapshot-Größe) - Wo nachsehen: Auf dem Server den Zuwachs von IpFragCreates (beim Senden erzeugte Fragmente) in nstat -az prüfen, beim Empfänger IpReasmFails (gescheiterte Reassemblierungen). Verteilung der UDP-Paketgrößen per Spielserver-Log oder Paketmitschnitt prüfen - Spricht dafür: In belebten Gebieten steigt IpFragCreates, es gibt UDP-Pakete über 1.500 Byte, und gleichzeitig häufen sich Meldungen über Teleportieren - Spricht dagegen: IpFragCreates steigt nicht: auf der Sendeseite des Servers findet keine Fragmentierung statt - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Fehlt ein Fragment, scheitert die Reassemblierung, und das ganze Paket geht verloren, UDP-Anwendungen sollen IP-Fragmentierung vermeiden - [RFC 8900: IP Fragmentation Considered Fragile](https://www.rfc-editor.org/rfc/rfc8900) · IETF · Fälle, in denen Firewalls und einzelne Netze IP-Fragmente verwerfen - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Von nstat angezeigte Zählernamen: FragCreates (erzeugte Fragmente) und ReasmFails (gescheiterte Reassemblierungen) der Gruppe Ip #### sk-reliable-udp · Retransmission-Einstellungen bei zuverlässigem UDP · Reliable-UDP tuning (KCP, ENet…) Sind die selbst gebauten Retransmission-Regeln auf UDP zu vorsichtig, erholt sich die Übertragung erst spät. Sind sie zu aggressiv, verstopfen sie die Leitung zusätzlich. - Warum → Folge → Auf dem Bildschirm: Einstellungen für Retransmission-Intervall, Anzahl der Versuche und Window-Größe passen nicht zur Leitung → Späte Wiederherstellung oder mehr Überlast durch doppelt gesendete Daten → Verschluckte Skills, Zeitraffer, bei Überlast noch stärkerer Lag - Symptome: Verschluckte Aktion / Rollback, Zeitraffer / Faktoren: Paketverlust, Latenz - Wer: Nur ich / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Retransmission auf Basis der gemessenen Umlaufzeit, Kanäle nach Wichtigkeit trennen. Client: dieselben Retransmission- und Kanaleinstellungen wie der Server verwenden. - Im Graphen: Vereinzelte Spitzen ohne Muster (Retransmission-Rate bei zuverlässigem UDP, RTT im Spiel) - Wo nachsehen: Statistiken der verwendeten Bibliothek pro Verbindung (Retransmissions, geschätzte Umlaufzeit, Wartezeit bis zur Retransmission) auf Server und Client protokollieren und mit der tatsächlichen Verlustrate der Leitung desselben Spielers vergleichen (per mtr gemessen) - Spricht dafür: Retransmission-Rate um ein Mehrfaches höher als die tatsächliche Verlustrate der Leitung: zu aggressive Einstellung. Wartezeit bis zur Retransmission ein Mehrfaches der gemessenen Umlaufzeit: zu vorsichtige Einstellung - Spricht dagegen: Retransmission-Rate ähnlich der Verlustrate der Leitung und Wartezeit passend zur Umlaufzeit: kein Einstellungsproblem. Den Paketverlust der Leitung selbst untersuchen - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Retransmissions können Überlast verstärken und unterliegen daher der Congestion Control, die Umlaufzeit wird als gleitendes Mittel mehrerer Messungen (EWMA) geschätzt, Startwert 1 s, bei Timer-Ablauf Senderate senken #### sk-slowstart · Slow Start nach Leerlauf · Slow start after idle Nach einer Weile Leerlauf verkleinert TCP das Congestion Window (die Menge, die auf einmal gesendet werden darf) wieder. Werden dann plötzlich große Datenmengen gesendet, gehen sie in mehreren Etappen hinaus. - Warum → Folge → Auf dem Bildschirm: Über eine zuvor ruhende Verbindung werden große Datenmengen gesendet, etwa beim Betreten einer Stadt → Congestion Window ist geschrumpft, die Übertragung verteilt sich auf mehrere Round Trips → Direkt nach dem Betreten erscheinen Charaktere und NPCs in der Umgebung um einige Round Trips verspätet (je weiter weg der Server, desto auffälliger) - Symptome: Input-Lag, Unsichtbar / Geisterobjekte / Faktoren: Latenz - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel, Nach Inaktivität - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Daten beim Betreten reduzieren (Unverzichtbares zuerst senden). - Aufgaben Infrastrukturteam: tcp_slow_start_after_idle abschalten (Linux, gilt serverweit). - Größenordnungen: Bleibt eine Verbindung länger als ein RTO im Leerlauf, beginnt das Congestion Window zu schrumpfen. Nach langem Leerlauf fällt es auf etwa 14 KB (10 Pakete). 100 KB passen dann nicht mehr in einen Sendevorgang und brauchen 3 Round Trips. - Im Graphen: Nur einzelne Ausreißer (Übertragungszeit direkt nach dem Betreten (Spieler mit langer RTT)) - Wo nachsehen: Wert von sysctl net.ipv4.tcp_slow_start_after_idle prüfen und im Moment des Betretens eines Gebiets nach Leerlauf in ss -ti der Verbindung kontrollieren, ob cwnd (Congestion Window) geschrumpft ist - Spricht dafür: Einstellung steht auf 1 (Standard), beim Betreten nach Leerlauf schrumpft cwnd auf etwa 10, die Übertragung verteilt sich auf mehrere Round Trips. Je länger die RTT des Spielers, desto später erscheinen die Objekte, mit 0 verschwindet das Problem - Spricht dagegen: cwnd bleibt groß, Objekte erscheinen trotzdem spät: serverseitige Verarbeitung beim Betreten („Spawn-Flut beim Betreten belebter Gebiete“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_slow_start_after_idle standardmäßig an, nach Leerlauf über die Dauer eines RTO wird das Congestion Window verkleinert (Verfahren nach RFC 2861) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Wurde länger als ein RTO nichts gesendet, wird das Congestion Window auf höchstens das Restart Window min(IW, cwnd) verkleinert, danach Slow Start - [RFC 6928: Increasing TCP's Initial Window](https://www.rfc-editor.org/rfc/rfc6928) · IETF · Initial Window 10 Segmente, höchstens 14.600 Byte - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · cwnd (Congestion Window) und ssthresh (Slow-Start-Schwelle) bei -i #### sk-congestion · Einbruch der Senderate durch Congestion Control · Congestion control backoff TCP wertet Paketverlust als Zeichen von Überlast und senkt die Senderate um 30–50 %. Auf Paketverlust im WLAN reagiert es genauso. - Warum → Folge → Auf dem Bildschirm: Bei hohem Sendevolumen etwas Paketverlust im WLAN oder auf der Leitung → TCP senkt die Senderate deutlich und erholt sich nur langsam (CUBIC, Standard unter Linux und Windows, senkt um 30 %) → In belebten Gebieten stauen sich Updates: Zeitraffer und Input-Lag - Symptome: Zeitraffer, Input-Lag / Faktoren: Latenz, Stillstand - Wer: Nur ich / Wann: Bei großem Andrang - 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: - [RFC 9438: CUBIC for Fast and Long-Distance Networks](https://www.rfc-editor.org/rfc/rfc9438) · 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 - [TCP BBR congestion control comes to GCP – your Internet just got faster](https://cloud.google.com/blog/products/networking/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 - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_congestion_control wählt den Congestion-Control-Algorithmus für neue Verbindungen - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · cwnd und ssthresh bei -i sowie Name des Congestion-Control-Algorithmus - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=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 #### sk-linger · Verlust der letzten Daten durch harten Abbruch per RST · SO_LINGER, abrupt RST Trennt der Server eine Verbindung überstürzt, gehen der zuletzt gesendete Hinweis oder die Bestätigung des Speicherns verloren. - Warum → Folge → Auf dem Bildschirm: Server schließt die Verbindung per hartem Abbruch (RST). Passiert, wenn SO_LINGER auf 0 s steht oder geschlossen wird, bevor alle empfangenen Daten gelesen sind → Noch in Übertragung befindlicher Kick-Grund und letzte Daten werden verworfen → Grundlos „Verbindung wegen eines unbekannten Fehlers getrennt“ - Symptome: Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ich / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Nach dem Senden des Grundes zuerst nur die Senderichtung schließen (shutdown), empfangene Daten bis zum Schließen der Gegenseite vollständig lesen und erst dann schließen, SO_LINGER mit 0 s vermeiden. - Im Graphen: Vereinzelte Spitzen ohne Muster (Per RST beendete Verbindungen) - Wo nachsehen: Zuwachs von TcpExtTCPAbortOnData (per RST geschlossen, obwohl noch Daten zu senden waren, SO_LINGER 0 s) und TcpExtTCPAbortOnClose (mit ungelesenen Daten geschlossen) in nstat -az prüfen, im Moment der Trennung im Paketmitschnitt auf dem Server prüfen, ob ein RST hinausgeht und kein FIN - Spricht dafür: Zum Zeitpunkt der Meldungen „Verbindung wegen eines unbekannten Fehlers getrennt“ sendet der Server RST, und AbortOnData oder AbortOnClose steigen - Spricht dagegen: Server beendet die Verbindung normal per FIN, Grund wird trotzdem nicht angezeigt: Verbindungsabbau im Client - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [closesocket function (winsock.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-closesocket) · Microsoft · Ist SO_LINGER aktiv und die Zeit auf 0 gesetzt, wird die Verbindung hart abgebrochen und sofort zurückgesetzt, nicht gesendete Daten gehen verloren - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Wird mit noch ungelesenen empfangenen Daten geschlossen, sendet TCP ein RST, um den Datenverlust anzuzeigen - [Graceful Shutdown, Linger Options, and Socket Closure](https://learn.microsoft.com/en-us/windows/win32/winsock/graceful-shutdown-linger-options-and-socket-closure-2) · Microsoft · Reihenfolge: mit shutdown zuerst nur die Senderichtung schließen, nach der Abschlussmeldung der Gegenseite den Socket schließen - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPAbortOnData: per RST geschlossen, obwohl noch Daten zu senden waren (etwa durch SO_LINGER 0 s), TcpExtTCPAbortOnClose: mit ungelesenen Daten geschlossen und RST gesendet #### sk-blocking-io · Blockierende I/O-Architektur · Blocking I/O model Kann ein Thread nichts anderes tun, während er auf einen Socket wartet, wird mit steigender Spielerzahl alles langsamer. - Warum → Folge → Auf dem Bildschirm: Für jede Verbindung wird auf Lesen und Schreiben gewartet → Verzögerung einer Verbindung greift auf andere Verbindungen desselben Threads über → Je mehr Spieler gleichzeitig online sind, desto stärker Zeitlupe und Input-Lag für alle - Symptome: Zeitlupe, Input-Lag / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang, Abendliche Stoßzeit - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Auf asynchrone I/O mit epoll, IOCP oder io_uring umstellen. - Im Graphen: Steigt mit Spielerzahl und Last (Antwortzeit, Thread-Zahl) - Wo nachsehen: Mit pidstat -w -t die Zahl der Spielserver-Threads und die freiwilligen Kontextwechsel pro Thread prüfen (cswch/s: wie oft ein Thread anhält, um auf eine Ressource zu warten) und mit der Antwortzeit bei steigender Spielerzahl vergleichen - Spricht dafür: Mit steigender Spielerzahl wächst die Antwortzeit steil, die meisten der mit den Verbindungen vermehrten Threads haben nur viele freiwillige Wechsel und nutzen kaum CPU (warten auf Sockets) - Spricht dagegen: Threads nutzen ohne Wartezeiten ständig CPU: Rechenlast („Überschrittenes Tick-Budget“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [epoll(7) — Linux manual page](https://man7.org/linux/man-pages/man7/epoll.7.html) · Linux man-pages · I/O-Ereignisbenachrichtigung, die so skaliert, dass viele fd auf einmal überwacht werden können - [I/O Completion Ports](https://learn.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports) · Microsoft · Windows-Verfahren, das viele asynchrone I/O-Vorgänge mit einem vorab erzeugten Thread-Pool abwickelt - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · cswch/s bei -w: freiwillige Kontextwechsel, bei denen ein Thread beim Warten auf Ressourcen selbst anhält, -t: pro Thread #### sk-reuseport · Schieflast bei der SO_REUSEPORT-Verteilung · SO_REUSEPORT imbalance, stuck worker Teilen sich mehrere Prozesse denselben Port, legt der Kernel für jede Verbindung per Adress-Hash fest, welcher Prozess zuständig ist, und ändert das danach nicht mehr. Steht dieser Prozess still, warten nur die ihm zugeordneten Spieler. - Warum → Folge → Auf dem Bildschirm: Gateway oder Login-Server startet mit SO_REUSEPORT mehrere Prozesse → Steht ein Prozess durch GC oder Überlast still, wandern die ihm zugeordneten neuen Verbindungen und UDP-Pakete trotzdem nicht zu anderen Prozessen → Nur einige Spieler: kein Login oder Freeze. Bei Neustarts mit geänderter Prozesszahl brechen einige UDP-Sessions ab - Symptome: Kein Login / Endlos-Laden, Freeze, Verbindungsabbruch / Faktoren: Stillstand, Paketverlust - Wer: Nur ich, Ganzer Server / Wann: Direkt nach Login oder Wartung, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Empfangs-Threads dürfen niemals blockieren, Verfahren zur Übergabe von Sessions bei Neustarts implementieren. - Aufgaben Infrastrukturteam: Verbindungswarteschlange pro Prozess überwachen (Recv-Q in ss), bei Deployments mit geänderter Prozesszahl das Verfahren zur Session-Übergabe einhalten. - Im Graphen: Nur einzelne Ausreißer (Verbindungswarteschlange pro Listen-Socket (Recv-Q)) - Wo nachsehen: Mit ss -ltnp für jeden Listen-Socket desselben Ports Recv-Q (Verbindungen, die auf accept warten) und den zuständigen Prozess prüfen, Durchsatz der Prozesse vergleichen - Spricht dafür: Von mehreren Sockets desselben Ports staut sich nur bei einem dauerhaft die Recv-Q, und dieser Prozess steht still oder hat einen Durchsatz nahe 0 - Spricht dagegen: Recv-Q staut sich bei allen Sockets gleichmäßig: Gesamtüberlast („Überlauf der Verbindungswarteschlange (Backlog)“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Mit SO_REUSEPORT binden mehrere Sockets an dieselbe Adresse und teilen sich TCP-Verbindungen und UDP-Pakete - [net/core/sock_reuseport.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/sock_reuseport.c?h=v6.12) · Linux kernel · Ohne BPF-Programm wird der zuständige Socket gewählt, indem der Paket-Hash auf die Zahl der Sockets in der Gruppe aufgeteilt wird - [Why does one NGINX worker take all the load?](https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/) · Cloudflare · SO_REUSEPORT teilt die Queues per einfachem Hash auf die Worker auf, blockiert ein Worker, hängen alle Verbindungen in seiner Queue - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=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 #### sk-udp-connreset · WSAECONNRESET-Fehler bei UDP-Sockets unter Windows · WSAECONNRESET on a Windows UDP socket Sendet ein Windows-Server UDP an einen Client, der schon weg ist, kommt eine ICMP-Meldung „Port nicht erreichbar“ zurück. Durch diese Meldung endet der nächste Empfangsaufruf mit einem Fehler. Behandelt der Servercode diesen Fehler als Defekt des Sockets selbst, sind alle betroffen, die diesen Socket nutzen. - Warum → Folge → Auf dem Bildschirm: UDP geht weiter an die Adresse eines gerade abgemeldeten Clients, eine ICMP-Meldung „Port nicht erreichbar“ kommt zurück → Windows beendet den nächsten Empfangsaufruf mit dem Fehler WSAECONNRESET (10054), der Servercode stoppt den Empfang oder schließt den Socket → Alle, die diesen Socket nutzen, auf einmal: Freeze oder Verbindungsabbruch - Symptome: Verbindungsabbruch, Freeze / Faktoren: Paketverlust, Stillstand - Wer: Ganzer Server / Wann: Gelegentlich, zufällig, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: SIO_UDP_CONNRESET per WSAIoctl abschalten, damit diese Meldung nicht ankommt, bei Empfangsfehlern nur loggen und weiter empfangen. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungen, Log der Empfangsfehler) - Wo nachsehen: Im Spielserver-Log nach UDP-Empfangsfehlercodes (WSAECONNRESET, 10054) und nach Einträgen suchen, dass die Empfangsschleife stoppte oder der Socket geschlossen wurde, per Paketmitschnitt auf dem Server prüfen, ob kurz davor ICMP Port Unreachable eintraf - Spricht dafür: Kurz vor den gleichzeitigen Verbindungsabbrüchen ist ein WSAECONNRESET-Empfangsfehler protokolliert, und davor kam ICMP Port Unreachable von der Adresse eines gerade abgemeldeten Clients - Spricht dagegen: Linux-Server oder SIO_UDP_CONNRESET im Code abgeschaltet: trifft nicht zu - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Winsock IOCTLs](https://learn.microsoft.com/en-us/windows/win32/winsock/winsock-ioctls) · Microsoft · SIO_UDP_CONNRESET schaltet für UDP die Meldung „Port nicht erreichbar“ (PORT_UNREACHABLE) ein und aus - [recvfrom function (winsock.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recvfrom) · Microsoft · WSAECONNRESET an einem UDP-Socket bedeutet, dass ein früherer Sendevorgang ICMP Port Unreachable erhalten hat - [Windows Sockets Error Codes](https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2) · Microsoft · Fehlernummer von WSAECONNRESET: 10054 ### L9 Spielprozess auf dem Server (18 Ursachen) #### sp-tick-overrun · Überschrittenes Tick-Budget · Tick overrun Passt die Arbeit eines Ticks nicht mehr ins Budget, dehnt sich das Tick-Intervall des Servers. Das ganze Gebiet läuft dann langsamer oder ruckelt. - Warum → Folge → Auf dem Bildschirm: Arbeit für einen Tick (z. B. 50 ms) übersteigt das Budget → Spielzustand, der 20-mal pro Sekunde berechnet werden soll, wird nur 8-mal berechnet → Ganzes Gebiet in Zeitlupe (je nach Serverdesign Ruckeln), Skills reagieren verzögert - Symptome: Zeitlupe, Input-Lag, Ruckeln / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei großem Andrang, Abendliche Stoßzeit - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Teure Berechnungen reduzieren, den Tick auf mehrere Threads verteilen, Spieler verteilen (Kanäle), Tick-Verarbeitungszeit als Metrik erfassen. - Aufgaben Infrastrukturteam: Tick-Zeit und CPU-Auslastung pro Kern in Monitoring und Alarmierung aufnehmen, CPUs und Instanzen mit hoher Single-Core-Leistung (Takt) prüfen. - Größenordnungen: Bei einem Server mit 20 Ticks pro Sekunde beträgt das Budget 50 ms, bei 30 Ticks 33 ms, bei 60 Ticks 16,7 ms. Für plötzlichen Andrang ist es sicherer, im Normalbetrieb nur etwa die Hälfte des Budgets zu nutzen und den Rest als Reserve zu lassen. - Im Graphen: Steigt mit Spielerzahl und Last (Server-Tick-Zeit, Spieler pro Zone und Kanal, CPU des Game-Threads) - Wo nachsehen: Vom Server erfasste Tick-Verarbeitungszeit (p99) und Zahl der Tick-Überschreitungen im selben Graphen wie die Spielerzahl pro Zone und Kanal darstellen. Ohne Tick-Metriken mit pidstat -t 1 die CPU-Auslastung des einzelnen Game-Threads prüfen - Spricht dafür: Zum Zeitpunkt des Andrangs überschreitet die Tick-Zeit das Budget (50 ms bei 20 Ticks), und die CPU-Auslastung des Game-Threads klebt währenddessen nahe 100 % - Spricht dagegen: Tick überschreitet das Budget, CPU des Game-Threads aber niedrig: Ursache liegt im Warten (GC-Pause, Locks, synchrone Aufrufe). Lange Run-Queue-Latenz in bcc runqlat: Threads bekommen keine CPU-Zeit, also eher CPU-Mangel oder zu viele Threads - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Wie sich ein verspäteter Tick zeigt, hängt vom Serverdesign ab. Rückt der Server den Spielzustand pro Tick um eine feste Zeitspanne vor (z. B. 50 ms), verlangsamt sich die Spielzeit selbst, und alles läuft in Zeitlupe. Rückt der Server um die tatsächlich vergangene Zeit auf einmal vor, bleibt die Spielgeschwindigkeit erhalten. Dafür kommen Pakete seltener, und Objekte springen jeweils weit, was als Ruckeln oder Teleportieren erscheint. In beiden Fällen reagieren Eingaben verzögert. Bedient ein einzelner Game-Thread den ganzen Server, wird der ganze Server langsamer. Hat jedes Gebiet einen eigenen Thread, trifft es nur dieses Gebiet. Manche Spiele wie EVE Online verlangsamen in großen Schlachten die Spielzeit absichtlich um bis zu den Faktor 10 (Time Dilation), damit die Berechnung hinterherkommt. - Reale Fälle: eve-hedgp-2014 - Quellen: - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Ein Server mit 128 Ticks muss einen Frame in 7,8125 ms abschließen, die Server-Frame-Zeit wird pro Subsystem gemessen und das Budget aufgeteilt - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · EVE Online verlangsamt bei Überlast die Spielzeit per Time Dilation, Untergrenze 10 % (10-mal langsamer), Node-CPU im Normalbetrieb unter 80 % - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Gerät eine Simulation mit festem Zeitschritt in Rückstand, werden Aufholschritte gebündelt ausgeführt, Zeit über dem Limit wird verworfen, dadurch läuft die Spielzeit langsamer als die reale Zeit - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.) - [Demonstrations of runqlat, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/runqlat_example.txt) · IO Visor · Zeigt die Run-Queue-Latenz des Schedulers (Wartezeit, bis eine Aufgabe CPU-Zeit bekommt) als Histogramm #### sp-aoi · Explodierende Sichtbereichsberechnung (AOI, N²) · Area-of-interest explosion Wird für alle Spieler paarweise geprüft, wer wen sehen kann, wächst der Rechenaufwand bei 10-mal so vielen Spielern auf das 100-Fache. - Warum → Folge → Auf dem Bildschirm: Abstände werden zwischen allen Charakteren verglichen, oder trotz Aufteilung in ein Raster (Grid) drängen sich Hunderte um eine Zelle → Bei 100 Spielern etwa 10.000 Vergleiche, bei 1.000 Spielern etwa 1 Million → An vollen Orten wie beim Weltboss oder bei Belagerungen schießt die Tick-Zeit hoch: Zeitlupe und Ruckeln - Symptome: Zeitlupe, Ruckeln / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: In Raster oder Bereiche aufteilen und nur die Umgebung vergleichen, weit entfernte Objekte seltener aktualisieren, Zahl der Spieler begrenzen, die eine Person sieht. - Größenordnungen: Setzt man für Abstandsvergleich und Aktualisierung der Sichtbarkeitslisten zusammen 0,1 µs (eine Zehnmillionstelsekunde) pro Spielerpaar an, ergibt das bei 1.000 Spielern (etwa 1 Million Paare) 100 ms pro Tick. Das ist doppelt so viel wie das Budget bei 20 Ticks pro Sekunde (50 ms). - Im Graphen: Steigt mit Spielerzahl und Last (Server-Tick-Zeit, Spieler an einem Ort) - Wo nachsehen: Spielerzahl pro Zone und Kanal und Tick-Zeit im selben Graphen darstellen, dazu die separat gemessene Zeit der Sichtbereichsberechnung innerhalb des Ticks. Ohne separate Messung mit perf top -p den CPU-Anteil pro Funktion im Spielprozess prüfen - Spricht dafür: Verdoppelt sich die Spielerzahl an einem Ort, steigt die Tick-Zeit fast auf das 4-Fache, und Funktionen für Sichtbereich und Abstand belegen den Großteil der CPU-Zeit - Spricht dagegen: Tick-Zeit wächst proportional zur Spielerzahl, oder Sende- und Serialisierungsfunktionen haben einen großen Anteil: eher explodierende Broadcast-Last oder Kosten für Serialisierung und Kompression - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Comparing Interest Management Algorithms for Massively Multiplayer Games](https://www.sable.mcgill.ca/~clump/papers/boulanger-06-comparing.pdf) · ACM · Paper von NetGames 2006 (Autorenfassung). Abstandsmessung zwischen allen Paaren skaliert nicht mit wachsender Spielerzahl, bei Aufteilung in ein quadratisches Raster werden nur die 9 Zellen der Umgebung geprüft - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · Das Standardverfahren, das für jeden Actor alle Verbindungen prüft, wird bei vielen Spielern und Actors zum CPU-Engpass des Servers, MMORPGs u. a. teilen die Welt in ein Raster und verwenden Listen pro Zelle wieder - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Zeigt den CPU-Anteil eines laufenden Prozesses (-p) oder Threads (-t) pro Funktion (Symbol) in Echtzeit #### sp-broadcast · Explodierende Broadcast-Last · Broadcast fan-out (N×N) Wird jede Bewegung eines Spielers an alle geschickt, die ihn sehen, wächst die Zahl der zu sendenden Updates mit dem Quadrat der versammelten Spieler. - Warum → Folge → Auf dem Bildschirm: Jede Änderung eines Spielers geht an alle, die ihn sehen können → Sehen sich 1.000 Spieler gegenseitig, sind es 1 Million Updates pro Tick → Sende-Warteschlange und Bandbreite laufen voll: Latenz und Paketverlust (Input-Lag, Zeitraffer, Teleportieren) - Symptome: Input-Lag, Teleportieren, Zeitraffer / Faktoren: Latenz, Paketverlust - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Update-Frequenz nach Entfernung und Wichtigkeit senken (nahe Gegner jeden Tick, entfernte Spieler einige Male pro Sekunde), Datenmenge pro Empfänger begrenzen und mit dem Wichtigsten zuerst füllen, mehrere Updates in ein Paket bündeln, Zahl der angezeigten Spieler begrenzen. - Aufgaben Infrastrukturteam: Sendebandbreite und Pakete pro Sekunde je Server mit den Netzwerklimits von NIC und Instanz vergleichen und alarmieren, vor großen Events die Reserven prüfen. - Größenordnungen: 1.000 Spieler × 1.000 Spieler × 20 Ticks = 20 Millionen Updates pro Sekunde. Bei 40 Byte pro Update sind das für den ganzen Server etwa 6,4 Gbps, pro Empfänger etwa 6,4 Mbps. Begrenzt man die sichtbaren Spieler auf 150, sind es insgesamt etwa 1 Gbps und pro Spieler etwa 1 Mbps. - Im Graphen: Steigt mit Spielerzahl und Last (Gesendete Pakete und Bytes des Servers, Spieler an einem Ort) - Wo nachsehen: txpck/s und txkB/s aus sar -n DEV 1 (von der Server-NIC pro Sekunde gesendete Pakete und KB) zusammen mit dem Graphen der Spielerzahl betrachten. Bei Cloud-Instanzen die Zähler für Limitüberschreitungen in ethtool -S prüfen (bei AWS ENA bw_out_allowance_exceeded und pps_allowance_exceeded) - Spricht dafür: Mit wachsender Spielerzahl steigen gesendete Pakete und Bytes steiler als die Spielerzahl (annähernd quadratisch), ab Erreichen des Limits steigen die Zähler für Limitüberschreitungen oder die beim Senden verworfenen Pakete - Spricht dagegen: Sendevolumen unverändert, nur die Tick-Zeit steigt: eher Sichtbereichsberechnung oder Spiellogik - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: eve-hedgp-2014 - Quellen: - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Die O(n²)-Übertragung, bei der n Spieler die Aktionen von n Spielern sehen müssen, ist der unvermeidliche limitierende Faktor großer Flottenschlachten - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Ist die Bandbreite einer Verbindung ausgeschöpft, erhält jeder Actor eine Priorität (Entfernung, Blickrichtung, Zeit seit der letzten Übertragung), und die Bandbreite wird nach Wichtigkeit verteilt - [Detailed Actor Replication Flow in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/detailed-actor-replication-flow-in-unreal-engine) · Epic Games · NetUpdateFrequency legt die Update-Frequenz pro Actor fest, gesendet wird nach Priorität, und ist die Verbindung ausgeschöpft, wird der Rest auf den nächsten Tick verschoben - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · rxpck/s und txpck/s in sar -n DEV (empfangene und gesendete Pakete pro Sekunde), rxkB/s und txkB/s (empfangene und gesendete KB pro Sekunde) - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · bw_out_allowance_exceeded (Sendebandbreiten-Limit überschritten) und pps_allowance_exceeded (PPS-Limit überschritten) zählen Pakete, die deshalb in die Queue gestellt oder verworfen wurden #### sp-hotzone · Überlastetes Gebiet auf einem einzelnen Thread (Hotspot) · Single-threaded hot zone Ist jedes Gebiet einem einzelnen Thread zugeordnet und drängen sich viele Spieler an einem Ort, läuft nur dieser eine Kern auf 100 %. - Warum → Folge → Auf dem Bildschirm: Ein Thread ist für ein Gebiet (Kanal) zuständig → Drängen sich Spieler an einem Ort, ist nur dieser Kern ausgelastet, die übrigen Kerne haben Luft → Nur dieses Gebiet laggt, andere Gebiete laufen normal - Symptome: Zeitlupe, Input-Lag / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Auf Kanäle verteilen, innerhalb des Gebiets parallelisieren, Spielerzahl begrenzen. - Aufgaben Infrastrukturteam: CPU-Auslastung pro Kern in Monitoring und Alarmierung aufnehmen (im Durchschnitt über den ganzen Server geht die Auslastung eines einzelnen Kerns unter). - Größenordnungen: Auf einem Server mit 16 Kernen erscheint die Gesamt-CPU-Auslastung bei einem Kern auf 100 % nur als etwa 6 %. Finden lässt sich das nur über die Auslastung pro Kern. - Im Graphen: Steigt mit Spielerzahl und Last (CPU-Auslastung pro Kern, CPU pro Thread) - Wo nachsehen: Mit mpstat -P ALL 1 die Auslastung pro Kern und mit pidstat -t 1 die CPU pro Thread des Spielprozesses prüfen, mit der Spielerzahl der Zone vergleichen, für die der am stärksten belastete Thread zuständig ist - Spricht dafür: Gesamt-CPU des Servers niedrig, nur ein Thread (ein Kern) klebt nahe 100 %, und zur selben Zeit drängen sich Spieler in der Zone dieses Threads - Spricht dagegen: Mehrere Kerne gleichmäßig hoch: Überlast des ganzen Servers. Nur %soft (Empfangsverarbeitung) eines Kerns hoch: eher NIC-Interrupts auf nur einem Kern - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Dass andere Gebiete normal laufen, gilt nur, wenn jedes Gebiet seinen Tick unabhängig ausführt. Warten die Threads mehrerer Gebiete in jedem Tick aufeinander und gehen gemeinsam zum nächsten Tick über, bremst das am stärksten belastete Gebiet den Tick des ganzen Servers. - Reale Fälle: eve-hedgp-2014 - Quellen: - [Time Dilation – How’s That Going?](https://www.eveonline.com/news/view/time-dilation-hows-that-going) · CCP Games · Time Dilation in EVE Online wirkt pro Node, daher werden auch entfernte Sonnensysteme auf demselben Node langsamer, große Schlachten laufen auf verstärkten Nodes mit nur 4 Sonnensystemen - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · Zeigt Auslastung pro Prozessor und Gesamtdurchschnitt getrennt an (-P ALL), %soft ist der Zeitanteil für die Verarbeitung von Software-Interrupts - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.) #### sp-lock · Lock-Contention · Lock contention Warten mehrere Threads auf denselben Lock, um auf dieselben Daten zuzugreifen, läuft trotz zusätzlicher Threads immer nur einer zur Zeit. - Warum → Folge → Auf dem Bildschirm: Mehrere Threads greifen gleichzeitig auf gemeinsame Daten zu, etwa Auktionshaus oder Gildenbank → Bis der Thread mit dem Lock fertig ist, warten alle anderen → Nur bestimmte Funktionen langsam, im schlimmsten Fall verzögert sich der gesamte Tick - Symptome: Input-Lag, Freeze / Faktoren: Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Locks feingranularer aufteilen, Arbeit innerhalb von Locks reduzieren, nachrichtenbasierte Architektur (für alle Daten einen zuständigen Thread festlegen, andere Threads schicken nur Anfragen per Nachricht). - Größenordnungen: Macht die Arbeit innerhalb des Locks 20 % der Gesamtarbeit aus, erreicht der Durchsatz egal mit wie vielen Threads höchstens das 5-Fache eines einzelnen Threads. Bei 40 % ist beim 2,5-Fachen Schluss. - Im Graphen: Steigt mit Spielerzahl und Last (Verarbeitungszeit der Anfragen, CPU und Kontextwechsel pro Thread) - Wo nachsehen: Mit pidstat -w -t 1 die freiwilligen Kontextwechsel pro Thread prüfen (cswch/s: wie oft ein Thread anhält, um auf eine Ressource zu warten), mit bcc offcputime -p ermitteln, wo Threads außerhalb der CPU warten (Wartezeit pro Call-Stack). Bei .NET die Zahl der Lock-Contentions in dotnet-counters (ab .NET 9 dotnet.monitor.lock_contentions, bis 8 Monitor Lock Contention Count) - Spricht dafür: Mit steigender Last bleibt die CPU-Auslastung niedrig, die Verarbeitungszeit wächst aber, der Großteil der Wartezeit entfällt auf Call-Stacks, die einen Lock anfordern, und die Zahl der Lock-Contentions steigt mit - Spricht dagegen: CPU voll ausgelastet: Problem der Rechenlast (überschrittenes Tick-Budget, überlastetes Gebiet auf einem einzelnen Thread). Gewartet wird auf DB- oder Dateiaufrufe: eher synchrone Aufrufe im Game-Thread - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Das tritt in Architekturen auf, in denen mehrere Threads gemeinsam Spieldaten ändern. Ist für jedes Gebiet und jede Funktion ein einzelner Thread zuständig und läuft der Austausch nur über Nachrichten, gibt es kaum Locks. Dafür muss man darauf achten, dass sich die Arbeit nicht auf einem Thread ballt (überlastetes Gebiet auf einem einzelnen Thread). Wartet der Game-Thread auf einen Lock, den ein langsamer Speichervorgang hält, steht der ganze Tick still. - Reale Fälle: roblox-2021 - Quellen: - [Amdahl's Law in the Multicore Era](https://research.cs.wisc.edu/multifacet/papers/ieeecomputer08_amdahl_multicore.pdf) · IEEE · Artikel in IEEE Computer 2008 (Autorenfassung). Ist der nicht parallelisierbare Anteil 1−f, kann der Speedup egal mit wie vielen Kernen 1/(1−f) nicht überschreiten (Amdahlsches Gesetz) - [Request scheduling](https://learn.microsoft.com/en-us/dotnet/orleans/grains/request-scheduling) · Microsoft · Grains (Actors) in Orleans arbeiten Anfragen nach einem Single-Thread-Ausführungsmodell einzeln bis zum Ende ab und ändern ihren Zustand daher nie gleichzeitig, warten Grains gegenseitig auf ihre Antworten, ist ein Deadlock möglich - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · cswch/s bei -w ist die Zahl freiwilliger Kontextwechsel, bei denen ein Thread anhält, um auf eine Ressource zu warten, -t zeigt die Werte pro Thread - [Demonstrations of offcputime, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/offcputime_example.txt) · IO Visor · Summiert die Zeit, in der Threads angehalten waren und die CPU verlassen hatten (off-CPU), pro Call-Stack, -p wählt den Prozess - [Well-known EventCounters in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/available-counters) · Microsoft · Monitor Lock Contention Count (monitor-lock-contention-count): Zahl der Konflikte beim Versuch, einen Monitor-Lock zu erhalten - [.NET runtime metrics](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/built-in-metrics-runtime) · .NET · Ab .NET 9 dotnet.monitor.lock_contentions: Zahl der Konflikte beim Versuch, einen Monitor-Lock zu erhalten, seit Prozessstart #### sp-deadlock · Deadlock · Deadlock Wartet jeder von zwei Threads auf den Lock, den der andere hält, stehen beide für immer still. - Warum → Folge → Auf dem Bildschirm: Thread A hält Lock 1 und wartet auf Lock 2, B hält Lock 2 und wartet auf Lock 1 → Beide stehen für immer still, abhängige Threads bleiben nacheinander ebenfalls hängen → Ganzer Server steht still, Watchdog startet neu, Verbindungsabbruch für alle - Symptome: Freeze, Verbindungsabbruch / Faktoren: Stillstand - Wer: Ganzer Server, Nur eine bestimmte Funktion / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Regeln für die Lock-Reihenfolge, Locks mit Timeout, Watchdog einsetzen und im Moment des Stillstands einen Thread-Dump schreiben. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungen, Sendevolumen des Servers) - Wo nachsehen: Während des Stillstands die Call-Stacks aller Threads sichern. JVM: jstack (findet und markiert Deadlocks automatisch), .NET: dotnet-stack, native Server: thread apply all bt in gdb oder mit gcore eine Core-Datei schreiben und nach dem Neustart analysieren - Spricht dafür: Zwei oder mehr Threads hängen mit Stacks, in denen jeder auf den Lock des anderen wartet, und die CPU-Auslastung des Prozesses liegt währenddessen nahe 0 - Spricht dagegen: Ein Thread läuft während des Stillstands mit 100 % CPU: Endlosschleife. Threads warten auf DB oder externe Antworten: eher synchrone Aufrufe oder ein erschöpfter Thread-Pool - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Runtime locking correctness validator](https://docs.kernel.org/locking/lockdep-design.html) · Linux kernel · Werden zwei Locks in entgegengesetzter Reihenfolge genommen, entsteht durch zirkuläres Warten ein Deadlock (lock inversion deadlock), der Linux-Kernel prüft die Lock-Reihenfolge und warnt vorab - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Ein Deadlock, bei dem die Anwendung läuft, aber nicht vorankommt, wird per Liveness-Probe erkannt und der Container neu gestartet - [Diagnostic Tools (Java SE 21 Troubleshooting Guide)](https://docs.oracle.com/en/java/javase/21/troubleshoot/diagnostic-tools.html) · Oracle · jstack gibt die Stacks aller Threads einer laufenden JVM aus und findet und meldet auch Deadlocks (Found one Java-level deadlock) - [dotnet-stack diagnostic tool - .NET CLI](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-stack) · Microsoft · Erfasst die verwalteten Stacks aller Threads eines .NET-Prozesses und gibt sie aus - [Threads (Debugging with GDB)](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads.html) · GNU Project · thread apply all führt denselben Befehl für alle Threads aus (bt: Call-Stack ausgeben) - [gcore(1) — Linux manual page](https://man7.org/linux/man-pages/man1/gcore.1.html) · gdb · Erstellt eine Core-Datei eines laufenden Programms, das Programm läuft danach unverändert weiter #### sp-sync-call · Synchrone Aufrufe im Game-Thread · Synchronous DB / file I/O on the game loop Wartet der Server mitten im Tick auf eine DB-Antwort oder einen Schreibvorgang, steht das gesamte Spielgeschehen für genau diese Zeit still. - Warum → Folge → Auf dem Bildschirm: Innerhalb des Ticks wird auf DB-Abfragen und -Speichervorgänge, Log-Schreibvorgänge und externe API-Aufrufe gewartet → Braucht die DB 100 ms, steht auch der Tick 100 ms still → Bei jeder Verlangsamung von DB oder Datenträger stockt das ganze Gebiet kurz - Symptome: Freeze, Ruckeln / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei bestimmten Aktionen, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Langsame Vorgänge (DB-Abfragen und -Speichervorgänge, Log-Schreibvorgänge, externe API-Aufrufe) vollständig asynchron auslagern und das Ergebnis im nächsten Tick übernehmen (mit nur einem Timeout steht der Tick während der Wartezeit weiterhin still). - Größenordnungen: Selbst ein DB-Round-Trip von 0,5 ms im selben Rechenzentrum summiert sich bei 100 Aufrufen pro Tick auf 50 ms. Das verbraucht allein das komplette Budget eines Servers mit 20 Ticks pro Sekunde. - Im Graphen: Vereinzelte Spitzen ohne Muster (Server-Tick-Zeit, DB-Query-Latenz) - Wo nachsehen: Graph der Tick-Zeit, DB-Query-Latenz (slow query log u. a.) und Disk-Latenz auf derselben Zeitachse darstellen. Ohne Tick-Metriken mit bcc offcputime -p ermitteln, wo der Game-Thread wartet - Spricht dafür: Tick-Spitzen fallen zeitlich mit Spitzen der DB- oder Dateilatenz zusammen, und die Wartezeit des Game-Threads entfällt auf Call-Stacks für den Empfang von DB-Antworten oder das Schreiben von Dateien - Spricht dagegen: DB- und Disk-Latenz unauffällig, Tick schlägt trotzdem aus: eher GC-Pause oder Lock-Contention - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Designs, Lessons and Advice from Building Large Distributed Systems](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Keynote auf der LADIS 2009 (Jeff Dean). Round Trip innerhalb desselben Rechenzentrums etwa 0,5 ms (500.000 ns) - [ASP.NET Core Best Practices](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices) · Microsoft · Datenzugriffe, I/O und langlaufende Operationen asynchron aufrufen, synchron blockierende Aufrufe führen zur Erschöpfung des Thread-Pools und zu verzögerten Antworten - [Demonstrations of offcputime, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/offcputime_example.txt) · IO Visor · Summiert die Zeit, in der Threads angehalten waren und die CPU verlassen hatten (off-CPU), pro Call-Stack, -p wählt den Prozess #### sp-queue · Rückstau in der Message-Queue · Mailbox / job queue backlog Kommen Anfragen schneller herein, als sie verarbeitet werden, stauen sie sich in der Warteschlange. Spätere Anfragen werden dann erst nach einigen Sekunden verarbeitet oder verworfen. - Warum → Folge → Auf dem Bildschirm: Anfragen treffen schneller ein, als sie verarbeitet werden → Warteschlange wird länger, über dem Limit wird verworfen → Skills und Handel reagieren verzögert oder werden verschluckt - Symptome: Input-Lag, Verschluckte Aktion / Rollback / Faktoren: Latenz, Paketverlust - Wer: Bestimmter Ort oder Kanal, Nur eine bestimmte Funktion / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Länge der Warteschlange überwachen, Richtlinie zum bevorzugten Verwerfen alter Anfragen, Verarbeitung parallelisieren. - Im Graphen: Plateau am Limit (Queue-Länge und Alter der ältesten Nachricht, Verarbeitungen pro Sekunde) - Wo nachsehen: Vom Server erfasste Länge pro Queue, Alter der ältesten Nachricht sowie eingegangene, verarbeitete und verworfene Nachrichten pro Sekunde prüfen. Ohne Metriken im Code mit ss (oder netstat) Recv-Q des Spiel-Sockets prüfen (vom Kernel empfangene, vom Prozess noch nicht gelesene Datenmenge) - Spricht dafür: Solange mehr eingeht als verarbeitet wird, stagniert die Verarbeitungsrate auf einem festen Wert, während Queue-Länge, Alter und verworfene Nachrichten stetig steigen - Spricht dagegen: Queue kurz und Nachrichten jung, Reaktion trotzdem verzögert: eher Latenz der Leitung oder Verzögerung des Ticks selbst - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Reale Fälle: eve-hedgp-2014 - Quellen: - [Avoiding insurmountable queue backlogs](https://d1.awsstatic.com/builderslibrary/pdfs/avoiding-insurmountable-queue-backlogs.pdf) · AWS · Amazon Builders' Library. Rückstau über das Alter wartender Nachrichten überwachen, Echtzeitsysteme verarbeiten neue Daten zuerst (annähernd LIFO), alte Nachrichten werden teils verworfen - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Kommen Anfragen schneller, als sie verarbeitet werden, füllt sich die Queue und die Latenz steigt, LIFO oder CoDel anstelle von FIFO entfernen alte, bereits nutzlose Anfragen - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · Werkzeug für Socket-Statistiken (ähnliche Informationen wie netstat), -p zeigt den Prozess, der den Socket nutzt - [netstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/netstat.8.html) · net-tools · Recv-Q: Anzahl der Bytes auf einem verbundenen Socket, die das Anwenderprogramm noch nicht abgeholt hat #### sp-timer-burst · Gleichzeitig auslösende Timer · Synchronized timers Fallen alle Monster-Respawns, alle Buff-Abläufe und die Belohnungen zur vollen Stunde in denselben Tick, ist dieser eine Tick Dutzende Male so aufwendig wie sonst. - Warum → Folge → Auf dem Bildschirm: Timer für Respawn, Ablauf, Belohnungen und automatisches Speichern sind auf denselben Zeitpunkt gelegt → In diesem einen Tick fällt Dutzende Male so viel Arbeit an wie sonst → Zu festen Zeitpunkten jeweils ein kurzes Stocken - Symptome: Freeze, Ruckeln / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: In festen Abständen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Timer-Zeitpunkte leicht zufällig streuen, Verarbeitung auf mehrere Ticks verteilen. - Im Graphen: Spitzen in festen Abständen (Server-Tick-Zeit) - Wo nachsehen: Zeitpunkte der Tick-Spitzen sammeln und die Abstände prüfen (zur vollen Stunde, alle 5 Minuten usw.). Mit der Liste der Timer für Respawn, Buff-Ablauf, Belohnungen und automatisches Speichern abgleichen, die zur selben Zeit laufen - Spricht dafür: Tick schlägt jedes Mal zur selben Uhrzeit oder im selben Abstand aus, und zu diesem Zeitpunkt lösen Spiel-Timer gesammelt aus - Spricht dagegen: Periodisch, aber deckungsgleich mit den Pausen im GC-Log oder den Cron- und Backup-Zeiten des Servers: eher „Stop-the-World-GC-Pause auf dem Server“ oder „Zeitgesteuerte Jobs“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Allen Timern, periodischen und verzögerten Jobs Jitter hinzufügen, um Last zu verteilen, die sonst auf denselben Zeitpunkt fällt, Fallbeispiel: Anfragen vieler Server im 1-Minuten-Takt ballten sich in den ersten Sekunden jeder Minute #### sp-pathfinding · Pathfinding-Flut · Pathfinding storms Verfolgen Hunderte Monster gleichzeitig Spieler und berechnen dabei ihre Wege, kostet das viel CPU-Zeit. - Warum → Folge → Auf dem Bildschirm: Durch Zusammenziehen von Mobs oder Massen-Spawns verfolgen viele Monster gleichzeitig Spieler → Pathfinding-Berechnung für jedes Monster → Nur dieses Farmgebiet läuft in Zeitlupe - Symptome: Zeitlupe / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Pfade cachen, Zahl der Berechnungen begrenzen, auf mehrere Ticks verteilen. - Im Graphen: Steigt mit Spielerzahl und Last (Server-Tick-Zeit, Monster pro Zone) - Wo nachsehen: Zahl der Monster pro Zone, die gerade Spieler verfolgen, und Tick-Zeit prüfen. Ohne eigene Zählung mit perf top -p den CPU-Anteil pro Funktion im Spielprozess prüfen - Spricht dafür: Beim Zusammenziehen von Mobs und bei Massen-Spawns steigt die Tick-Zeit, und Pathfinding-Funktionen (Wegsuche) belegen einen großen Teil der CPU-Zeit - Spricht dagegen: Wenige Monster, viele Spieler, Tick-Zeit steigt trotzdem: eher Sichtbereichsberechnung oder Broadcast - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [AI.NavMesh.pathfindingIterationsPerFrame](https://docs.unity3d.com/ScriptReference/AI.NavMesh-pathfindingIterationsPerFrame.html) · Unity · Pathfinding verarbeitet pro Frame nur eine festgelegte Zahl von Knoten und verteilt sich so auf mehrere Frames, das Spiel bleibt auch bei langen Pfaden oder vielen gleichzeitigen Anfragen flüssig - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Zeigt den CPU-Anteil eines laufenden Prozesses (-p) pro Funktion (Symbol) in Echtzeit #### sp-serialize · Kosten für Serialisierung und Kompression · Serialization / compression cost Auch das Umwandeln der Sendedaten in Bytes und ihre Kompression kosten CPU-Zeit. Bei vielen Spielern schießen diese Kosten in die Höhe. - Warum → Folge → Auf dem Bildschirm: Für jedes Update werden Strukturen in Bytes umgewandelt und komprimiert → Kosten wachsen mit dem Quadrat der Spielerzahl → Senden verzögert sich: Input-Lag - Symptome: Input-Lag / Faktoren: Stillstand, Latenz - Wer: Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Einmal erzeugte Pakete für mehrere Empfänger wiederverwenden, schlanke Formate nutzen. - Im Graphen: Steigt mit Spielerzahl und Last (CPU-Auslastung des Servers, CPU der Threads, die Pakete erzeugen) - Wo nachsehen: Mit perf top -p den Anteil von Serialisierungs-, Kompressions- und Verschlüsselungsfunktionen (einschließlich Bibliotheksfunktionen wie zlib, LZ4, OpenSSL) an der CPU-Zeit des Spielprozesses bei wenigen und bei vielen Spielern vergleichen - Spricht dafür: Je mehr Spieler zusammenkommen, desto größer der Anteil der Serialisierungs-, Kompressions- und Verschlüsselungsfunktionen, und die CPU der paketerzeugenden Threads ist als Erstes ausgelastet - Spricht dagegen: Anteil dieser Funktionen gering: eher Sichtbereichsberechnung oder Spiellogik - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Werden Pakete verschlüsselt (TLS, DTLS u. a.), kosten auch Ver- und Entschlüsselung CPU-Zeit. Verschlüsselt wird pro Verbindung. Auch wenn ein einmal erzeugtes Paket an mehrere Empfänger geht, fallen die Verschlüsselungskosten deshalb für jeden Empfänger an. Symmetrische Verfahren wie AES-GCM sind schnell: Ein Kern schafft mehrere GB pro Sekunde, im Normalbetrieb ist ihr Anteil also gering. Die Geschwindigkeit hängt aber stark von der Größe der Einheit ab, die auf einmal verschlüsselt wird (Record). Bei vielen kleinen Paketen, wie sie in Spielen üblich sind, steigen deshalb die Kosten pro Byte. Beim Handshake, der einmal pro Verbindung stattfindet, signiert der Server mit dem Schlüssel seines Zertifikats und berechnet den Schlüsselaustausch (ECDHE). Ein Kern schafft pro Sekunde etwa 1.100 (RSA 2048) bis 18.000 (ECDSA P-256) Signaturen und etwa 9.000 Schlüsselaustausche. Bei einem Login-Ansturm wird das zur Last. - Quellen: - [Introduction to Iris in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/introduction-to-iris-in-unreal-engine) · Epic Games · Hält den zu replizierenden Zustand als eine einzige quantisierte Kopie, spart so teure Arbeit, und mehrere Verbindungen nutzen das Ergebnis gemeinsam - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Replizierte Variablen in jedem Frame pro Client zu vergleichen und geänderte Werte zu bündeln, erfordert langsame, verstreute Speicherzugriffe und kostet viel Server-CPU - [How "expensive" is crypto anyway?](https://blog.cloudflare.com/how-expensive-is-crypto-anyway/) · Cloudflare · Messung mit BoringSSL: AES-128-GCM etwa 3,7 GB pro Sekunde (stark abhängig von der Record-Größe), ein Kern schafft pro Sekunde 1.120 RSA-2048-Signaturen, 18.477 ECDSA-P-256-Signaturen und 9.394 P-256-ECDHE-Operationen, auf den Edge-Servern von Cloudflare verbrauchte die TLS-Bibliothek etwa 1,8 % der CPU - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Zeigt den CPU-Anteil eines laufenden Prozesses (-p) pro Funktion (Symbol) in Echtzeit #### sp-crash · Serverabsturz · Server process crash Stürzt der Serverprozess durch einen unbehandelten Fehler ab, bricht für alle auf diesem Server gleichzeitig die Verbindung ab. - Warum → Folge → Auf dem Bildschirm: Fatale Fehler wie Verweise auf nicht existierende Objekte (Null-Referenz), fehlerhafte Daten oder Speichermangel → Prozess des Servers (oder der Zone) wird beendet → Verbindungsabbruch für alle gleichzeitig, Fortschritt seit dem letzten Speichern wird unter Umständen zurückgesetzt (Rollback) - Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Gelegentlich, zufällig, Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Ursache anhand von Crash-Dumps finden und beheben, häufig speichern. - Aufgaben Infrastrukturteam: Prozess automatisch neu starten, Umgebung zum Sammeln und Aufbewahren von Crash-Dumps bereitstellen, bei Serverausfall sofort alarmieren. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungen, Prozessneustarts) - Wo nachsehen: Core-Dump-Einträge in coredumpctl list (Zeitpunkt, PID, Signal) und Einträge des Dienstmanagers (systemd) zu abnormalen Beendigungen und Neustarts prüfen. Bei Windows-Servern die von WER geschriebenen Dump-Dateien - Spricht dafür: Zum Zeitpunkt, an dem die Verbindungen schlagartig gegen 0 fallen, gibt es eine abnormale Beendigung des Spielserverprozesses und einen Core-Dump - Spricht dagegen: Prozess lief durchgehend weiter, Verbindungen trotzdem abgebrochen: eher Netzwerkgeräte oder Idle-Timeout. Eintrag über einen Watchdog-Neustart nach langem Stillstand: eher Endlosschleife oder Deadlock - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Collecting User-Mode Dumps](https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps) · Microsoft · Windows-Fehlerberichterstattung (WER) so konfigurieren, dass beim Absturz eines User-Mode-Programms vollständige Dumps oder Minidumps lokal gesammelt werden - [systemd.service(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.service.5.html) · systemd · Restart=on-failure startet den Dienst nach abnormaler Beendigung, Beendigung durch ein Signal (einschließlich Core-Dump) oder Watchdog-Timeout automatisch neu, empfohlen für langlaufende Dienste - [coredumpctl(1) — Linux manual page](https://man7.org/linux/man-pages/man1/coredumpctl.1.html) · systemd · list zeigt die von systemd-coredump gespeicherten Core-Dumps mit Absturzzeitpunkt, PID und auslösendem Signal #### sp-threadpool · Erschöpfter Thread-Pool · Thread pool starvation Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit. - Warum → Folge → Auf dem Bildschirm: Worker-Threads hängen fest, weil sie auf Antworten externer APIs oder der DB warten → Für neue Anfragen ist kein Thread frei → Endlos-Laden bei bestimmten Funktionen wie Login oder Shop - Symptome: Kein Login / Endlos-Laden, Input-Lag, Freeze / Faktoren: Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Bei großem Andrang, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Timeouts für langsame Aufrufe, getrennte Thread-Pools pro Funktion, auf asynchrone Verarbeitung umstellen. - Im Graphen: Plateau am Limit (Threads und Warteschlangenlänge des Thread-Pools, Verarbeitungszeit der Anfragen) - Wo nachsehen: Bei .NET Thread-Zahl und Warteschlangenlänge des Thread-Pools in dotnet-counters monitor prüfen (ab .NET 9 dotnet.thread_pool.thread.count und dotnet.thread_pool.queue.length, bis 8 ThreadPool Thread Count und ThreadPool Queue Length), mit dotnet-stack ermitteln, wo die Worker-Threads warten. Bei JVM und nativen Servern dasselbe per Thread-Dump prüfen - Spricht dafür: CPU-Auslastung deutlich unter 100 %, die Thread-Zahl steigt aber langsam und stetig oder klebt am Limit, die Warteschlange wächst, und die meisten Worker warten auf die Antwort desselben externen Aufrufs (DB, HTTP) - Spricht dagegen: Warteschlange leer, trotzdem langsam: Das aufgerufene System selbst ist langsam, also eher kaskadierender Ausfall oder Abhängigkeit von externen Diensten - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Teilen sich Paketempfang und Spiellogik denselben Worker-Thread-Pool, kommt die Paketverarbeitung des ganzen Servers zum Stillstand, sobald einige langsame Aufgaben alle Worker belegen. - Reale Fälle: riot-euw-2021 - Quellen: - [Debug ThreadPool Starvation](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-threadpool-starvation) · Microsoft · Sind keine Threads im Pool mehr frei und müssen neue Aufgaben warten, werden Antworten langsam, Ursache ist blockierender Code, der Threads belegt. Liegt die CPU in dotnet-counters deutlich unter 100 % und steigt dotnet.thread_pool.thread.count langsam und stetig, ist das ein Zeichen für einen erschöpften Pool (oft ist auch dotnet.thread_pool.queue.length hoch), mit dotnet-stack ermitteln, wo die Threads warten - [Avoiding insurmountable queue backlogs](https://d1.awsstatic.com/builderslibrary/pdfs/avoiding-insurmountable-queue-backlogs.pdf) · AWS · Gleichzeitig bearbeitete Anfragen = Ankunftsrate × Latenz (Littles Gesetz). Steigt bei 100 Anfragen pro Sekunde die Latenz von 100 ms auf 10 s, wachsen 10 Threads auf 1.000, und der Pool ist erschöpft - [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead) · Microsoft Azure · Mit eigenen Connection- und Thread-Pools pro aufgerufenem Dienst blockiert die Störung eines Dienstes nur dessen Pool - [.NET runtime metrics](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/built-in-metrics-runtime) · .NET · dotnet.thread_pool.thread.count (Threads im Thread-Pool) und dotnet.thread_pool.queue.length (wartende Aufgaben) gibt es ab .NET 9 - [Well-known EventCounters in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/available-counters) · Microsoft · ThreadPool Thread Count (threadpool-thread-count) und ThreadPool Queue Length (threadpool-queue-length) bis .NET 8 #### sp-infinite-loop · Endlosschleife und außer Kontrolle geratene Logik · Infinite loop / runaway logic Endet ein Tick wegen eines Bugs nicht, bleibt der Server stehen, und der Watchdog startet ihn zwangsweise neu. - Warum → Folge → Auf dem Bildschirm: Schleife endet wegen einer falschen Bedingung nicht, oder eine Rekursion gerät außer Kontrolle → Tick endet nicht, Server steht still → Freeze, danach Verbindungsabbruch für alle - Symptome: Freeze, Verbindungsabbruch / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei bestimmten Aktionen, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Obergrenzen für Schleifendurchläufe, Watchdog, Tests, die die problematische Eingabe nachstellen. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungen, CPU pro Thread) - Wo nachsehen: Während des Stillstands mit pidstat -t 1 die CPU pro Thread prüfen und mit perf top -t (Thread-ID) oder gdb feststellen, in welcher Funktion der Thread mit 100 % kreist. Nach einem bereits erfolgten Neustart die Einträge zu Watchdog-Timeouts prüfen (WatchdogSec in systemd, fehlgeschlagene Liveness-Probes in Kubernetes) - Spricht dafür: Während der Server still steht, klebt ein Game-Thread bei 100 % CPU, und der Stack kreist immer in derselben Funktion oder Schleife - Spricht dagegen: CPU während des Stillstands nahe 0: eher Deadlock oder Warten auf externe Antworten - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [systemd.service(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.service.5.html) · systemd · WatchdogSec=: Sendet der Dienst nicht innerhalb der festgelegten Zeit ein Lebenszeichen (WATCHDOG=1), gilt er als fehlgeschlagen und wird beendet, je nach Einstellung von Restart= automatisch neu gestartet - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Ein Zustand, in dem die Anwendung läuft, aber nicht vorankommt, wird per Liveness-Probe erkannt und neu gestartet, standardmäßig wird alle 10 s geprüft und nach 3 aufeinanderfolgenden Fehlschlägen neu gestartet - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.) - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Zeigt den CPU-Anteil eines laufenden Threads (-t) oder Prozesses (-p) pro Funktion (Symbol) in Echtzeit #### sp-hot-entity · Auf ein Ziel konzentrierter Kampf (Weltboss) · Hot entity / combat event fan-out Greifen Hunderte Spieler gleichzeitig einen einzigen Boss an, ballt sich die Berechnung auf diesen einen Boss, und jeder Treffer wird an alle gesendet, die ihn sehen. - Warum → Folge → Auf dem Bildschirm: Hunderte Spieler setzen pausenlos Skills, Buffs und Debuffs auf einen Boss ein → Berechnung von Lebenspunkten, Aggro-Liste und Debuffs des Bosses ballt sich an einer Stelle, für jeden Treffer gehen Pakete mit Schadenszahlen und Effekten an alle, die zusehen → Skills kommen verzögert an, Schadenszahlen erscheinen gebündelt, nur rund um den Boss Zeitlupe - Symptome: Input-Lag, Zeitraffer, Zeitlupe / Faktoren: Stillstand, Latenz - Wer: Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Schadenszahlen und Effekte anderer Spieler bündeln oder weglassen, Zahl der Debuffs auf einem Ziel begrenzen, Trefferverarbeitung auf mehrere Ticks verteilen. - Größenordnungen: Schlagen 800 Spieler je 2-mal pro Sekunde zu, sind das 1.600 Treffer pro Sekunde. Werden alle 800 Zuschauer über jeden Treffer informiert, ergibt das 1,28 Millionen Nachrichten pro Sekunde. - Im Graphen: Steigt mit Spielerzahl und Last (Server-Tick-Zeit, gesendete Nachrichten) - Wo nachsehen: Tick-Zeit und gesendete Pakete während des Bosskampfs zusammen mit der Spielerzahl rund um den Boss betrachten, wenn möglich auch die Ereignisse pro Sekunde und Ziel (Treffer, Buffs, Debuffs) - Spricht dafür: Mit mehr Spielern rund um den Boss steigen Tick-Zeit und Sendevolumen steil an, und der eine Boss hat Dutzende Male mehr Ereignisse pro Sekunde als andere Ziele - Spricht dagegen: Schon das bloße Versammeln an einem Ort bremst auch ohne Boss genauso: eher Sichtbereichsberechnung oder explodierende Broadcast-Last - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Selbst ein einzelner Angriff muss allen zuschauenden Clients gemeldet werden, so entsteht eine O(n²)-Last, bei der n Spieler n Spieler informieren, bei nachrichtenintensiven Drohnenangriffen wächst diese Last noch schneller #### sp-spawn-burst · Spawn-Flut beim Betreten belebter Gebiete · Spawn burst when entering a crowd Reist man per Teleport in eine volle Stadt, muss der Server Aussehen, Ausrüstung und Zustand von Hunderten neu sichtbarer Spieler auf einmal senden. - Warum → Folge → Auf dem Bildschirm: Durch Teleport, Login oder Kanalwechsel taucht man plötzlich an einem belebten Ort auf → Vollständige Daten für Hunderte Spieler werden auf einmal erzeugt und gesendet, und der eigene PC lädt sie ebenfalls auf einmal → Kurzer Freeze direkt nach der Ankunft, Charaktere erscheinen verzögert nacheinander, Eingaben reagieren verzögert - Symptome: Freeze, Input-Lag, Zeitraffer / Faktoren: Stillstand, Latenz - Wer: Nur ich, Bestimmter Ort oder Kanal / Wann: Beim Bewegen oder Zonenwechsel, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: nach Entfernung sortiert auf mehrere Ticks verteilt senden, Aussehensdaten cachen. Client: Daten schon während des Ladebildschirms empfangen, empfangene Charaktere über mehrere Frames verteilt erzeugen. - Größenordnungen: Sind Aussehen, Ausrüstung und Buffs eines Spielers zusammen 300 Byte groß, ergeben 500 Spieler etwa 150 KB. In einem einzigen Moment fällt so Dutzende Male mehr an als die übliche Sendemenge pro Tick (einige KB). - Im Graphen: Ansturm direkt nach Login oder Wartung (Gesendete Bytes pro Verbindung, Frametime des Clients) - Wo nachsehen: In den ersten Sekunden nach Ankunft an einem belebten Ort die über diese Verbindung gesendeten Bytes und Pakete (Serverlog) und die Frametime des Clients (Netgraph, Client-Log) prüfen - Spricht dafür: Direkt nach der Ankunft schießt das Sendevolumen dieser Verbindung auf Dutzende Male den Wert eines normalen Ticks hoch und fällt dann wieder ab, im selben Moment schlägt auch die Frametime des Clients aus - Spricht dagegen: Gleicher Stillstand auch beim Wechsel an einen leeren Ort: eher Zonenwechsel (Übergabe zwischen Servern) oder Laden im Client - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Detailed Actor Replication Flow in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/detailed-actor-replication-flow-in-unreal-engine) · Epic Games · Beim ersten Öffnen eines Actor-Channels werden Startinformationen wie Position und Rotation mitgesendet, ist die Verbindung ausgeschöpft, werden die übrigen Actors auf den nächsten Tick verschoben - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Priorisiert nach Entfernung und Blickrichtung und sendet nahe, sichtbare Actors zuerst #### sp-entity-buildup · Anhäufung von Objekten (nicht aufgeräumte Items und Beschwörungen) · Entity / timer buildup over uptime Werden Items am Boden, Beschwörungen und abgelaufene Timer, die längst verschwunden sein sollten, nicht aufgeräumt, wächst die Arbeit pro Tick, je länger der Server läuft. - Warum → Folge → Auf dem Bildschirm: Items am Boden, Beschwörungen, abgelaufene Timer und Daten leerer Gruppen werden nicht rechtzeitig gelöscht → Die Listen, die jeder Tick durchläuft, werden täglich länger → Direkt nach der Wartung läuft alles normal, nach einigen Tagen wird nur dieser Server oder dieses Gebiet zunehmend träge - Symptome: Zeitlupe, Ruckeln, Input-Lag / Faktoren: Stillstand - Wer: Ganzer Server, Bestimmter Ort oder Kanal / Wann: Je länger es läuft - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Objektzahl pro Gebiet als Metrik erfassen und den Trend beobachten, Lebensdauer und Obergrenzen für Objekte festlegen, regelmäßig aufräumen. - Größenordnungen: Durchläuft der Server in jedem Tick alle Objekte einmal, verdoppelt sich mit der Objektzahl auch dieser Anteil der Tick-Zeit. - Im Graphen: Steigt langsam, fällt abrupt (Objekte pro Zone, Server-Tick-Zeit) - Wo nachsehen: Objektzahl pro Zone und Server (Items am Boden, Beschwörungen, Timer) und Tick-Zeit über einen Zeitraum betrachten, der länger als der Wartungszyklus ist (einige Wochen) - Spricht dafür: Objektzahl und Tick-Zeit starten nach der Wartung niedrig, steigen täglich und fallen bei Wartung oder Neustart abrupt ab, immer wieder, während der Arbeitsspeicher reichlich bleibt - Spricht dagegen: Tick unverändert, nur der Speicherverbrauch steigt stetig: eher Speicherleck - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Wie bei einem Speicherleck wird es schlimmer, je länger der Server läuft. Der Unterschied: Arbeitsspeicher ist reichlich frei, nur die Tick-Zeit steigt. Zeigt der Graph der Objektzahl ein Sägezahnmuster im Wartungsrhythmus, liegt dieser Fall vor. - Quellen: - [Actor Ticking in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-ticking-in-unreal-engine) · Epic Games · Ohne eigenes Intervall tickt jeder Actor und jede Component einmal pro Frame, wird der Tick nicht gebraucht, lässt er sich abschalten - [AActor::SetLifeSpan](https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Engine/AActor/SetLifeSpan) · Epic Games · Hat ein Actor eine Lebensdauer, wird er nach deren Ablauf automatisch zerstört #### sp-patch-traffic · Patch verändert das Traffic-Muster · Patch changes traffic pattern Vergrößern neue Inhalte, Effekte oder synchronisierte Felder die Pakete oder erhöhen ihre Frequenz, stößt ein bisher stabiler Server nach dem Patch an Grenzen bei MTU, Bandbreite oder Paketzahl. - Warum → Folge → Auf dem Bildschirm: Durch neue Skill-Effekte, synchronisierte Felder und Item-Daten im Patch werden Pakete größer oder häufiger → Große Pakete überschreiten die MTU und werden fragmentiert, das zusätzliche Volumen stößt an Bandbreite, PPS-Limit der Cloud und Sendepuffer → Ab dem Patch an belebten Orten Teleportieren, verschluckte Skills und Input-Lag. An der Infrastruktur wurde nichts geändert, trotzdem steigt der Paketverlust - Symptome: Teleportieren, Verschluckte Aktion / Rollback, Input-Lag / Faktoren: Paketverlust, Latenz - Wer: Ganzer Server, Bestimmter Ort oder Kanal, Bestimmte Region oder Provider / Wann: Bei großem Andrang, Abendliche Stoßzeit, Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Pakete selbst auf höchstens 1.200 Byte aufteilen, für neue synchronisierte Felder nur Änderungen senden und die Frequenz nach Entfernung und Wichtigkeit senken, vor dem Deployment auf dem Testserver Pakete und Bytes pro Spieler und Sekunde sowie die größte Paketgröße mit dem vorherigen Build vergleichen, Build-Version in den Traffic-Metriken mitschreiben. - Aufgaben Infrastrukturteam: Server/OS: Deployment-Zeitpunkte im Graphen markieren und Pakete und Bytes pro Spieler und Sekunde sowie die durchschnittliche Paketgröße vor und nach dem Deployment vergleichen, Alarm auf die Zähler für Limitüberschreitungen der Instanz, bei Bedarf größere Instanzen. Netzwerk: Verarbeitungslimits von Firewall, Load-Balancer und DDoS-Schutz prüfen, ebenso ob sie Fragmente blockieren. - Größenordnungen: Sicher sind UDP-Pakete mit höchstens 1.200 Byte. Die Path-MTU im Internet beträgt meist 1.500 Byte, durch Tunnel ist sie kleiner (bei einem GRE-Tunnel 1.476 Byte). Pakete über der Path-MTU werden fragmentiert oder verworfen. Geht bei einem fragmentierten Paket auch nur ein Fragment verloren, ist das ganze Paket verloren. Steigen die Pakete pro Spieler und Sekunde um 20 %, steigt auch die Gesamtmenge des Servers um 20 %. Eine Instanz, die schon nahe am Limit lief, läuft dann sofort über. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (Pakete und Bytes pro Spieler und Sekunde, durchschnittliche Paketgröße) - Wo nachsehen: Pakete und Bytes pro Sekunde der Server-NIC (rxpck/s, txpck/s, rxkB/s, txkB/s aus sar -n DEV, bei EC2 NetworkPacketsOut und NetworkOut) vor und nach dem Deployment durch die Zahl gleichzeitiger Verbindungen teilen und vergleichen. Durchschnittliche Paketgröße = Bytes ÷ Pakete, Größenverteilung über die Statistik Packet Lengths in Wireshark aus einem Paketmitschnitt - Spricht dafür: Ab dem Deployment steigen Pakete und Bytes pro Spieler oder die durchschnittliche Paketgröße stufenartig an und bleiben oben, ab demselben Zeitpunkt steigen die vom Server erzeugten Fragmente (fragcrt/s in sar -n IP) oder die Zähler für Limitüberschreitungen der Instanz (pps_allowance_exceeded und bw_out_allowance_exceeded bei AWS ENA) - Spricht dagegen: Traffic-Muster vor und nach dem Deployment gleich, nur Latenz und Paketverlust gestiegen: Infrastrukturänderungen zur selben Zeit prüfen (Konfiguration, Routen, Geräte, OS- und Kernel-Updates) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Kommt die Meldung „Vor dem Patch lief es gut“, ist dies neben Infrastrukturänderungen die erste Ursache auf Seiten des Spiels, die zu prüfen ist. Auch wenn die Patchnotes keine Netzwerkänderung nennen: An belebten Orten fällt ein einziger neuer Effekt oder ein neues synchronisiertes Feld für Hunderte Spieler gleichzeitig an. Wo das zusätzliche Volumen tatsächlich an Grenzen stößt, behandeln die Einträge „IP-Fragmentierung von UDP-Paketen“, „Überschrittenes PPS-Limit in der Cloud“, „Vollauslastung der NIC-Bandbreite“, „Zu kleine Socket-Puffer im Kernel“ und „Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz)“. Dieser Eintrag beschreibt den Fall, dass ein Spiel-Patch den Traffic erst an diese Grenzen bringt. Bevor man Limits anhebt, reduziert man deshalb zuerst den durch den Patch gestiegenen Traffic. Wurden zur selben Zeit auch OS oder Kernel aktualisiert, zeigt der Traffic pro Spieler, welcher Fall vorliegt: Hat er sich verändert, gilt dieser Eintrag, sonst eher „Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update“. - Quellen: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · UDP-Anwendungen sollen keine Datagramme senden, die die Path-MTU überschreiten (SHOULD NOT), geht ein Fragment verloren, ist das ganze fragmentierte Paket verloren, manche NATs und Firewalls verwerfen alle Fragmente - [RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports](https://www.rfc-editor.org/rfc/rfc8899) · IETF · Für Datagramm-Transporte wie UDP werden 1.200 Byte als sichere Grundgröße (BASE_PLPMTU) empfohlen - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Path-MTU im Internet 1.500, durch einen GRE-Tunnel 1.476 - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · pps_allowance_exceeded und bw_out_allowance_exceeded: Zahl der Pakete, die wegen Überschreitung des PPS- oder Sendebandbreiten-Limits der Instanz in die Queue gestellt oder verworfen wurden - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · rxpck/s und txpck/s (Pakete pro Sekunde) sowie rxkB/s und txkB/s (KB pro Sekunde) in sar -n DEV, fragcrt/s in sar -n IP (erzeugte IP-Fragmente pro Sekunde, ipFragCreates) - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · NetworkPacketsOut (von der Instanz über alle Netzwerkschnittstellen gesendete Pakete) und NetworkOut (gesendete Bytes) - [8.7. Packet Lengths](https://www.wireshark.org/docs/wsug_html_chunked/ChStatPacketLengths.html) · Wireshark · Teilt mitgeschnittene Pakete in Längenbereiche ein und zeigt Anzahl, Mittelwert, Minimum und Maximum ### L10 Arbeitsspeicher (9 Ursachen) #### mem-gc · Stop-the-World-GC-Pause auf dem Server · Stop-the-world GC pause Während ein Java- oder C#-Server alle Threads anhält, um Garbage einzusammeln (Stop-the-World), steht der gesamte Server still. - Warum → Folge → Auf dem Bildschirm: Heap voll, GC startet → Alle Game-Threads angehalten, während die GC sammelt (je mehr lebende Daten, desto länger) → Alle auf dem Server stehen gleichzeitig still, danach Zeitraffer - Symptome: Freeze, Zeitraffer / Faktoren: Stillstand - Wer: Ganzer Server / Wann: In festen Abständen, Je länger es läuft - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: GC mit kurzen Pausen (ZGC, Shenandoah, G1 mit niedrigerem Pausenziel) per Startoption explizit festlegen, Allokationen reduzieren, Heap-Größe anpassen. - Aufgaben Infrastrukturteam: Instanzen mit genug Arbeitsspeicher für einen großzügigen Heap wählen, Containern mindestens 2 CPUs und mindestens ca. 1,8 GB Arbeitsspeicher zuweisen (darunter wählt Java bis JDK 26 standardmäßig die Serial GC), GC-Pausenzeiten überwachen. - Größenordnungen: Eine Minor GC, die nur neue Objekte (Young Generation) sammelt, dauert im ein- bis zweistelligen Millisekundenbereich. Eine Full GC über den gesamten Heap mit mehreren GB lebender Daten kann länger als 1 s dauern. ZGC bleibt fast unabhängig von der Heap-Größe unter 1 ms, und auch bei Shenandoah sind die Pausen kurz, weil sie nicht mit der Heap-Größe wachsen. - Im Graphen: Spitzen in festen Abständen (Server-Tick-Zeit, GC-Pausenzeit) - Wo nachsehen: GC-Log aktivieren und Zeitpunkt und Dauer der Pausen über den Graphen der Server-Tick-Zeit legen. Java: Pause-Zeilen der Startoption -Xlog:gc* (bis JDK 8: -XX:+PrintGCDetails), .NET: GC-Pausenmetrik in dotnet-counters (ab .NET 9 dotnet.gc.pause.time, bis 8 % Time in GC since last GC), Go: die Zeile, die GODEBUG=gctrace=1 pro GC schreibt - Spricht dafür: Tick-Spitzen und GC-Pausen fallen zeitlich zusammen, Pausendauer etwa gleich Spitzendauer. Alle Zonen und Kanäle des Servers schlagen im selben Moment aus - Spricht dagegen: Keine langen Pausen im GC-Log, Tick schlägt trotzdem aus: andere Ursache wie Locks, synchrone Aufrufe oder Schreibzugriffe auf den Datenträger. Nur eine Zone schlägt aus: GC der Skript-Engine (mem-script-gc) oder Last in dieser Zone - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Bei Java liegt das Standard-Pausenziel von G1 bei 200 ms pro Pause. Auf einem Server mit 20 Ticks pro Sekunde sind das 4 Ticks. Bekommt ein Container weniger als 2 CPUs oder weniger als etwa 1,8 GB Arbeitsspeicher, wählt Java bis JDK 26 die Serial GC als Standard. Sie sammelt mit einem einzigen Thread, und die Pausen werden deutlich länger. C#-Server (.NET) schalten meist Server-GC und Background-GC ein. Die Sammlung der Generationen 0 und 1 (Gen0/1), in denen neue Objekte liegen, und eine Full GC mit Kompaktierung halten trotzdem alle Threads an. Bei Go liegen die Pausen meist unter 1 ms. Bei vielen Allokationen muss aber der Code, der Speicher anfordert, einen Teil der GC-Arbeit übernehmen, und der Tick wird langsamer. Für jedes Verfahren gilt: Wird schneller alloziert als gesammelt, bleibt am Ende der Game-Thread stehen. G1 fällt dann auf eine Full GC zurück, ZGC hält den anfordernden Thread an, bis die Sammlung fertig ist. - Reale Fälle: riot-euw-2021 - Quellen: - [Garbage-First (G1) Garbage Collector](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-first-g1-garbage-collector1.html) · Oracle · Standard-Pausenziel von G1: 200 ms (MaxGCPauseMillis). Geht während der Sammlung der Speicher aus, Rückfall auf eine Full GC, die alles anhält und den gesamten Heap kompaktiert - [JEP 523: Make G1 the Default Garbage Collector in All Environments](https://openjdk.org/jeps/523) · OpenJDK · Bisher war bei 1 CPU oder weniger als 1.792 MB Arbeitsspeicher die Serial GC Standard, ab JDK 27 ist überall G1 Standard - [JEP 439: Generational ZGC](https://openjdk.org/jeps/439) · OpenJDK · ZGC-Pausen höchstens 1 ms und unabhängig von der Heap-Größe, G1-Pausen einige ms bis einige Sekunden. Wird schneller alloziert als freigegeben, droht ein Allocation Stall (Anhalten bei der Allokation) - [JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)](https://openjdk.org/jeps/189) · OpenJDK · Shenandoah-Pausenzeiten sind ähnlich, ob der Heap 200 MB oder 200 GB groß ist - [Background garbage collection](https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/background-gc) · .NET · Background-GC gilt nur für Sammlungen der Generation 2, Sammlungen der Generationen 0 und 1 (Foreground-GC) halten alle verwalteten Threads an - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Die Go-GC läuft größtenteils nebenläufig und hat nur kurze Stop-the-World-Pausen, bei vielen Allokationen übernehmen Goroutinen GC-Arbeit (Assist), was zu Verzögerungen führt - [JEP 271: Unified GC Logging](https://openjdk.org/jeps/271) · OpenJDK · Ab JDK 9 GC-Logging auf Basis von Unified Logging (-Xlog) neu implementiert, -Xlog:gc schreibt wie früher -XX:+PrintGC eine Zeile pro GC - [The java Command](https://docs.oracle.com/en/java/javase/25/docs/specs/man/java.html) · Oracle · Tabelle zur Umstellung alter GC-Log-Optionen auf -Xlog: aus -XX:+PrintGCDetails wird -Xlog:gc* - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · Ab .NET 9 Anzeige über System.Runtime-Meter (dotnet.gc.pause.time u. a.), bis .NET 8 über die älteren EventCounter (% Time in GC since last GC u. a.) - [runtime package](https://pkg.go.dev/runtime) · Go · GODEBUG=gctrace=1: eine Zeile pro GC mit Wall-Clock-Zeit pro Phase, Heap-Größe zu Beginn und Ende der GC sowie Ziel-Heap #### mem-script-gc · GC-Pause der Skript-Engine · Scripting VM GC (Lua, etc.) Laufen Quests, KI und Skills in einer Skriptsprache wie Lua, steht selbst auf einem C++-Server die Zone still, solange die GC der Skript-Engine läuft. - Warum → Folge → Auf dem Bildschirm: Skript-Engine jeder Zone erzeugt beim Ausführen von Quests, KI und Events massenhaft temporäre Objekte → Sammelt die GC der Skript-Engine viel auf einmal, bleibt der Tick dieser Zone stehen → Kurzes Stocken in festen Abständen, nur in bestimmten Zonen oder während bestimmter Events - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal / Wann: Bei großem Andrang, In festen Abständen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Inkrementelle oder generationelle GC einstellen, GC in jedem Tick ein Stück weiterlaufen lassen, temporäre Objekte in Skripten reduzieren. - Größenordnungen: Wächst der Skript-Heap auf mehrere hundert MB, kann eine Sammlung in einem Durchgang (bei abgeschalteter inkrementeller Sammlung oder als vollständige Sammlung im generationellen Modus) einige Dutzend bis mehrere hundert ms dauern. - Im Graphen: Spitzen in festen Abständen (Tick-Zeit pro Zone, Speicher der Skript-Engine) - Wo nachsehen: Tick-Zeit pro Zone und Speicherverbrauch der Skript-Engine dieser Zone (in Lua collectgarbage("count")) in jedem Tick aufzeichnen und in einem Graphen übereinanderlegen - Spricht dafür: Momente, in denen der Skript-Speicher abrupt fällt (Sammlung in einem Durchgang), fallen mit Tick-Spitzen dieser Zone zusammen, andere Zonen sind unauffällig - Spricht dagegen: Spitzen ohne Änderung im Skript-Speicher: Last oder Locks in dieser Zone. Alle Zonen des Servers schlagen gleichzeitig aus: GC des Servers (mem-gc) oder Swap (mem-swap) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Lua 5.4 Reference Manual](https://www.lua.org/manual/5.4/manual.html) · Lua.org · Der inkrementelle Modus teilt die Sammlung in kleine Schritte zwischen der Programmausführung auf (große Schritte bedeuten Stop-the-World), eine Major-Sammlung im generationellen Modus ist ein Stop-the-World-Durchlauf über alle Objekte, collectgarbage("count") liefert den gesamten von Lua belegten Speicher (KB) #### mem-alloc · Allokationsflut · Allocation storms Entstehen während eines Events massenhaft temporäre Objekte, läuft die GC viel häufiger als sonst. - Warum → Folge → Auf dem Bildschirm: Item-Drops, Kampflogs und Event-Belohnungen lassen die Zahl temporärer Objekte explodieren → GC läuft um ein Vielfaches häufiger, noch nicht verworfene Objekte wandern in die Old Generation, dadurch kommt auch die Full GC früher → Kurzes Stocken in festen Abständen, nur während Events - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Ganzer Server, Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Objekt-Pools und wiederverwendbare Puffer nutzen, Allokationen mit einem Profiler untersuchen. - Im Graphen: Steigt mit Spielerzahl und Last (Anzahl der GCs, Allokationsrate) - Wo nachsehen: GCs pro Minute im GC-Log zählen (Java -Xlog:gc, Go GODEBUG=gctrace=1), bei .NET Allokationsmenge und GC-Anzahl in dotnet-counters prüfen (ab .NET 9 dotnet.gc.heap.total_allocated und dotnet.gc.collections, bis 8 Allocation Rate und Gen 0 GC Count). Mit der Zahl gleichzeitiger Spieler und den Event-Zeiten übereinanderlegen - Spricht dafür: Mit Event-Beginn steigen Allokationsrate und GC-Anzahl steiler als die Spielerzahl, kurze Pausen häufen sich. Nach dem Event wieder normal - Spricht dagegen: GC-Anzahl unverändert, aber einzelne Pausen werden länger: Die lebenden Daten sind gewachsen (mem-gc-thrash, mem-leak) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · Ist die Young Generation voll, folgt eine Minor GC. Ein Teil der überlebenden Objekte wandert in die Old Generation, ist diese voll, wird der gesamte Heap gesammelt (dauert viel länger als eine Minor GC), -Xlog:gc schreibt eine Zeile pro GC - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Je höher die Allokationsrate, desto häufiger die GC-Zyklen, GODEBUG=gctrace=1 gibt einen GC-Trace aus - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · Ab .NET 9 Anzeige als dotnet.gc.heap.total_allocated und dotnet.gc.collections, bis .NET 8 als Allocation Rate und Gen 0 GC Count #### mem-leak · Speicherleck · Memory leak Nicht freigegebener Speicher sammelt sich nach und nach an und führt Tage später zu GC-Stürmen, Swapping oder zum erzwungenen Beenden des Prozesses. - Warum → Folge → Auf dem Bildschirm: Daten ausgeloggter Charaktere und Event-Handler werden nicht freigegeben → Freier Speicher nimmt über mehrere Tage ab → Direkt nach der Wartung unauffällig, mit jedem Tag mehr Lag, am Ende fällt der Server aus - Symptome: Zeitlupe, Freeze, Verbindungsabbruch / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Je länger es läuft, Abendliche Stoßzeit - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Heap-Dumps analysieren, Langzeit-Lasttests durchführen. - Aufgaben Infrastrukturteam: Trend des Speicherverbrauchs pro Prozess überwachen und Alarme dafür einrichten. - Im Graphen: Langsamer Anstieg (Prozessspeicher (RSS), Heap nach der GC) - Wo nachsehen: Speicher des Spielserverprozesses (RSS aus pidstat -r) über mehrere Tage verfolgen, bei Servern mit GC den direkt nach der GC verbleibenden Heap. Java: der Wert nach der GC aus der Vorher-/Nachher-Belegung in den -Xlog:gc-Zeilen, .NET: Heap-Größe nach der GC in dotnet-counters (ab .NET 9 dotnet.gc.last_collection.heap.size, bis 8 GC Heap Size) - Spricht dafür: Der direkt nach der GC verbleibende Heap (Grundlinie) steigt nach dem Neustart jeden Tag und sinkt auch in den ruhigen frühen Morgenstunden nicht - Spricht dagegen: Heap-Grundlinie flach, nur RSS steigt: Fragmentierung (mem-fragment) oder nativer Speicher. Steigt und fällt mit der Spielerzahl: normaler Verbrauch - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Wird der Server bei der regelmäßigen Wartung jede Woche neu gestartet, bleibt ein Leck verdeckt und lange unentdeckt. Oft tritt es plötzlich zutage, wenn eine Wartung einmal verschoben wird oder ein Event mehr Spieler bringt. - Quellen: - [Troubleshoot Memory Leaks](https://docs.oracle.com/en/java/javase/25/troubleshoot/troubleshooting-memory-leaks.html) · Oracle · Wird die Ausführung allmählich langsamer, liegt ein Leck nahe, am Ende geht der Speicher aus und das Programm bricht ab. Wichtigste Grundlage der Leckanalyse ist ein Heap-Dump - [Debug a memory leak in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak) · .NET · Auch mit GC entsteht ein Leck, wenn nicht mehr benötigte Objekte weiter referenziert werden, Folge sind Leistungseinbußen und OutOfMemoryException. Speichertrend prüfen und Dumps analysieren - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · -Xlog:gc-Zeilen haben das Format „Belegung vor der GC->Belegung nach der GC(Heap-Größe)“ - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · Ab .NET 9 Anzeige als dotnet.gc.last_collection.heap.size, bis .NET 8 als GC Heap Size - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -r: RSS pro Prozess (tatsächlich im RAM liegender Speicher) und Page Faults #### mem-gc-thrash · GC-Thrashing (zu wenig Heap-Reserve) · GC thrashing (heap nearly full) Nähern sich die lebenden Daten der Heap-Grenze, findet jede GC kaum noch etwas zum Freigeben, und die GC läuft ununterbrochen immer wieder. - Warum → Folge → Auf dem Bildschirm: Lebende Daten erreichen durch Event-Andrang oder ein Leck fast die Heap-Grenze → GC gibt nur wenig frei, sofort folgt die nächste Full GC, der Großteil der CPU-Zeit geht an die GC → Ganzer Server wechselt einige Minuten lang zwischen Zeitlupe und Freeze, bis der Prozess wegen Speichermangels beendet wird - Symptome: Zeitlupe, Freeze, Verbindungsabbruch / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Abendliche Stoßzeit, Bei großem Andrang, Je länger es läuft - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Heap deutlich größer als die lebenden Daten zur Spitzenzeit wählen (meist mindestens das 2-Fache), lange referenzierte Daten und Lecks reduzieren. - Aufgaben Infrastrukturteam: Alarm auf den GC-Zeitanteil einrichten, früh neu starten, ohne auf Erholung zu warten, Instanzen mit genug Arbeitsspeicher wählen, damit der Heap wachsen kann. - Größenordnungen: Beansprucht die GC mehr als 10 % der Laufzeit, gilt das meist als Warnsignal. Einige GCs in Java melden einen Out-of-Memory-Fehler, wenn sie 98 % der Zeit mit GC verbringen und trotzdem kaum etwas freigeben. - Im Graphen: Plateau am Limit (Heap nach der GC, GC-Zeitanteil) - Wo nachsehen: Prüfen, wie nahe der direkt nach der GC verbleibende Heap am maximalen Heap liegt und welcher Zeitanteil auf die GC entfällt. Java: „nach der GC(Heap-Größe)“ in den -Xlog:gc-Zeilen und Häufigkeit der Zeilen mit Pause Full, .NET: dotnet-counters (bis .NET 8 % Time in GC since last GC, ab .NET 9 Zuwachs von dotnet.gc.pause.time), Go: Abstand zwischen den Zeilen von GODEBUG=gctrace=1 - Spricht dafür: Heap bleibt auch direkt nach der GC nahe am Maximum, Full GCs laufen direkt hintereinander, GC-Zeitanteil steigt weit über den Normalwert (meist über 10 %). Währenddessen werden die Ticks des ganzen Servers langsamer - Spricht dagegen: Nach der GC genug Heap frei, nur die Pausen sind lang: GC-Verfahren oder -Einstellungen (mem-gc) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [The Parallel Collector](https://docs.oracle.com/en/java/javase/25/gctuning/parallel-collector1.html) · Oracle · Parallel GC wirft OutOfMemoryError, wenn sie über 98 % der Gesamtzeit mit GC verbringt und weniger als 2 % des Heaps freigibt - [Garbage-First Garbage Collector Tuning](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-first-garbage-collector-tuning.html) · Oracle · G1 bemisst den Heap standardmäßig (GCTimeRatio=12) so, dass die GC-Zeit bei höchstens etwa 8 % der Gesamtzeit liegt, Full GCs wegen zu hoher Heap-Belegung erscheinen im Log als Pause Full (G1 Compaction Pause) - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Mit dem Standardwert GOGC=100 liegt der Ziel-Heap bei etwa dem 2-Fachen des lebenden Heaps, nahe am Speicherlimit läuft die GC ununterbrochen (Thrashing), GODEBUG=gctrace=1 gibt einen GC-Trace aus - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · -Xlog:gc-Zeilen zeigen GC-Art (Pause Young, Pause Full), „Belegung vor der GC->Belegung nach der GC(Heap-Größe)“ und Pausendauer - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · Ab .NET 9 Anzeige als dotnet.gc.pause.time, bis .NET 8 als % Time in GC since last GC #### mem-swap · Swap · Swapping Wird der Arbeitsspeicher knapp und lagert das OS einen Teil auf den Datenträger aus, wartet jeder Zugriff auf diesen Speicher auf einen über 1.000-mal langsameren Datenträger. - Warum → Folge → Auf dem Bildschirm: Belegter Speicher übersteigt den physischen RAM → OS lagert einen Teil auf den Datenträger aus und liest ihn bei Bedarf zurück → Ticks schnellen auf mehrere hundert ms hoch, alle Spieler auf dem Server erleben Zeitlupe und Freezes - Symptome: Zeitlupe, Freeze / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Je länger es läuft, Abendliche Stoßzeit - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Speicherverbrauch des Prozesses begrenzen (Heap-Größe u. a.), auf Lecks prüfen. - Aufgaben Infrastrukturteam: Spielserver so konfigurieren, dass sie keinen Swap nutzen, auf Speicheralarme reagieren, RAM großzügig über dem Spitzenverbrauch einplanen, denn ohne Swap wird der Prozess beendet (OOM), sobald der Speicher ausgeht. - Größenordnungen: Ein RAM-Zugriff dauert etwa 100 ns, das Zurücklesen von einer SSD etwa 100 µs (1.000-mal so lange), von einem über das Netzwerk angebundenen Cloud-Datenträger etwa 1 ms (10.000-mal) und von einer HDD 10 ms (100.000-mal). - Im Graphen: Langsamer Anstieg (Swap-Belegung, Swap-in/-out) - Wo nachsehen: Spalten si und so von vmstat 1 (pro Sekunde aus dem Swap eingelesene bzw. ausgelagerte Menge), some und full in /proc/pressure/memory (Zeitanteil, in dem auf Speicher gewartet wurde) und majflt/s aus pidstat -r für den Spielserverprozess (Page Faults, die vom Datenträger nachladen mussten) über die Tick-Zeit legen - Spricht dafür: Zum Zeitpunkt des Lags ist si größer als 0, majflt/s des Spielservers und der full-Wert von memory steigen gemeinsam - Spricht dagegen: si und so bei 0, Speicherdruck (PSI) nahe 0: Swap scheidet aus. Kein Swap, aber majflt/s und PSI steigen: Speicher fast erschöpft, Code-Seiten werden neu eingelesen, zuerst Speicher freimachen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Ein Server mit GC liest beim Sammeln den ganzen Heap kreuz und quer. Ist auch nur ein Teil des Heaps ausgelagert, kann eine einzelne GC einige bis einige Dutzend Sekunden dauern. Ohne Swap entfällt die Phase, in der das Auslagern bremst, und der Prozess wird direkt beendet (OOM). Deshalb muss zuerst genug freier Speicher eingeplant werden. Auch ohne Swap kann der ganze Server vor dem erzwungenen Beenden eine Weile stark langsamer werden: Ist der Speicher fast erschöpft, entfernt das OS sogar die Code-Seiten der ausführbaren Datei aus dem Speicher und liest sie erneut ein. - Quellen: - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · „Numbers Everyone Should Know“: Hauptspeicherzugriff 100 ns, Disk-Seek 10 ms (Stand 2009) - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · swappiness: relative Kosten von Swapping und dem Freigeben von Dateiseiten, Swap ist Random-I/O und daher teuer - [Concepts overview](https://docs.kernel.org/admin-guide/mm/concepts.html) · Linux kernel · Der Kernel gibt Page Cache mit Original auf dem Datenträger und auslagerbare Seiten frei, reicht das nicht, beendet der OOM-Killer einen Prozess - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · Latenz im 99,99. Perzentil (Four-Nines Latency) von Server-NVMe-SSDs 130 µs: Beleg dafür, dass ein einzelner SSD-Lesezugriff um die 100 µs dauert - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Latenz des Standard-Cloud-Datenträgers (gp3) im einstelligen Millisekundenbereich - [vmstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/vmstat.8.html) · procps-ng · si: pro Sekunde aus dem Swap eingelesener Speicher, so: pro Sekunde in den Swap ausgelagerter Speicher - [PSI - Pressure Stall Information](https://docs.kernel.org/accounting/psi.html) · Linux kernel · some (Zeitanteil, in dem einige Tasks blockiert waren) und full (Zeitanteil, in dem alle Tasks gleichzeitig blockiert waren) in /proc/pressure/memory - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -r: majflt/s (Faults, bei denen eine Seite vom Datenträger gelesen werden musste) #### mem-cache-miss · Cache-Miss · CPU cache misses Liegen Daten verstreut im Speicher, muss die CPU jedes Mal bis zum langsamen RAM gehen und warten. - Warum → Folge → Auf dem Bildschirm: Objekte über Zeiger verstreut, Zugriff ohne feste Reihenfolge → Daten nicht im CPU-Cache, also jedes Mal Lesen aus dem RAM (rund 100-mal langsamer) → Gleiche Arbeit kostet ein Vielfaches an Tick-Zeit, im schlimmsten Fall Zeitlupe - Symptome: Zeitlupe / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Immer, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Häufig gemeinsam genutzte Daten zusammenhängend im Speicher anordnen (datenorientiertes Design). - Im Graphen: Von Anfang an dauerhaft hoch (Tick-Zeit, CPU-Auslastung) - Wo nachsehen: perf stat -d -p PID an den Spielserverprozess hängen, Instruktionen pro Takt (insn per cycle) sowie L1- und LLC-Cache-Misses messen und zusammen mit Tick-Zeit und CPU-Auslastung auswerten - Spricht dafür: CPU dauerhaft ausgelastet, aber insn per cycle niedrig und viele LLC-Misses. Bestätigt, wenn ein Build mit geändertem Datenlayout die Tick-Zeit bei gleicher Spielerzahl deutlich senkt - Spricht dagegen: CPU-Auslastung niedrig, Ticks trotzdem langsam: Ursache, die außerhalb der CPU wartet, etwa Locks oder I/O-Wartezeiten - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · L1-Cache 0,5 ns, L2-Cache 7 ns, Hauptspeicher 100 ns (Stand 2009): Ein Zugriff auf den RAM ist ein bis zwei Größenordnungen langsamer als auf den Cache - [perf-stat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-stat.1.html) · perf · -p zählt Hardware-Events eines laufenden Prozesses und zeigt insn per cycle, -d ergänzt Events der L1- und LLC-Datencaches #### mem-fragment · Speicherfragmentierung · Heap fragmentation Zerfällt freier Speicher durch ständiges Allozieren und Freigeben in kleine Stücke, belegt der Prozess viel mehr Speicher, als er tatsächlich nutzt. - Warum → Folge → Auf dem Bildschirm: Viele Threads allozieren und geben über lange Zeit Speicherblöcke unterschiedlicher Größe frei → Freier Speicher in kleinen Stücken verstreut, kann nicht ans OS zurückgegeben werden, Verbrauch steigt wie bei einem Leck immer weiter → Je länger der Server läuft, desto langsamer wird er durch Swap und Speichermangel, bis er zwangsweise beendet wird - Symptome: Zeitlupe, Verbindungsabbruch / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Je länger es läuft - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Speicher-Pools pro Blockgröße und fragmentierungsresistente Allokatoren (jemalloc, mimalloc u. a.) einsetzen. - Im Graphen: Langsamer Anstieg (Prozessspeicher (RSS)) - Wo nachsehen: Zwei Server mit demselben Build starten, nur bei einem die Zahl der glibc-Arenen per Umgebungsvariable MALLOC_ARENA_MAX senken oder auf einen anderen Allokator wie jemalloc wechseln, dann einige Tage lang RSS aus pidstat -r vergleichen - Spricht dafür: Bei ähnlicher Spieler- und Objektzahl hört der RSS-Anstieg nur beim geänderten Server auf oder fällt deutlich geringer aus - Spricht dagegen: Steigt nach dem Allokatorwechsel genauso: nie freigegebener Speicher (mem-leak) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Der Verlauf sieht aus wie bei einem Speicherleck, doch die Heap-Analyse findet keine Leckstelle. Beim Standard-Allokator von Linux (glibc) ist das Problem auf Servern mit vielen Threads besonders ausgeprägt. Schon ein Wechsel des Allokators kann den Verbrauch deutlich senken. - Quellen: - [mallopt(3) — Linux manual page](https://man7.org/linux/man-pages/man3/mallopt.3.html) · Linux man-pages · glibc malloc legt zur Verringerung von Thread-Contention Arenen bis zu einem Vielfachen der CPU-Anzahl an, mehr Arenen bedeuten mehr Speicherverbrauch (Begrenzung mit M_ARENA_MAX, auch per Umgebungsvariable MALLOC_ARENA_MAX einstellbar) - [jemalloc memory allocator](https://jemalloc.net/) · jemalloc · Allgemeine malloc-Implementierung mit Schwerpunkt auf Vermeidung von Fragmentierung und skalierbarer Nebenläufigkeit - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -r: RSS pro Prozess (tatsächlich im RAM liegender Speicher) #### mem-numa · Entfernter NUMA-Speicher · Remote NUMA access Nutzt ein Prozess auf einem Server mit zwei CPUs Speicher, der an der anderen CPU hängt, werden die Zugriffe langsamer. - Warum → Folge → Auf dem Bildschirm: Threads und ihr Speicher liegen auf verschiedenen CPU-Sockeln → Speicherzugriffe werden langsamer (je nach Hardware um das 1,5- bis 2-Fache) → Gleiche Ausstattung, aber Leistungsunterschiede von Prozess zu Prozess - Symptome: Zeitlupe / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Prozesse und ihren Speicher an einen Sockel binden (numactl), bei zwei Sockeln je Sockel eigene Spielserverprozesse betreiben. - Im Graphen: Nur einzelne Ausreißer (Tick-Zeit pro Prozess, Speicher pro Knoten) - Wo nachsehen: Mit numastat -p PID prüfen, auf welchem NUMA-Knoten der Speicher des Spielserverprozesses liegt und ob numa_miss und other_node in numastat steigen, dann mit dem Knoten der CPU vergleichen, auf der der Prozess läuft - Spricht dafür: Nur bei den langsamen Prozessen liegt der Großteil des Speichers auf einem anderen Knoten als die CPU, auf der sie laufen, und nach einem Neustart mit per numactl an einen Knoten gebundener CPU und gebundenem Speicher verschwindet der Unterschied - Spricht dagegen: Gleiche Knotenverteilung wie bei den schnellen Prozessen, trotzdem langsam: andere Ursache wie Noisy Neighbor, CPU-Throttling oder Last dieses Prozesses - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [What is NUMA?](https://docs.kernel.org/mm/numa.html) · Linux kernel · Speicher in derselben Zelle ist schneller und hat mehr Bandbreite, Zugriffe auf Speicher in einer anderen (entfernten) Zelle sind langsamer - [numactl(8) — Linux manual page](https://man7.org/linux/man-pages/man8/numactl.8.html) · numactl · --cpunodebind und --membind binden CPU und Speicher eines Prozesses an bestimmte NUMA-Knoten - [numastat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/numastat.8.html) · numactl · Zähler numa_miss (Allokation auf einem anderen als dem gewünschten Knoten) und other_node (Allokation auf diesem Knoten durch einen Prozess, der auf einem anderen Knoten läuft), -p zeigt den Speicher eines Prozesses pro Knoten ### L11 Datenträger (9 Ursachen) #### dk-sync-log · Synchrones Schreiben von Logs · Synchronous logging Wartet der Game-Thread bei jeder Logzeile, bis der Datenträger fertig ist, bleibt bei ausgelastetem Datenträger auch das Spielgeschehen stehen. - Warum → Folge → Auf dem Bildschirm: Kampf- und Handelslogs werden direkt aus dem Game-Thread in eine Datei geschrieben → Wird sicheres Speichern (fsync) verlangt oder ist der Schreibpuffer des OS (Page Cache) am Limit, dauert bei ausgelastetem Datenträger ein einzelner Schreibvorgang einige Dutzend ms → Kurzes Stocken in Kämpfen mit vielen Logeinträgen - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Asynchron loggen (Puffer im Speicher + eigener Thread), Logmenge reduzieren, im Game-Thread kein fsync aufrufen. - Aufgaben Infrastrukturteam: Log-Rotation und -Komprimierung mit niedriger I/O-Priorität ausführen, Logs auf einem anderen Datenträger als die Daten ablegen, Disk-Schreiblatenz überwachen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Server-Tick-Zeit, Disk-Schreiblatenz) - Wo nachsehen: w_await und aqu-sz aus iostat -x 1 über die Tick-Zeit legen, mit perf trace -p PID --duration 10 write- und fsync-Aufrufe im Spielserver finden, die länger als 10 ms dauerten, samt zugehörigem Thread - Spricht dafür: Zu den Tick-Spitzen dauern write- und fsync-Aufrufe des Game-Threads einige Dutzend ms, im selben Moment schießt die Disk-Schreiblatenz hoch. Fällt oft mit Log-Rotation oder -Komprimierung zusammen - Spricht dagegen: Keine langsamen Systemaufrufe im Game-Thread, Tick schlägt trotzdem aus: andere Ursache wie GC, Locks oder überschrittenes Tick-Budget. Nur der eigene Log-Thread ist langsam: kein Einfluss auf das Spielgeschehen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Normalerweise nimmt das OS Schreibvorgänge zuerst im Arbeitsspeicher (Page Cache) an und schreibt sie später auf den Datenträger. Eine Logzeile ist daher meist sofort erledigt. Stillstand entsteht, wenn fsync sicheres Speichern verlangt, wenn aufgestaute Schreibvorgänge ein Limit überschreiten und das OS den Schreibaufruf blockiert oder wenn Logdateien rotiert oder komprimiert werden. Deshalb ist meist alles unauffällig, und Spitzen gibt es nur in Momenten, in denen der Datenträger ausgelastet ist. - Quellen: - [fsync(2) — Linux manual page](https://man7.org/linux/man-pages/man2/fsync.2.html) · Linux man-pages · fsync schreibt geänderte Daten bis auf den Datenträger (einschließlich Disk-Cache) und blockiert, bis das Gerät den Abschluss meldet - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · Erreichen aufgestaute Schreibvorgänge (dirty) dirty_ratio, muss der schreibende Prozess das Zurückschreiben auf den Datenträger selbst übernehmen - [ionice(1) — Linux manual page](https://man7.org/linux/man-pages/man1/ionice.1.html) · util-linux · Ein Job mit I/O-Priorität idle bekommt nur dann Zeit auf dem Datenträger, wenn kein anderes Programm ihn nutzt - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: w_await (durchschnittliche Bearbeitungszeit von Schreibanfragen einschließlich Wartezeit in der Warteschlange), aqu-sz (durchschnittliche Warteschlangenlänge, früher avgqu-sz) - [perf-trace(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-trace.1.html) · perf · -p verfolgt die Systemaufrufe eines laufenden Prozesses, --duration zeigt nur Aufrufe, die länger als die angegebenen ms dauerten #### dk-fsync · fsync-Flut · fsync storms Eine Anfrage, Daten „sicher“ auf den Datenträger zu schreiben, dauert je nach Datenträger 0,1 ms bis einige Dutzend ms. Häufen sich solche Anfragen, wird die Warteschlange lang. - Warum → Folge → Auf dem Bildschirm: Regelmäßiges Speichern und Logout-Wellen lösen massenhaft Anfragen zum sicheren Schreiben aus → Disk-Warteschlange wird länger → Lag zu jedem Speicherzeitpunkt, verzögerter Logout und Kanalwechsel - Symptome: Ruckeln, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Ganzer Server / Wann: In festen Abständen, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Speichervorgänge bündeln (mehrere Speichervorgänge mit einem fsync), Speicherzeitpunkte verteilen. - Aufgaben Infrastrukturteam: Server/OS: Server-SSDs mit Stromausfallschutz einsetzen, Länge der Disk-Warteschlange und fsync-Latenz überwachen. DB-Systeme: Geht das Speichern in die DB, auch den Datenträger für das DB-Log auf solche SSDs legen, Commit-Latenz überwachen. - Größenordnungen: Die Dauer pro Aufruf hängt von der Hardware ab, grob gilt: Server-SSD (mit Stromausfallschutz) 0,1 ms, normale SSD 1 bis einige ms, Cloud-Datenträger 1–2 ms, HDD mindestens 10 ms. Wartet ein einzelner Thread jeden Aufruf einzeln ab, schafft eine HDD nicht einmal 100 pro Sekunde. - Im Graphen: Spitzen in festen Abständen (Länge der Disk-Warteschlange, Flush- und Schreiblatenz) - Wo nachsehen: f/s und f_await (vom Datenträger verarbeitete Flushes und deren Dauer) sowie w/s, aqu-sz und w_await aus iostat -x 1 über die Zeitpunkte von regelmäßigem Speichern und Logouts legen. Ältere sysstat-Versionen zeigen aqu-sz als avgqu-sz. Bei Cloud-Datenträgern VolumeQueueLength und VolumeAvgWriteLatency von EBS prüfen - Spricht dafür: Zu jedem Speicherzeitpunkt und jeder Logout-Welle schießen Flush-Anzahl und Warteschlangenlänge gemeinsam hoch, w_await und f_await erreichen ein Mehrfaches des Normalwerts. Speichern und Kanalwechsel verzögern sich dann - Spricht dagegen: Warteschlange schießt zu Zeiten ohne Speichern oder Logouts hoch: Backup oder Komprimierung (dk-backup) oder IOPS-Limit (dk-iops). Gleiche Flush-Anzahl, aber langsamer: eher aufgebrauchte Burst-Credits (dk-burst) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [fsync(2) — Linux manual page](https://man7.org/linux/man-pages/man2/fsync.2.html) · Linux man-pages · fsync leert auch den Disk-Cache und blockiert, bis das Gerät den Abschluss meldet - [Reliability (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-reliability.html) · PostgreSQL · Normale SATA-Festplatten und viele SSDs haben Schreibcaches, deren Inhalt bei Stromausfall verloren geht, für sicheres Speichern ist ein Cache mit Batterie oder Stromausfallschutz nötig - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Latenz des Standard-Cloud-Datenträgers (gp3) im einstelligen Millisekundenbereich, io2 Block Express bei 16-KiB-I/O im Mittel unter 500 µs - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Ein Seek auf der HDD 10 ms - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: f/s und f_await (vom Datenträger verarbeitete Flush-Anfragen und deren durchschnittliche Dauer), w/s, w_await, aqu-sz (früher avgqu-sz) - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · VolumeQueueLength (Anzahl der Anfragen, die auf Abschluss warten), VolumeAvgWriteLatency (Schreiblatenz im 1-Minuten-Mittel, Nitro-Instanzen) #### dk-burst · Aufgebrauchte Burst-Credits beim Cloud-Datenträger · Burst credit depletion Manche Cloud-Datenträger und kleine Servergrößen haben Burst-Credits, mit denen sie kurzzeitig schneller als ihre Basisleistung arbeiten. Dauert eine Lastphase lange und sind die Credits aufgebraucht, sinkt die Geschwindigkeit schlagartig. - Warum → Folge → Auf dem Bildschirm: Lange Nutzung oberhalb der Basisleistung → Burst-Credits aufgebraucht, Leistung fällt abrupt auf die Basisleistung → Jeden Abend beginnt der Lag erst nach einigen Stunden - Symptome: Ruckeln, Zeitlupe, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Ganzer Server / Wann: Abendliche Stoßzeit, Je länger es läuft - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Server/OS: Datenträger mit garantierter Leistung einsetzen (gp3, Provisioned IOPS), Alarm auf das Credit-Guthaben einrichten, auch das Burst-Limit der Disk-Bandbreite der Instanz und die CPU-Credits prüfen. DB-Systeme: auch DB-Datenträger, einschließlich verwalteter Datenbanken, auf garantierte Leistung umstellen, Alarm auf das Credit-Guthaben einrichten. - Größenordnungen: Ein AWS-gp2-Datenträger mit 100 GB liefert normalerweise 300 IOPS, im Burst 3.000 IOPS, und hält mit vollem Guthaben etwa 30 Minuten durch. gp3 hat keine Credits und liefert immer 3.000. Auch kleine Premium SSDs von Azure laufen mit Credits bis zu 30 Minuten im Burst. - Im Graphen: Plateau am Limit (IOPS, Burst-Credit-Guthaben) - Wo nachsehen: In CloudWatch BurstBalance von EBS (gp2, st1, sc1), EBSIOBalance% und EBSByteBalance% der Instanz (einige Instanzen mit Burst) und CPUCreditBalance bei burstfähigen Instanzen prüfen. Bei Azure Metriken zur Nutzung der Burst-Credits wie Data Disk Used Burst IO Credits Percentage prüfen - Spricht dafür: Ab dem Zeitpunkt, an dem das Guthaben gegen 0 fällt, verläuft IOPS (VolumeReadOps, VolumeWriteOps) flach auf Höhe der Basisleistung, VolumeQueueLength und Lag steigen gemeinsam. Beginnt erst, nachdem die Spitzenlast einige Stunden angehalten hat - Spricht dagegen: Alle Guthaben ausreichend, IOPS trotzdem flach: festes Limit von Volume oder Instanz (dk-iops) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch bei intaktem Datenträger zeigt sich bei kleinen virtuellen Servern dasselbe Muster, weil die Disk-Bandbreite der Instanz selbst ein Burst-Limit hat (etwa mindestens 30 Minuten pro Tag). Günstige Server mit CPU-Credits werden ebenfalls auf ihre Basisleistung gebremst, sobald die Credits aufgebraucht sind. - Quellen: - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Basisleistung von gp2: 3 IOPS pro GiB (mindestens 100), Burst bis 3.000 IOPS über I/O-Credits, 5,4 Millionen Credits reichen für mindestens 30 Minuten. gp3 liefert ohne Burst immer 3.000 IOPS - [Managed disk bursting](https://learn.microsoft.com/en-us/azure/virtual-machines/disk-bursting) · Microsoft Azure · Premium SSD bis P20 mit Credit-basiertem Burst, mit vollem Guthaben 30 Minuten bei maximaler Burst-Geschwindigkeit - [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) · AWS · Einige Instanzen halten die maximale EBS-Leistung nur 30 Minuten einmal alle 24 Stunden und fallen danach auf die Basisleistung zurück - [Standard mode for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) · AWS · Burstfähige Instanzen im Standardmodus senken die CPU-Auslastung bei aufgebrauchten CPU-Credits auf das Basisniveau (allmählich, ohne abrupten Abfall) - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · BurstBalance: verbleibende I/O-Credits bei gp2 bzw. Durchsatz-Credits bei st1 und sc1 (%), VolumeReadOps, VolumeWriteOps, VolumeQueueLength - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · EBSIOBalance% und EBSByteBalance%: verbleibende EBS-Credits einiger Instanzen, die einmal alle 24 Stunden 30 Minuten lang im Burst laufen, CPUCreditBalance: verbleibende CPU-Credits burstfähiger Instanzen - [Disk metrics](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-metrics) · Microsoft Azure · Nutzung der Burst-Credits von Datenträgern und VMs (5-Minuten-Intervall), z. B. Data Disk Used Burst IO Credits Percentage #### dk-iops · IOPS-Limit und volle Warteschlange · IOPS limit / queue saturation Kommen mehr Anfragen, als der Datenträger pro Sekunde bewältigt, wird die Warteschlange lang und die Latenz explodiert. - Warum → Folge → Auf dem Bildschirm: Lese- und Schreibanfragen nähern sich der Kapazität des Datenträgers → Warteschlange wird länger (explodiert meist ab 90 % Auslastung) → Verzögertes Speichern und Laden, bei synchronen Aufrufen Freeze - Symptome: Input-Lag, Freeze / Faktoren: Latenz, Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang, Abendliche Stoßzeit - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Anfragen zusammenfassen, häufig gelesene Daten cachen, Zugriffe asynchron gestalten, damit der Game-Thread nicht auf den Datenträger wartet. - Aufgaben Infrastrukturteam: Server/OS: schnellere Datenträger einsetzen, Limits für Disk-Bandbreite und IOPS je Instanztyp prüfen, Alarme auf Disk-Auslastung und Warteschlange einrichten, große Dateikopien in ruhige Zeiten legen. DB-Systeme: auch für DB-Datenträger Alarme auf IOPS- und Durchsatzauslastung einrichten, Disk-Limits der DB-Instanzgröße prüfen. - Größenordnungen: HDD etwa 150 IOPS, SATA-SSD Zehntausende, NVMe Hunderttausende. Der Standard-Cloud-Datenträger (AWS gp3) liefert 3.000 IOPS und 125 MiB pro Sekunde. Daneben gibt es ein eigenes Durchsatzlimit pro Sekunde. Schöpft eine große Dateikopie es aus, stauen sich selbst kleine Schreibvorgänge. - Im Graphen: Plateau am Limit (IOPS, Länge der Disk-Warteschlange) - Wo nachsehen: r/s und w/s, rkB/s und wkB/s, aqu-sz sowie r_await und w_await aus iostat -x 1 prüfen. In der Cloud VolumeReadOps, VolumeWriteOps und VolumeQueueLength von EBS sowie die Limit-Prüfungen VolumeIOPSExceededCheck und VolumeThroughputExceededCheck, auf Instanzseite InstanceEBSIOPSExceededCheck und InstanceEBSThroughputExceededCheck prüfen - Spricht dafür: Anfragen pro Sekunde oder Durchsatz verlaufen flach auf dem Limitwert, aqu-sz und await schießen gemeinsam hoch. In der Cloud steht die Exceeded-Metrik auf 1 - Spricht dagegen: %util bei 100 %, await aber niedrig: möglicherweise noch Reserven. Bei SSDs und RAID mit paralleler Verarbeitung zeigt %util nicht das Limit an. Limit nicht erreicht, nur await hoch: Latenz des Datenträgers selbst (dk-hdd) oder fsync (dk-fsync) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: In der Cloud hat zusätzlich zum Limit des Datenträgers jede Servergröße (Instanztyp) eigene Limits für Disk-Bandbreite und IOPS. Selbst mit einem teuren Datenträger stößt ein kleiner Server an das Limit der Instanz. - Quellen: - [Exos X18 Data Sheet](https://www.seagate.com/www-content/datasheets/pdfs/exos-x18-mango-DS2045-1N-2007US-en_US.pdf) · Seagate · 4K-Random-Reads auf einer Server-HDD mit 7.200 U/min: 170 IOPS (QD16) - [D3-S4520 SSD](https://www.solidigm.com/products/data-center/d3/s4520.html) · Solidigm · Server-SATA-SSD, 4-KB-Random-Read/-Write bis 92K/48K IOPS - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · Server-NVMe-SSD, Random-Read/-Write 1.000K/200K IOPS - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Basisleistung von gp3: 3.000 IOPS und 125 MiB/s, zwei getrennte Limits, die sich unabhängig voneinander erhöhen lassen - [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) · AWS · Jeder Instanztyp hat eigene Basis- und Höchstlimits für EBS-Bandbreite, Durchsatz und IOPS - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: r/s und w/s, rkB/s und wkB/s, aqu-sz (früher avgqu-sz), r_await und w_await, %util. Bei RAID und modernen SSDs mit paralleler Verarbeitung zeigt %util nicht das Leistungslimit an - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · VolumeIOPSExceededCheck und VolumeThroughputExceededCheck: 1, wenn das Volume versucht hat, sein IOPS- oder Durchsatzlimit zu überschreiten (Nitro-Instanzen), VolumeQueueLength - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · InstanceEBSIOPSExceededCheck und InstanceEBSThroughputExceededCheck: 1, wenn die Instanz versucht hat, ihr EBS-IOPS- oder -Durchsatzlimit zu überschreiten #### dk-full · Datenträger voll · Disk full Füllen angesammelte Logs und Dumps den Datenträger, schlagen Schreibvorgänge fehl. Ohne Vorkehrungen stürzt der Server ab. - Warum → Folge → Auf dem Bildschirm: Logs, Dumps und temporäre Dateien sammeln sich bis 100 % → Schreibvorgänge schlagen fehl. Ohne Fehlerbehandlung Absturz, mit Fehlerbehandlung fehlgeschlagenes Speichern → Verbindungsabbruch, Spielfortschritt wird zurückgesetzt (Rollback) - Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Je länger es läuft - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Schreibfehler abfangen und mit erneutem Speicherversuch und Alarm reagieren (kein Absturz), unnötige Logs und Dumps reduzieren. - Aufgaben Infrastrukturteam: Server/OS: Log-Rotation einrichten, Alarm auf den Füllstand setzen, Logs und Daten auf getrennte Datenträger legen. DB-Systeme: überwachen, ob sich DB-Transaktionslogs (WAL, binlog) wegen gestoppter Replikation oder fehlender Log-Backups ansammeln. - Im Graphen: Langsamer Anstieg (Disk-Belegung) - Wo nachsehen: Belegung mit df -h und Inode-Belegung mit df -i prüfen, in Server- und DB-Logs nach ENOSPC-Fehlern suchen. Bei der DB: in PostgreSQL Slots in pg_replication_slots mit active = false, in MySQL Anzahl und Größe der Dateien aus SHOW BINARY LOGS, in SQL Server log_reuse_wait_desc in sys.databases, bei RDS FreeStorageSpace prüfen - Spricht dafür: Belegung steigt über mehrere Tage stetig an, der Zeitpunkt, an dem sie 100 % erreicht, fällt mit Absturz oder fehlgeschlagenem Speichern zusammen, im Log steht ENOSPC - Spricht dagegen: Genug Platz frei, Schreibvorgänge schlagen trotzdem fehl: andere Ursache wie Berechtigungen oder Dateigrößenlimit - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Die Transaktionslogs der DB (WAL, binlog usw.) werden nicht gelöscht und wachsen weiter, wenn ein Replikat stehen bleibt oder Log-Backups ausbleiben. Ist dieser Datenträger voll, stoppen alle Schreibvorgänge der DB, und Speichern und Handel schlagen gleichzeitig fehl. - Quellen: - [write(2) — Linux manual page](https://man7.org/linux/man-pages/man2/write.2.html) · Linux man-pages · Ist auf dem Gerät kein Platz mehr, schlägt das Schreiben mit dem Fehler ENOSPC fehl - [Monitoring Disk Usage (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/diskusage.html) · PostgreSQL · Ist der Datenträger mit dem WAL voll, kann der DB-Server mit einer Panic herunterfahren - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Ein Replikationsslot gibt WAL erst frei, wenn das Replikat es empfangen hat, und kann so den Platz von pg_wal füllen (begrenzbar mit max_slot_wal_keep_size) - [Troubleshoot a full transaction log (SQL Server Error 9002)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002) · Microsoft SQL Server · Bei vollem Log ist die DB nur noch lesbar und nicht mehr änderbar; häufige Gründe für eine blockierte Log-Bereinigung sind fehlende Log-Backups, Replikationsverzögerung und lange Transaktionen; was blockiert, zeigt log_reuse_wait_desc in sys.databases - [df(1) — Linux manual page](https://man7.org/linux/man-pages/man1/df.1.html) · coreutils · Belegung je Dateisystem, -i zeigt die Inode-Belegung anstelle der Blockbelegung - [pg_replication_slots (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/view-pg-replication-slots.html) · PostgreSQL · active: ob der Slot gerade streamt, wal_status: ob das vom Slot festgehaltene WAL max_wal_size überschreitet - [SHOW BINARY LOGS Statement](https://dev.mysql.com/doc/refman/8.4/en/show-binary-logs.html) · MySQL · Liste der Binärlog-Dateien des Servers mit Dateigröße (File_size) - [Amazon CloudWatch metrics for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html) · AWS · FreeStorageSpace: verbleibender Speicherplatz der DB-Instanz #### dk-backup · Backup-, Komprimierungs- und Scan-Jobs · Backup / compression / scans Belegen nächtliche Backups, Log-Komprimierung oder Sicherheitsscans den Datenträger, stauen sich die Lese- und Schreibzugriffe des Spielservers. - Warum → Folge → Auf dem Bildschirm: Geplanter Backup- oder Komprimierungsjob startet → Belegt den Großteil von Disk-Bandbreite und IOPS → Lag jeden Tag zur selben Uhrzeit - Symptome: Ruckeln, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Ganzer Server / Wann: In festen Abständen - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Server/OS: Backup-, Komprimierungs- und Scan-Jobs mit niedrigerer I/O-Priorität ausführen, Startzeiten verteilen. DB-Systeme: Backups auf einem Replikat erstellen. - Im Graphen: Spitzen in festen Abständen (Disk-Auslastung, Disk-Wartezeit) - Wo nachsehen: Mit sar -d %util, await und aqu-sz der letzten Tage (Tagesdateien unter /var/log/sa; sadc muss mit -S DISK auch die Disk-Daten sammeln) tageweise übereinanderlegen, zu diesen Uhrzeiten mit pidstat -d 1 die Prozesse mit den höchsten kB_rd/s und kB_wr/s suchen und mit den Zeitplänen von Cron und systemd-Timern abgleichen - Spricht dafür: Jeden Tag zur selben Uhrzeit schießen await und %util hoch, und Backup-, Komprimierungs- oder Scan-Prozesse verursachen dann den Großteil der Lese- und Schreibzugriffe - Spricht dagegen: Spitzen jeden Tag zu anderen Uhrzeiten: geplanter Job unwahrscheinlich. I/O zu diesem Zeitpunkt größtenteils vom Spielserver selbst: eher Speichern oder Logging (dk-fsync, dk-sync-log) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [ionice(1) — Linux manual page](https://man7.org/linux/man-pages/man1/ionice.1.html) · util-linux · Ein Job in der Klasse idle bekommt nur dann Zeit auf dem Datenträger, wenn kein anderes Programm ihn nutzt - [Using Replication for Backups](https://dev.mysql.com/doc/refman/8.4/en/replication-solutions-backups.html) · MySQL · Ein Backup von einem angehaltenen Replikat beeinträchtigt den Betrieb der Primär-DB nicht - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · -d: await, aqu-sz und %util je Gerät aus den Tagesdateien (Standard /var/log/sa), die Disk-Daten müssen mit der sadc-Option -S DISK gesammelt werden - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -d: kB_rd/s und kB_wr/s je Prozess (pro Sekunde vom Datenträger gelesene bzw. auf ihn geschriebene Datenmenge) #### dk-lazy-load · Lazy Loading auf dem Server · Lazy loading on the server Liest der Server Dungeon- oder Kartendaten erst bei der ersten Anfrage vom Datenträger, stehen alle still, bis dieser Tick fertig ist. - Warum → Folge → Auf dem Bildschirm: Jemand betritt als Erster einen Dungeon oder ein Gebiet → Der Server liest die Daten im Game-Thread vom Datenträger → Alle auf diesem Server stehen kurz still - Symptome: Freeze / Faktoren: Stillstand - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Daten beim Serverstart vorladen, asynchron laden. - Aufgaben Infrastrukturteam: Bei Servern, die gerade aus einem Snapshot erstellt wurden, den Datenträger vor der Inbetriebnahme vorwärmen (alle Blöcke einmal lesen) oder Fast Snapshot Restore nutzen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Server-Tick-Zeit, Disk-Lesezugriffe) - Wo nachsehen: Zeitpunkte des Stillstands mit den Einträgen zum ersten Betreten von Dungeons oder Gebieten im Spielserver-Log abgleichen, für diesen Moment die Disk-Lesezugriffe des Spielservers (kB_rd/s aus pidstat -d) und mit perf trace --duration langsame read- und open-Aufrufe prüfen. Bei neu gestarteten Cloud-Servern VolumeAvgReadLatency von EBS mit älteren Servern vergleichen - Spricht dafür: Stillstand nur beim ersten Betreten, beim zweiten Betreten desselben Orts nicht. Während des Stillstands wartet der Game-Thread auf das Lesen einer Datei - Spricht dagegen: Gleicher Stillstand auch in bereits geladenen Gebieten: andere Ursache wie überschrittenes Tick-Budget oder GC - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: In der Cloud holt ein Server, der gerade aus einem Snapshot (Kopie eines Datenträgers) erstellt wurde, jeden Block beim ersten Lesen aus einem entfernten Storage und ist dadurch deutlich langsamer als sonst. Dauert der erste Eintritt nur auf Servern, die per Autoscaling neu gestartet wurden, auffällig lange, liegt dieser Verdacht nahe. - Quellen: - [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html) · AWS · Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, solange Blöcke aus S3 geholt werden; vorab mit dd oder fio alle Blöcke lesen und so initialisieren - [Amazon EBS fast snapshot restore](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html) · AWS · Fast Snapshot Restore liefert Volumes, die schon beim Erstellen initialisiert sind, und beseitigt so die Latenz beim ersten Zugriff - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -d: kB_rd/s je Prozess (pro Sekunde vom Datenträger gelesene Datenmenge) - [perf-trace(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-trace.1.html) · perf · --duration zeigt nur Systemaufrufe, die länger als die angegebenen ms dauerten - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · VolumeAvgReadLatency: Leselatenz im 1-Minuten-Mittel (Nitro-Instanzen) #### dk-coredump · Schreiben von Core-Dumps · Core dump writing Stürzt der Server ab, schreibt er mehrere GB Arbeitsspeicher auf den Datenträger. Das kann den Neustart um einige Minuten verzögern. - Warum → Folge → Auf dem Bildschirm: Serverabsturz, der gesamte Arbeitsspeicher wird in eine Datei geschrieben → Kein Neustart möglich, solange mehrere GB geschrieben werden → Server abgestürzt, nach dem Verbindungsabbruch lange kein Login möglich - Symptome: Kein Login / Endlos-Laden / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Einsatz kleiner Dumps prüfen, die nur den nötigen Speicher enthalten (Minidumps), Absturzursache beheben. - Aufgaben Infrastrukturteam: Dump-Größe begrenzen (Core-Dump-Einstellungen des OS), schnelle Datenträger einsetzen, Neustart und Dump entkoppeln (Komprimieren und Hochladen des Dumps erst nach dem Neustart separat erledigen). - Im Graphen: Verbindungen brechen gleichzeitig ab (Anzahl der Verbindungen, Zeitpunkt des Serverneustarts) - Wo nachsehen: Absturzzeitpunkt, Größe der Core-Datei (coredumpctl list und info oder die Datei an dem Ort, auf den core_pattern zeigt), Zeitpunkt, an dem die Datei fertig geschrieben war, und Zeitpunkt, an dem der Dienst wieder lief, nebeneinanderlegen und für diesen Zeitraum wkB/s aus iostat -x prüfen - Spricht dafür: Nach dem Absturz liegen die Disk-Schreibvorgänge nahe am Limit, solange eine Core-Datei von mehreren GB geschrieben wird, und der Neustart beginnt erst, wenn das Schreiben beendet ist - Spricht dagegen: Core-Dumps abgeschaltet oder klein und schnell fertig, Neustart trotzdem langsam: eher der Serverstart selbst, etwa Laden der Karten oder kalter DB-Cache (db-cold-cache) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [core(5) — Linux manual page](https://man7.org/linux/man-pages/man5/core.5.html) · Linux man-pages · Obergrenze der Core-Dateigröße per RLIMIT_CORE, Auswahl der enthaltenen Speicherbereiche per coredump_filter, Core-Dumps per Pipe an ein Programm übergeben und separat verarbeiten - [Minidump Files](https://learn.microsoft.com/en-us/windows/win32/debug/minidump-files) · Microsoft · Ein Minidump enthält nur den nützlichen Teil der Crash-Dump-Informationen und ist dadurch schnell erstellt und klein - [coredumpctl(1) — Linux manual page](https://man7.org/linux/man-pages/man1/coredumpctl.1.html) · systemd · list: im Journal erfasste Core-Dumps (TIME ist der vom Kernel gemeldete Absturzzeitpunkt), info: Details je Dump und die auf den Datenträger geschriebene Größe - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: wkB/s (pro Sekunde auf den Datenträger geschriebene Datenmenge) #### dk-hdd · Seek-Latenz von HDDs · HDD seek latency Bei einer HDD muss sich der Schreib-/Lesekopf über die Magnetscheibe bewegen (Seek). Verstreute Daten zu lesen oder zu schreiben dauert deshalb pro Zugriff fast 10 ms. - Warum → Folge → Auf dem Bildschirm: HDDs in alten Servern oder günstigem Storage → Etwa 10 ms pro verstreutem Lese- oder Schreibzugriff → Speichern und Laden insgesamt verzögert - Symptome: Input-Lag / Faktoren: Latenz - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Design auf überwiegend sequenzielles Schreiben auslegen. - Aufgaben Infrastrukturteam: Server/OS: auf SSDs umstellen (zuerst die Datenträger mit vielen verstreuten Lese- und Schreibzugriffen). DB-Systeme: die DB-Datenträger mit den meisten verstreuten Lese- und Schreibzugriffen zuerst durch SSDs ersetzen. - Im Graphen: Von Anfang an dauerhaft hoch (Disk-Lese- und Schreiblatenz (r_await, w_await)) - Wo nachsehen: Mit lsblk -d -o NAME,ROTA prüfen, ob es eine rotierende Festplatte (HDD) ist, und r/s, w/s sowie r_await, w_await aus iostat -x 1 prüfen. Bei virtuellen Servern die Art des Datenträgers in der Spezifikation von Cloud oder Storage nachsehen - Spricht dafür: Rotierende Festplatte, und obwohl nur einige Dutzend bis rund hundert Anfragen pro Sekunde anfallen, liegen r_await und w_await dauerhaft im ein- bis zweistelligen Millisekundenbereich - Spricht dagegen: SSD, Latenz trotzdem hoch: eher volle Warteschlange (dk-iops) oder aufgebrauchte Burst-Credits (dk-burst) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Ein Seek auf der Disk 10 ms, 1 MB sequenziell von der Disk lesen 20 ms - [Exos X18 Data Sheet](https://www.seagate.com/www-content/datasheets/pdfs/exos-x18-mango-DS2045-1N-2007US-en_US.pdf) · Seagate · HDD mit 7.200 U/min: mittlere Rotationslatenz 4,16 ms, 4K-Random-Reads 170 IOPS - [lsblk(8) — Linux manual page](https://man7.org/linux/man-pages/man8/lsblk.8.html) · util-linux · -o wählt die Ausgabespalten, zu den Spalten der Gerätetopologie gehört ROTA (rotierend oder nicht) - [ABI stable symbols](https://docs.kernel.org/admin-guide/abi-stable.html) · Linux kernel · /sys/block/(Datenträger)/queue/rotational: zeigt, ob das Gerät rotierend oder nicht rotierend ist - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: r/s und w/s, r_await und w_await (durchschnittliche Bearbeitungszeit pro Anfrage einschließlich Wartezeit in der Warteschlange) ### L12 Datenbank (16 Ursachen) #### db-no-index · Query ohne Index · Missing index / full table scan Ohne Index muss die DB die ganze Tabelle lesen, um die passenden Zeilen zu finden (Full Table Scan). - Warum → Folge → Auf dem Bildschirm: Ein neues Feature bringt eine Suche nach einer nicht indizierten Bedingung mit → Millionen Zeilen werden komplett gescannt, eine einzige Query dauert mehrere hundert ms bis einige Sekunden → Postfach und Handelsverlauf laden langsam, belegte Verbindungen lassen auch andere Anfragen warten - Symptome: Input-Lag, Kein Login / Endlos-Laden / Faktoren: Latenz, Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Ausführungsplan neuer Queries vor dem Deployment prüfen, Indizes ergänzen, auch bei ändernden Queries (UPDATE, DELETE) prüfen, ob sie einen Index nutzen. - Aufgaben Infrastrukturteam: Slow-Query-Log überwachen, Queries mit Full Table Scan ermitteln und an das Entwicklungsteam weitergeben, Indizes im laufenden Betrieb online mit kurzen Locks anlegen. - Größenordnungen: Mit Index einige ms. Ohne Index wächst die Dauer mit der Datenmenge, bei großen Tabellen auf das Hundert- bis Zehntausendfache. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (DB-Query-Latenz, gelesene Zeilen) - Wo nachsehen: MySQL: Rows_examined und Rows_sent im slow query log (mit log_queries_not_using_indexes werden auch Queries ohne Index protokolliert) sowie SUM_NO_INDEX_USED und SUM_ROWS_EXAMINED in performance_schema events_statements_summary_by_digest prüfen, EXPLAIN ausführen. PostgreSQL: seq_scan und seq_tup_read in pg_stat_user_tables prüfen, EXPLAIN ausführen - Spricht dafür: Eine nach dem Deployment neu aufgetauchte Query liest mehrere tausend Mal so viele Zeilen (Rows_examined), wie sie zurückgibt (Rows_sent), EXPLAIN zeigt einen Full Table Scan (MySQL type ALL, PostgreSQL Seq Scan). seq_tup_read großer Tabellen steigt ab dem Deployment steil an - Spricht dagegen: Index wird genutzt, trotzdem langsam: Warten auf Locks (db-hot-row, db-ddl-lock) oder geänderter Ausführungsplan (db-plan-flip). Ein Full Table Scan auf kleinen Tabellen kann normal sein - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch Schreibvorgänge leiden darunter. Ändernde Queries ohne Index (UPDATE, DELETE) sperren je nach DB auch alle gescannten Zeilen und können so das Speichern völlig unbeteiligter Spieler blockieren. - Quellen: - [How MySQL Uses Indexes](https://dev.mysql.com/doc/refman/8.4/en/mysql-indexes.html) · MySQL · Ohne Index liest die DB die ganze Tabelle ab der ersten Zeile, je größer die Tabelle, desto teurer - [Locks Set by Different SQL Statements in InnoDB](https://dev.mysql.com/doc/refman/8.4/en/innodb-locks-set.html) · MySQL · Fehlt ein passender Index und wird die ganze Tabelle gescannt, werden alle Zeilen gesperrt, und selbst Einfügungen anderer Benutzer werden blockiert - [The Slow Query Log](https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html) · MySQL · Protokolliert Queries, die long_query_time (Standard 10 s) überschreiten; Queries ohne Index lassen sich zusätzlich protokollieren - [CREATE INDEX (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/sql-createindex.html) · PostgreSQL · Mit CONCURRENTLY entsteht der Index, ohne Schreibvorgänge zu blockieren; die normale Erstellung blockiert Schreibvorgänge bis zum Ende - [Statement Summary Tables](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html) · MySQL · events_statements_summary_by_digest: SUM_NO_INDEX_USED (Anzahl der Ausführungen ohne Index) und SUM_ROWS_EXAMINED je Gruppe gleich aufgebauter Queries - [EXPLAIN Output Format](https://dev.mysql.com/doc/refman/8.4/en/explain-output.html) · MySQL · type ALL bedeutet Full Table Scan, meist durch einen zusätzlichen Index vermeidbar - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · seq_scan (Anzahl sequenzieller Scans) und seq_tup_read (per sequenziellem Scan gelesene Zeilen) in pg_stat_user_tables - [Using EXPLAIN (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/using-explain.html) · PostgreSQL · Seq Scan: Ausführungsplan, der alle Zeilen der Tabelle nacheinander liest #### db-hot-row · Hot-Row-Lock-Contention · Hot row lock contention Wollen alle dieselbe Zeile ändern (Gildenlager, begehrtes Item im Auktionshaus, serverweiter Zähler), bekommt immer nur einer den Lock. - Warum → Folge → Auf dem Bildschirm: Durch ein Event oder ein begehrtes Item häufen sich Änderungen an derselben Zeile → Anfragen warten, bis sie den Lock bekommen → Handel schlägt fehl, „Bitte später erneut versuchen“, Timeouts - Symptome: Verschluckte Aktion / Rollback, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Nur eine bestimmte Funktion / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Zeile aufteilen (Sharded Counter), Transaktionen kurz halten, Änderungen im Speicher sammeln und gebündelt schreiben. - Aufgaben Infrastrukturteam: Wartezeit und Anzahl der Wartevorgänge auf Zeilensperren überwachen, Zeilen mit gehäufter Contention ermitteln und weitergeben. - Größenordnungen: Hält eine Anfrage den Lock 10 ms lang, lässt sich die Zeile höchstens 100-mal pro Sekunde ändern. Enthält die Transaktion zusätzlich einen Round Trip zu einem anderen Server, sinkt dieser Wert entsprechend weiter. - Im Graphen: Steigt mit Spielerzahl und Last (Wartevorgänge auf Zeilensperren (Anzahl, Dauer)) - Wo nachsehen: MySQL: Zuwachs von Innodb_row_lock_waits und Innodb_row_lock_time sowie Innodb_row_lock_current_waits prüfen, mit sys.innodb_lock_waits ermitteln, wer auf wen wartet. PostgreSQL: Sessions mit wait_event_type Lock in pg_stat_activity und Anfragen mit granted = false in pg_locks prüfen; mit log_lock_waits (standardmäßig aus) landen lange Lock-Wartezeiten im Log - Spricht dafür: Lock-Wartevorgänge steigen mit Event und Spielerzahl steil an, die meisten wartenden Anfragen zielen auf dieselbe Zeile (denselben Schlüssel) derselben Tabelle - Spricht dagegen: Wartevorgänge gleichmäßig auf viele Tabellen und Zeilen verteilt: eher ausgelasteter Datenträger oder ausgelastete CPU. Eine Session hält einen Lock lange und gibt ihn nicht frei: lange offene Transaktion (db-long-tx) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [InnoDB Locking](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html) · MySQL · Sperrt eine Transaktion eine Zeile (einen Indexeintrag), kann keine andere Transaktion diese Zeile ändern und muss warten - [How to Minimize and Handle Deadlocks](https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html) · MySQL · Empfehlung, Transaktionen klein und kurz zu halten und direkt nach zusammengehörigen Änderungen zu committen, um Konflikte zu verringern - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Innodb_row_lock_waits und Innodb_row_lock_time liefern Anzahl und Dauer der Wartevorgänge auf Zeilensperren, Innodb_row_lock_current_waits die Zahl der aktuell Wartenden - [The innodb_lock_waits and x$innodb_lock_waits Views](https://dev.mysql.com/doc/refman/8.4/en/sys-innodb-lock-waits.html) · MySQL · Wartende Query (waiting_query), blockierende Session (blocking_pid), Wartezeit (wait_age) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · wait_event_type in pg_stat_activity: Lock bedeutet, dass auf einen Heavyweight-Lock gewartet wird - [pg_locks (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/view-pg-locks.html) · PostgreSQL · granted = false: Der Prozess wartet darauf, den Lock zu bekommen - [Error Reporting and Logging (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-logging.html) · PostgreSQL · log_lock_waits: schreibt einen Logeintrag, wenn länger als deadlock_timeout auf einen Lock gewartet wird, standardmäßig aus #### db-deadlock · DB-Deadlock · Database deadlock Warten zwei Transaktionen (DB-Operationen, die als ein Paket verarbeitet werden) jeweils auf eine Zeile, die die andere gesperrt hat, bricht die DB eine davon zwangsweise ab. - Warum → Folge → Auf dem Bildschirm: Handel A sperrt in der Reihenfolge Item → Währung, Handel B in der Reihenfolge Währung → Item → Die DB erkennt den Deadlock und rollt eine der beiden Transaktionen zurück → Handel und Crafting schlagen gelegentlich fehl, Items werden zurückgebucht - Symptome: Verschluckte Aktion / Rollback, Input-Lag / Faktoren: Paketverlust, Stillstand - Wer: Nur eine bestimmte Funktion / Wann: Bei großem Andrang, Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Einheitliche Lock-Reihenfolge festlegen, Transaktionen kurz halten, bei Fehlschlag automatisch wiederholen. - Aufgaben Infrastrukturteam: Deadlock-Erkennung eingeschaltet lassen, Deadlock-Protokolle sammeln und weitergeben, auf MySQL-Servern mit abgeschalteter Erkennung das Lock-Wait-Timeout (Standard 50 s) verkürzen. - Größenordnungen: Bis zur Erkennung vergeht bei MySQL (InnoDB) kaum Zeit, bei PostgreSQL standardmäßig 1 s, bei SQL Server bis zu etwa 5 s. So lange stehen beide Anfragen still. Hat ein MySQL-Server die Erkennung wegen sehr vieler gleichzeitiger Anfragen abgeschaltet, wird bis zum Lock-Wait-Timeout gewartet (Standard 50 s). - Im Graphen: Vereinzelte Spitzen ohne Muster (Anzahl der Deadlocks, fehlgeschlagene Handelsvorgänge) - Wo nachsehen: MySQL: LATEST DETECTED DEADLOCK in SHOW ENGINE INNODB STATUS (nur der jüngste Fall), bei aktiviertem innodb_print_all_deadlocks alle Deadlocks im Error-Log sowie lock_deadlocks in INFORMATION_SCHEMA.INNODB_METRICS prüfen. PostgreSQL: deadlocks in pg_stat_database prüfen, SQL Server: xml_deadlock_report der standardmäßig aktiven Session system_health prüfen. Fehlercodes auf Seite des Spielservers: MySQL 1213, PostgreSQL 40P01, SQL Server 1205 - Spricht dafür: Zu den Zeitpunkten fehlgeschlagener Handels- oder Crafting-Vorgänge steigt die Zahl der Deadlocks, und die beiden protokollierten Transaktionen sperren dieselben Tabellen in umgekehrter Reihenfolge - Spricht dagegen: Deadlock-Zahl unverändert, trotzdem Fehlschläge: Lock-Wait-Timeout überschritten (MySQL-Fehler 1205) oder Hot Row (db-hot-row) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [InnoDB Startup Options and System Variables](https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.html) · MySQL · Bei aktivierter Erkennung (Standard) erkennt InnoDB Deadlocks sofort und führt ein Rollback aus, innodb_lock_wait_timeout Standard 50 s - [Deadlock Detection](https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlock-detection.html) · MySQL · Bei sehr hoher Parallelität kann die Erkennung selbst bremsen; dann wird sie mitunter abgeschaltet und das Lock-Wait-Timeout übernimmt - [Lock Management (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-locks.html) · PostgreSQL · deadlock_timeout Standard 1 s: Erst nach dieser Wartezeit auf einen Lock wird auf Deadlocks geprüft - [Deadlocks guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-deadlocks-guide) · Microsoft SQL Server · Standardintervall der Deadlock-Prüfung 5 s, bei häufigen Deadlocks sinkt es bis auf 100 ms; die standardmäßig aktive Session system_health erfasst xml_deadlock_report; die als Opfer gewählte Seite erhält Fehler 1205 - [How to Minimize and Handle Deadlocks](https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html) · MySQL · Mehrere Zeilen und Tabellen immer in derselben Reihenfolge ändern, bei Fehlschlag wiederholen, mit innodb_print_all_deadlocks alle Deadlocks protokollieren - [InnoDB Standard Monitor and Lock Monitor Output](https://dev.mysql.com/doc/refman/8.4/en/innodb-standard-monitor.html) · MySQL · LATEST DETECTED DEADLOCK: die beiden Transaktionen des jüngsten Deadlocks, gehaltene und erwartete Locks, zurückgerollte Seite - [InnoDB INFORMATION_SCHEMA Metrics Table](https://dev.mysql.com/doc/refman/8.4/en/innodb-information-schema-metrics-table.html) · MySQL · Zähler lock_deadlocks in INNODB_METRICS (standardmäßig aktiv) - [Server Error Message Reference](https://dev.mysql.com/doc/mysql-errors/8.4/en/server-error-reference.html) · MySQL · 1213 ER_LOCK_DEADLOCK (Deadlock), 1205 ER_LOCK_WAIT_TIMEOUT (Lock-Wait-Timeout überschritten) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · deadlocks in pg_stat_database: Anzahl der in dieser DB erkannten Deadlocks - [PostgreSQL Error Codes (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/errcodes-appendix.html) · PostgreSQL · 40P01 deadlock_detected #### db-pool · Erschöpfter Connection-Pool · Connection pool exhaustion Die Zahl der Verbindungen zur DB ist fest. Belegen langsame Queries die Verbindungen, müssen alle anderen Anfragen warten. - Warum → Folge → Auf dem Bildschirm: Durch langsame Queries oder eine Flut von Anfragen sind alle Verbindungen belegt → Neue Anfragen warten, bis eine Verbindung frei wird → Endlos-Laden beim Login, verzögertes Speichern, Timeouts - Symptome: Kein Login / Endlos-Laden, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Ganzer Server, Nur eine bestimmte Funktion / Wann: Direkt nach Login oder Wartung, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Langsame Queries beseitigen, Pool-Größe und Warte-Timeout anpassen (Pool nicht pauschal vergrößern), getrennte Pools je Funktion einrichten. - Aufgaben Infrastrukturteam: Maximale Verbindungszahl der DB sowie CPU- und IOPS-Reserven prüfen, vor Skalierung oder Autoscaling prüfen, ob Serveranzahl × Pool-Größe innerhalb der maximalen Verbindungszahl bleibt, Metriken für Verbindungs- und Lock-Wartezeiten ins Monitoring aufnehmen. - Größenordnungen: Die nötige Zahl an Verbindungen lässt sich mit „Anfragen pro Sekunde × Zeit, die eine Anfrage eine Verbindung belegt“ abschätzen. Bei 2.000 Anfragen pro Sekunde und 5 ms pro Anfrage sind im Mittel ständig 10 Verbindungen beschäftigt. Für Lastspitzen plant man üblicherweise das Zwei- bis Dreifache ein. Wird die Query auf 150 ms langsamer, braucht dieselbe Last 300 Verbindungen. - Im Graphen: Plateau am Limit (Belegte DB-Verbindungen, Wartezeit auf Verbindungen) - Wo nachsehen: Auf DB-Seite den Verbindungsstatus je Spielserver zählen. MySQL: Host, Command (untätige Verbindungen: Sleep) und Time aus SHOW PROCESSLIST sowie Threads_connected, Threads_running und die Zahl abgewiesener Verbindungen Connection_errors_max_connections prüfen. PostgreSQL: pg_stat_activity nach client_addr und state gruppiert zählen. Liefert die Connection-Pool-Bibliothek des Spielservers Anzahl und Dauer der Wartevorgänge, diese ebenfalls prüfen - Spricht dafür: Alle Verbindungen eines Spielservers (so viele, wie der Pool groß ist) führen Queries aus, keine Verbindung ist frei, währenddessen warten Login und Speichern. Oder die Gesamtzahl der DB-Verbindungen erreicht max_connections, und neue Verbindungen werden abgewiesen - Spricht dagegen: Genug freie Verbindungen, trotzdem langsam: Latenz der Queries selbst (db-no-index, db-hot-row) oder ausgelastete DB-Ressourcen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Ein pauschal vergrößerter Pool erhöht nur die CPU-Last der DB und die Lock-Contention, und alle werden gemeinsam langsamer. Übersteigt außerdem Serveranzahl × Pool-Größe die maximale Verbindungszahl der DB, bekommen neu hinzugefügte oder neu gestartete Server nicht einmal eine Verbindung. Das passiert häufig direkt nach Autoscaling oder Wartung. - Quellen: - [Number Of Database Connections](https://wiki.postgresql.org/wiki/Number_Of_Database_Connections) · PostgreSQL · Sind die DB-Ressourcen ausgeschöpft, sinkt der Durchsatz durch weitere Verbindungen sogar; aktive Verbindungen an die Ressourcen anzupassen und den Rest in eine Warteschlange zu stellen, verbessert Latenz und Durchsatz - [Too many connections](https://dev.mysql.com/doc/refman/8.4/en/too-many-connections.html) · MySQL · Sind alle max_connections belegt, werden neue Verbindungen mit dem Fehler Too many connections abgewiesen - [Connections and Authentication (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-connection.html) · PostgreSQL · max_connections: Obergrenze gleichzeitiger Verbindungen, Standard meist 100 - [SHOW PROCESSLIST Statement](https://dev.mysql.com/doc/refman/8.4/en/show-processlist.html) · MySQL · Host (Client-Adresse), Command (untätige Sessions: Sleep), Time, State - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Threads_connected und Threads_running, Connection_errors_max_connections (wegen Erreichen von max_connections abgewiesene Verbindungen) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · pg_stat_activity: client_addr und state (active, idle, idle in transaction usw.) je Verbindung #### db-replica-lag · Replikationsverzögerung · Replication lag Geschrieben wird in die Primär-DB, gelesen aus dem Replikat. Hinkt das Replikat hinterher, ist gerade Geschriebenes dort noch nicht zu sehen. - Warum → Folge → Auf dem Bildschirm: Schreiblast häuft sich auf der Primär-DB, das Replikat liegt einige Sekunden zurück → Gerade Gespeichertes fehlt beim Lesen aus dem Replikat noch → Gerade gekauftes Item nicht sichtbar, veraltete Preise auf dem Marktplatz, Bugs durch doppelte Vergabe - Symptome: Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur eine bestimmte Funktion / Wann: Bei großem Andrang, Abendliche Stoßzeit - Hauptzuständig: DB-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Gerade geschriebene Daten aus der Primär-DB lesen, Prüfung und Vergabe in einer einzigen Transaktion auf der Primär-DB ausführen (Duplikate per Unique Key oder bedingtem UPDATE verhindern). - Aufgaben Infrastrukturteam: Alarm auf Replikationsverzögerung einrichten, Replikate mindestens so groß wie die Primär-DB dimensionieren und parallele Replikation einsetzen, Massenlöschungen in kleinen Portionen ausführen, lang laufende Aggregations-Queries auf Replikaten im Griff behalten. - Im Graphen: Steigt mit Spielerzahl und Last (Replikationsverzögerung (s)) - Wo nachsehen: MySQL: auf dem Replikat Seconds_Behind_Source aus SHOW REPLICA STATUS prüfen (vor Version 8.0.22 SHOW SLAVE STATUS). PostgreSQL: write_lag, flush_lag und replay_lag in pg_stat_replication auf dem Primärserver prüfen, bei RDS ReplicaLag - Spricht dafür: Zum Zeitpunkt der Meldung „nicht sichtbar“ liegt die Verzögerung bei mindestens einigen Sekunden, nach dem Aufholen ist alles wieder normal. Die Verzögerung wächst bei Schreibspitzen, Massenlöschungen oder langen Aggregations-Queries auf dem Replikat - Spricht dagegen: Verzögerung nahe 0, trotzdem nicht sichtbar: eher Cache oder Synchronisation im Spielserver - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch ohne viele Schreibvorgänge kann ein Replikat zurückfallen. Eine Massenlöschung, die auf der Primär-DB 10 Minuten dauerte, wird auf dem Replikat erneut ausgeführt und lässt es um ebenso viel zurückfallen. Lang laufende Aggregations-Queries auf dem Replikat bremsen das Aufholen ebenfalls. - Quellen: - [SHOW REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.4/en/show-replica-status.html) · MySQL · Seconds_Behind_Source: Abstand zu dem Zeitpunkt, zu dem das gerade vom Replikat angewendete Event auf der Primär-DB protokolliert wurde (Replikationsverzögerung) - [Replica Server Options and Variables](https://dev.mysql.com/doc/refman/8.4/en/replication-options-replica.html) · MySQL · Mit replica_parallel_workers wenden mehrere Threads Transaktionen parallel an (Standard 4, bei 0 ein einzelner Thread der Reihe nach) - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Streaming-Replikation ist standardmäßig asynchron, zwischen Commit und Übernahme ins Replikat liegt also eine Verzögerung (meist unter 1 s, wenn das Replikat mithalten kann) - [MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) · MySQL · Ab 8.0.22 lautet die Anweisung SHOW REPLICA STATUS (früher SHOW SLAVE STATUS), ältere Versionen kennen nur SHOW SLAVE STATUS - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · write_lag, flush_lag und replay_lag in pg_stat_replication: Zeit vom Schreiben des WAL auf dem Primärserver, bis das Replikat meldet, es geschrieben, auf den Datenträger übertragen bzw. angewendet zu haben - [Amazon CloudWatch metrics for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html) · AWS · ReplicaLag: Zeit, um die ein Lesereplikat hinter der Quelle zurückliegt (s) #### db-checkpoint · Checkpoint und Log-Flush · Checkpoint / log flush stalls Schreibt die DB in regelmäßigen Abständen die Änderungen aus dem Arbeitsspeicher gebündelt auf den Datenträger, werden Queries in diesem Moment langsam. - Warum → Folge → Auf dem Bildschirm: Aufgelaufene Änderungen werden regelmäßig auf den Datenträger geschrieben → Der Datenträger ist in diesem Moment ausgelastet, Queries verzögern sich → Speichern und Laden werden in festen Abständen langsam - Symptome: Input-Lag, Ruckeln / Faktoren: Latenz - Wer: Ganzer Server, Nur eine bestimmte Funktion / Wann: In festen Abständen - Hauptzuständig: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Checkpoints in kleine Schritte aufteilen und gleichmäßig verteilen, Transaktionslog (Redo-Log, WAL) großzügig bemessen, schnelle Datenträger einsetzen. - Im Graphen: Spitzen in festen Abständen (DB-Query-Latenz, Disk-Schreibvolumen) - Wo nachsehen: PostgreSQL: Checkpoint-Zeitpunkte und geschriebene Buffer im Log von log_checkpoints (in neueren Versionen standardmäßig an), Anzahl der Checkpoints (ab 17 num_timed und num_requested in pg_stat_checkpointer, bis 16 checkpoints_timed und checkpoints_req in pg_stat_bgwriter) und checkpoint_warning-Warnungen prüfen. MySQL: im Abschnitt LOG von SHOW ENGINE INNODB STATUS die Differenz zwischen Log sequence number und Last checkpoint at prüfen. Disk-Schreibvolumen und Schreiblatenz des Servers darüberlegen - Spricht dafür: Spitzen der Query-Latenz fallen mit Checkpoint-Zeitpunkten zusammen, gleichzeitig schießen Disk-Schreibvolumen und Schreiblatenz hoch. Gibt es in PostgreSQL deutlich mehr angeforderte Checkpoints (num_requested) als zeitgesteuerte (num_timed), erreicht WAL oft max_wal_size, und Checkpoints werden vorgezogen - Spricht dagegen: Spitzen in einem Rhythmus ohne Bezug zu den Checkpoint-Zeitpunkten: Backup oder Batch-Job (dk-backup, db-batch) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Ist das Transaktionslog, das die Änderungen aufnimmt (Redo-Log bei MySQL, WAL bei PostgreSQL), zu klein, muss die DB bei jedem vollen Log hastig einen Checkpoint durchziehen. Der Schreibdurchsatz bricht dann immer wieder kurz stark ein. - Quellen: - [WAL Configuration (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-configuration.html) · PostgreSQL · Checkpoint standardmäßig alle 5 Minuten oder alle 1 GB WAL (max_wal_size), teuer, weil alle Dirty Pages geschrieben werden. checkpoint_completion_target verteilt die Schreibvorgänge und vermeidet I/O-Spitzen. Ist der Checkpoint-Abstand kürzer als checkpoint_warning, steht im Log eine Warnung, max_wal_size zu erhöhen - [Configuring Buffer Pool Flushing](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-flushing.html) · MySQL · Ist das Redo-Log voll, sinkt der Durchsatz durch einen hastigen (sharp) Checkpoint kurzzeitig; adaptives Flushing verteilt die Schreibvorgänge gleichmäßig - [Error Reporting and Logging (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-logging.html) · PostgreSQL · log_checkpoints: protokolliert je Checkpoint die geschriebenen Buffer und die Dauer, standardmäßig an - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · num_timed (zeitgesteuerte Checkpoints) und num_requested (angeforderte Checkpoints) in pg_stat_checkpointer - [PostgreSQL 17 Release Notes](https://www.postgresql.org/docs/release/17.0/) · PostgreSQL · pg_stat_checkpointer neu eingeführt, Checkpoint-Spalten aus pg_stat_bgwriter dorthin verschoben - [The Cumulative Statistics System (PostgreSQL 16 Documentation)](https://www.postgresql.org/docs/16/monitoring-stats.html) · PostgreSQL · Bis 16 checkpoints_timed und checkpoints_req in pg_stat_bgwriter - [InnoDB Standard Monitor and Lock Monitor Output](https://dev.mysql.com/doc/refman/8.4/en/innodb-standard-monitor.html) · MySQL · Abschnitt LOG: aktuelle Log Sequence Number und Position des letzten Checkpoints #### db-cold-cache · Kalter Cache (direkt nach Neustart) · Cold buffer pool after restart Nach einem Neustart der DB ist der Cache im Arbeitsspeicher leer, und eine Zeit lang wird jede Abfrage vom Datenträger gelesen. - Warum → Folge → Auf dem Bildschirm: DB-Neustart wegen Wartung → Häufig genutzte Daten liegen nicht im Arbeitsspeicher und werden vom Datenträger gelesen → Direkt nach der Wartung sind Login und Laden eine Zeit lang langsam - Symptome: Kein Login / Endlos-Laden, Input-Lag / Faktoren: Latenz - Wer: Ganzer Server / Wann: Direkt nach Login oder Wartung - Hauptzuständig: DB-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Schrittweise öffnen (die Zahl der Logins über eine Login-Warteschlange stufenweise erhöhen). - Aufgaben Infrastrukturteam: Cache nach dem Neustart vorwärmen (Warm-up, Einstellungen zum Sichern und Wiederherstellen des Buffer Pools prüfen), bei aus Snapshots wiederhergestellten DBs auch den Datenträger vorab lesen. - Im Graphen: Ansturm direkt nach Login oder Wartung (Disk-Lesezugriffe, Trefferquote des Buffer-Caches) - Wo nachsehen: MySQL: Verhältnis von Innodb_buffer_pool_reads (Lesevorgänge vom Datenträger, weil die Daten nicht im Buffer Pool lagen) zu Innodb_buffer_pool_read_requests sowie den Fortschritt des Vorwärmens in Innodb_buffer_pool_load_status prüfen. PostgreSQL: blks_read und blks_hit in pg_stat_database prüfen. Auch die Disk-Lesezugriffe des DB-Servers prüfen - Spricht dafür: Direkt nach dem Neustart schießen die Disk-Lesezugriffe hoch und die Trefferquote ist niedrig, mit der Zeit erholt sie sich; in diesem Zeitraum sind Login und Laden langsam - Spricht dagegen: Trefferquote normal, direkt nach der Wartung trotzdem langsam: Login-Ansturm und N+1 (db-login-storm) oder Connection-Pool (db-pool) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: MySQL speichert beim Herunterfahren die Seitenliste des Buffer Pools und liest die Seiten beim Start im Hintergrund wieder ein. Bis der Pool wieder voll ist, dauert es aber. Wurde die DB in der Cloud aus einem Snapshot (Kopie eines Datenträgers) wiederhergestellt, ist auch der Datenträger selbst bei jedem erstmals gelesenen Block langsam, und es dauert noch länger. - Reale Fälle: roblox-2021 - Quellen: - [Saving and Restoring the Buffer Pool State](https://dev.mysql.com/doc/refman/8.4/en/innodb-preload-buffer-pool.html) · MySQL · Um das Vorwärmen nach dem Neustart zu verkürzen, wird beim Herunterfahren eine Liste der zuletzt genutzten Seiten (Standard 25 %) gespeichert und beim Start wieder eingelesen, beides standardmäßig aktiv - [pg_prewarm — preload relation data into buffer caches](https://www.postgresql.org/docs/current/pgprewarm.html) · PostgreSQL · Schreibt den Inhalt der Shared Buffers regelmäßig weg und lädt ihn nach dem Neustart wieder (autoprewarm) - [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html) · AWS · Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, bis alle Blöcke geholt sind - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Innodb_buffer_pool_reads (logische Lesevorgänge, die nicht aus dem Buffer Pool bedient werden konnten und direkt vom Datenträger lesen mussten), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status (Fortschritt des Vorwärmens) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · blks_read (vom Datenträger gelesene Blöcke) und blks_hit (im Buffer-Cache gefundene Blöcke) in pg_stat_database #### db-login-storm · Login-Ansturm und N+1-Queries · Login storm, N+1 queries Fragt das Laden eines einzigen Charakters die DB einige Dutzend Mal einzeln ab, werden aus Zehntausenden gleichzeitigen Logins Millionen von Queries. - Warum → Folge → Auf dem Bildschirm: Beim Laden des Charakters werden Items, Skills und Quests jeweils einzeln abgefragt → Gleichzeitige Logins direkt nach der Wartung lassen die Query-Zahl explodieren → Endlos-Laden beim Login, selbst das Speichern von Spielern im laufenden Spiel stockt - Symptome: Kein Login / Endlos-Laden, Input-Lag / Faktoren: Stillstand, Latenz - Wer: Ganzer Server / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Daten gebündelt abfragen, Login-Warteschlange einsetzen, cachen, die durch Lazy Loading im ORM erzeugte Zahl der Abfragen prüfen. - Aufgaben Infrastrukturteam: Rangliste der am häufigsten aufgerufenen Queries erstellen und weitergeben, Query- und Verbindungszahl im Login-Zeitraum direkt nach der Wartung überwachen. - Im Graphen: Ansturm direkt nach Login oder Wartung (DB-Queries pro Sekunde, Logins) - Wo nachsehen: Logins direkt nach der Wartung und DB-Queries pro Sekunde (bei MySQL Zuwachs von Questions) übereinanderlegen, Queries pro Login berechnen. Die am häufigsten aufgerufenen Queries über COUNT_STAR in MySQL events_statements_summary_by_digest bzw. calls in PostgreSQL pg_stat_statements ermitteln - Spricht dafür: Einige Dutzend Queries pro Login, die Top-Queries sind kurze, gleich aufgebaute Abfragen über eine einzelne Charakter-ID. Ist die Query-Zahl pro Login nach einem Patch gestiegen, ist dieser Patch der Ausgangspunkt - Spricht dagegen: Wenige Queries pro Login, aber jede einzelne langsam: kalter Cache (db-cold-cache) oder Index (db-no-index) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Lazy Loading im ORM (einer Bibliothek, die DB-Abfragen automatisch erzeugt) produziert solche Abfragen, ohne dass es den Entwicklern auffällt. Auf dem Entwicklungsserver mit wenigen Charakteren merkt man nichts davon. Sichtbar wird es erst bei gleichzeitigen Logins im Live-Betrieb. - Quellen: - [Efficient Querying](https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying) · .NET · Lazy Loading im ORM erzeugt das N+1-Problem, bei dem für jedes Element eine weitere Query gesendet wird, und verschlechtert die Performance stark; empfohlen wird gebündeltes Laden (Eager Loading) - [pg_stat_statements — track statistics of SQL planning and execution](https://www.postgresql.org/docs/current/pgstatstatements.html) · PostgreSQL · Sammelt Ausführungsanzahl (calls) und Gesamtlaufzeit je Anweisung und liefert so eine Rangliste der am häufigsten aufgerufenen Queries - [Performance Schema Statement Digests and Sampling](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-digests.html) · MySQL · events_statements_summary_by_digest fasst gleich aufgebaute Queries zusammen und aggregiert Anzahl und Zeit - [Statement Summary Tables](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html) · MySQL · COUNT_STAR (Anzahl der Ausführungen) und SUM_TIMER_WAIT (Gesamtzeit) in den Summary-Tabellen - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Questions: Anzahl der vom Client gesendeten Anweisungen #### db-batch · Große Batch-Jobs · Batch jobs during service Laufen Ranglistenberechnung, Massenversand von Ingame-Post oder das Aufräumen alter Daten im laufenden Betrieb, belegen sie Locks und Datenträger. - Warum → Folge → Auf dem Bildschirm: Massenjob läuft während der Betriebszeit → Locks über große Bereiche, Datenträger und CPU belegt → Handel und Speichern schlagen zu bestimmten Zeiten fehl, Laden verzögert - Symptome: Input-Lag, Verschluckte Aktion / Rollback / Faktoren: Latenz, Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: In festen Abständen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: In kleine Portionen aufteilen und schrittweise abarbeiten, Aggregationen auf dem Replikat ausführen. - Aufgaben Infrastrukturteam: Replikat für Aggregationen bereitstellen, Batch-Jobs in ruhige Zeiten legen, Wartevorgänge durch Lock-Eskalation und Gap-Locks überwachen. - Im Graphen: Spitzen in festen Abständen (DB-Query-Latenz, Lock-Wartevorgänge) - Wo nachsehen: Lange Queries suchen, die zum Zeitpunkt des Lags liefen. MySQL: slow query log, PostgreSQL: query_start und query in pg_stat_activity prüfen und mit den Lock-Wartemetriken zur selben Zeit sowie dem Batch-Zeitplan (Cron, Event Scheduler der DB) abgleichen. SQL Server: Lock-Eskalation mit dem Extended Event lock_escalation protokollieren - Spricht dafür: Jedes Mal zur selben Uhrzeit laufen große UPDATE-, DELETE- oder Aggregations-Queries, währenddessen steigen Lock-Wartevorgänge und Disk-Auslastung gemeinsam - Spricht dagegen: Keine langen Queries zu diesem Zeitpunkt: Checkpoint (db-checkpoint) oder Server-Backup (dk-backup) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: SQL Server wandelt Zeilensperren in eine Tabellensperre um, wenn eine Anweisung mehr als etwa 5.000 davon hält (Lock-Eskalation). In diesem Moment stehen alle Anfragen auf dieselbe Tabelle still. Auch MySQL sperrt in der Standardeinstellung bei Änderungen über Bereichsbedingungen die Lücken zwischen den Zeilen mit (Gap-Lock) und verhindert so das Einfügen neuer Zeilen. - Quellen: - [Transaction Locking and Row Versioning Guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide) · Microsoft SQL Server · Hält eine Anweisung auf einer Tabelle (oder einem Index) mindestens 5.000 Locks, folgt eine Lock-Eskalation, protokollierbar mit dem Extended Event lock_escalation - [InnoDB Locking](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html) · MySQL · Unter der InnoDB-Standard-Isolationsstufe REPEATABLE READ nutzen Suchen und Scans Next-Key-Locks; Gap-Locks verhindern dabei das Einfügen neuer Zeilen in die Lücke - [The Slow Query Log](https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html) · MySQL · Protokolliert Queries über long_query_time mit Ausführungszeit (Query_time), Lock-Zeit (Lock_time) und gelesenen Zeilen - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · pg_stat_activity: aktuell laufende Query (query) und Startzeitpunkt (query_start) je Session #### db-failover · DB-Failover · Database failover Fällt die Primär-DB aus und wird auf die Reserve-DB umgeschaltet, sind währenddessen keine Schreibvorgänge möglich, und die letzten noch nicht replizierten Daten können verloren gehen. - Warum → Folge → Auf dem Bildschirm: Primär-DB fällt aus, die Reserve-DB wird zur Primär-DB hochgestuft → Während der Umschaltung einige Sekunden bis einige Minuten keine Schreibvorgänge möglich, bei asynchroner Replikation droht Verlust nicht replizierter Daten → Kurzzeitig schlägt jedes Speichern fehl, Rollback von Items und Erfahrungspunkten - Symptome: Verschluckte Aktion / Rollback, Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Stillstand, Paketverlust - Wer: Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: DB-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Speichern wiederholbar gestalten, abgerissene Verbindungen schnell verwerfen und zur neuen Adresse neu aufbauen lassen (Einstellungen von Connection-Pool und DNS-Cache), bei Failover-Übungen den Reconnect prüfen. - Aufgaben Infrastrukturteam: Synchrone oder semisynchrone Replikation einsetzen (kostet Schreiblatenz), Failover regelmäßig üben, Failover-Dauer und Replikationsverzögerung überwachen. - Größenordnungen: Das automatische Failover verwalteter Datenbanken dauert meist einige Dutzend Sekunden bis 2 Minuten. Bei asynchroner Replikation können die jüngsten Speicherstände im Umfang der Replikationsverzögerung (unter 1 s bis einige Sekunden) verloren gehen. - Im Graphen: Verbindungen brechen gleichzeitig ab (DB-Verbindungen, Schreibfehler) - Wo nachsehen: Failover-Protokoll der DB (bei RDS die Events RDS-EVENT-0013 Failover gestartet und RDS-EVENT-0049 Failover abgeschlossen, bei selbst betriebenen DBs das Promotion-Log) zusammen mit DB-Verbindungen und Verbindungsfehlern der Spielserver in einen Graphen legen. Bei asynchroner Replikation auch die Replikationsverzögerung direkt vor dem Ausfall prüfen (RDS ReplicaLag, replay_lag in PostgreSQL pg_stat_replication) - Spricht dafür: Fehlgeschlagenes Speichern ballt sich in einem Zeitraum zwischen Beginn und Ende des Failovers. Der zurückgesetzte Umfang entspricht etwa der Replikationsverzögerung direkt vor dem Ausfall. Spielserver, bei denen die Fehler nach Abschluss des Failovers weitergehen, nutzen noch Verbindungen zur alten Adresse - Spricht dagegen: Verbindungsabbrüche zu Zeiten ohne Failover-Eintrag: eher Netzwerk oder überlastete DB - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: riot-euw-2021 - Quellen: - [Failing over a Multi-AZ DB instance for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html) · AWS · Multi-AZ-Failover dauert meist 60–120 s, danach müssen Verbindungen neu aufgebaut werden; empfohlen wird eine DNS-Cache-TTL der JVM von höchstens 60 s - [High availability for Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html) · AWS · Während des Ausfalls schlagen Lese- und Schreibzugriffe fehl, die Wiederherstellung erfolgt meist innerhalb von 60 s (oft innerhalb von 30 s) - [Semisynchronous Replication](https://dev.mysql.com/doc/refman/8.4/en/replication-semisync.html) · MySQL · Bei asynchroner Replikation können committete Transaktionen auf dem Replikat fehlen, wenn die Primär-DB ausfällt; semisynchrone Replikation wartet auf die Empfangsbestätigung eines Replikats und verringert so das Risiko, erhöht aber die Latenz - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Log-Shipping ist asynchron, beim Ausfall des Primärservers gehen noch nicht übertragene Transaktionen verloren; die Verzögerung der Streaming-Replikation liegt meist unter 1 s - [Amazon RDS event categories and event messages](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) · AWS · RDS-EVENT-0013: Multi-AZ-Failover gestartet, RDS-EVENT-0049: Multi-AZ-Failover abgeschlossen - [Amazon CloudWatch metrics for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html) · AWS · ReplicaLag: Zeit, um die ein Lesereplikat hinter der Quelle zurückliegt (s) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · replay_lag in pg_stat_replication: Zeit vom Schreiben des WAL auf dem Primärserver, bis das Replikat meldet, es angewendet zu haben #### db-save-interval · Fortschrittsverlust durch lange Speicherintervalle · Periodic save window Wird zur Lastsenkung nur alle paar Minuten gespeichert, geht der Fortschritt verloren, wenn der Server dazwischen abstürzt. - Warum → Folge → Auf dem Bildschirm: Charakterzustand wird nur alle paar Minuten gespeichert → Dazwischen Serverabsturz oder Störung → Nach dem Reconnect Stand von vor einigen Minuten (Rollback) - Symptome: Verschluckte Aktion / Rollback / Faktoren: Paketverlust - Wer: Ganzer Server, Bestimmter Ort oder Kanal / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Wichtige Ereignisse (Handel, seltene Beute) sofort speichern, Änderungslog führen. - Aufgaben Infrastrukturteam: Prüfen, ob die DB genug IOPS- und CPU-Reserven für die zusätzlichen Schreibvorgänge bei kürzeren Speicherintervallen hat. - Im Graphen: Verbindungen brechen gleichzeitig ab (Anzahl der Verbindungen, Rollback-Meldungen) - Wo nachsehen: Zeitpunkt von Absturz oder Störung neben den letzten Speicherzeitpunkt der Charaktere legen, für die ein Rollback gemeldet wurde (Speicherlog des Spielservers oder Spalte mit dem Änderungszeitpunkt in der DB) - Spricht dafür: Der zurückgesetzte Stand entspricht dem letzten Speicherzeitpunkt vor dem Absturz, die verlorene Zeit ist kürzer als das Speicherintervall - Spricht dagegen: Laut Spielserver-Log wurde das Speichern abgeschlossen, trotzdem zurückgesetzt: Datenverlust beim DB-Failover (db-failover) oder alter Wert aus dem Replikat (db-replica-lag) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Asynchronous Commit (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-async-commit.html) · PostgreSQL · Werden Schreibvorgänge gesammelt und verzögert auf den Datenträger geschrieben, steigt der Durchsatz, bei einem Ausfall können aber die jüngsten Transaktionen verloren gehen (derselbe Zielkonflikt) - [Redis persistence](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) · Redis · Bei RDB-Snapshots alle paar Minuten muss man bei einem unerwarteten Beenden mit dem Verlust der Daten der letzten Minuten rechnen #### db-cache-stampede · Cache-Stampede · Cache stampede / thundering herd Laufen die Cache-Einträge beliebter Daten gleichzeitig ab, stürzen sich Tausende Anfragen auf einmal auf die DB. - Warum → Folge → Auf dem Bildschirm: Beliebte Daten in Redis o. Ä. laufen gleichzeitig ab → Anfragen, die dieselben Daten neu erzeugen wollen, landen alle gleichzeitig bei der DB → Überlastete DB, mehrere Funktionen werden nacheinander langsam oder stehen still - Symptome: Input-Lag, Freeze, Kein Login / Endlos-Laden / Faktoren: Stillstand, Latenz - Wer: Ganzer Server / Wann: In festen Abständen, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Ablaufzeitpunkte zufällig streuen, nur eine Anfrage aktualisieren lassen und die übrigen mit dem alten Wert bedienen. - Aufgaben Infrastrukturteam: Replikate und automatisches Failover einrichten, damit der Cache bei Neustart oder Ausfall von Redis nicht komplett leer ist, prüfen, ob die DB genug Reserven hat, um auch einen leeren Cache zu verkraften. - Im Graphen: Spitzen in festen Abständen (Cache-Trefferquote, DB-Queries pro Sekunde) - Wo nachsehen: keyspace_hits und keyspace_misses (Trefferquote), expired_keys und Neustarts (uptime_in_seconds) aus Redis INFO über die DB-Queries pro Sekunde legen und zählen, wie viele gleiche Queries in diesem Moment gleichzeitig auf der DB laufen (MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity) - Spricht dafür: Schießen die Cache-Misses schlagartig hoch, steigt die Zahl der DB-Queries mit, und die meisten gleichzeitig laufenden Queries sind dieselbe Query auf dieselben Daten. Fällt mit dem Ablaufintervall beliebter Keys oder einem Redis-Neustart zusammen - Spricht dagegen: Cache-Misses normal, nur die DB-Queries steigen: Login-Ansturm (db-login-storm) oder Batch-Job (db-batch) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Dasselbe passiert, wenn Redis neu startet oder der Cache durch einen Ausfall komplett leer ist. Besonders gefährdet sind Architekturen, deren DB im Vertrauen auf den Cache knapp dimensioniert ist. - Quellen: - [Scaling Memcache at Facebook (NSDI '13)](https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala) · USENIX · Wird ein häufig genutzter Key invalidiert, landen viele Lesezugriffe bei der DB (Thundering Herd); Gegenmittel sind Leases (nur ein Client aktualisiert) und die Rückgabe veralteter Werte, Cluster mit leerem Cache werden separat vorgewärmt - [Optimal Probabilistic Cache Stampede Prevention](https://www.vldb.org/pvldb/vol8/p886-vattani.pdf) · VLDB Endowment · Laufen beliebte Einträge ab, erzeugen mehrere Anfragen sie gleichzeitig neu (Cache-Stampede); Gegenmittel ist eine probabilistische vorzeitige Aktualisierung vor dem Ablauf - [High availability with Redis Sentinel](https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/) · Redis · Automatisches Failover, das bei Ausfall des Primärservers ein Replikat hochstuft - [INFO](https://redis.io/docs/latest/commands/info/) · Redis · keyspace_hits und keyspace_misses (erfolgreiche und fehlgeschlagene Key-Lookups), expired_keys (abgelaufene Keys), uptime_in_seconds (Zeit seit dem Start) - [SHOW PROCESSLIST Statement](https://dev.mysql.com/doc/refman/8.4/en/show-processlist.html) · MySQL · Je Session die laufende Anweisung (Info) und die Verweildauer im aktuellen Zustand (Time, in Sekunden) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · pg_stat_activity: aktuell laufende Query (query) je Session #### db-long-tx · Lange offene Transaktion · Long-running transaction / MVCC purge lag Bleibt eine Transaktion lange offen, hält sie ihre Locks weiter, und die DB kann alte Datenversionen nicht bereinigen (Purge). Dadurch wird alles nach und nach langsamer. - Warum → Folge → Auf dem Bildschirm: Bei offener Transaktion wird auf die Antwort eines anderen Servers gewartet, oder im laufenden Betrieb läuft eine lange Aggregations-Query auf der Primär-DB → Gehaltene Locks werden nicht freigegeben, alte Datenversionen, die bereinigt werden müssten, stauen sich → Timeouts bei Funktionen, die diese Zeile nutzen, Speichern und Abfragen werden über Stunden insgesamt langsamer - Symptome: Input-Lag, Verschluckte Aktion / Rollback / Faktoren: Latenz, Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Je länger es läuft, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Innerhalb einer Transaktion nicht auf Netzwerkaufrufe oder Benutzereingaben warten, Aggregations-Queries auf dem Replikat ausführen. - Aufgaben Infrastrukturteam: Alarm auf lange offene Transaktionen einrichten und sie zwangsweise beenden, Replikat für Aggregationen bereitstellen, Wachstum von Undo-Log und toten Zeilen überwachen. - Im Graphen: Langsamer Anstieg (Länge des Undo-Logs (History list length), tote Zeilen) - Wo nachsehen: MySQL: mit trx_started in INFORMATION_SCHEMA.INNODB_TRX die älteste Transaktion finden und History list length (noch nicht bereinigte Undo-Log-Menge) im Abschnitt TRANSACTIONS von SHOW ENGINE INNODB STATUS prüfen. PostgreSQL: xact_start und Sessions mit state idle in transaction in pg_stat_activity sowie n_dead_tup in pg_stat_user_tables prüfen - Spricht dafür: Eine Transaktion läuft seit Minuten bis Stunden, währenddessen steigen History list length oder n_dead_tup stetig und sinken erst, wenn nach dem Beenden dieser Transaktion die Bereinigung (Purge, VACUUM) läuft - Spricht dagegen: Keine alten Transaktionen, trotzdem insgesamt langsam: Checkpoint (db-checkpoint) oder Datenträger - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Damit Lesende den Stand vor einer Änderung sehen können, hält die DB alte Versionen vor (MVCC). Diese Einträge lassen sich erst löschen, wenn die älteste Transaktion beendet ist. Bleibt eine Transaktion mehrere Stunden offen, wächst bei MySQL das Undo-Log, und bei PostgreSQL häufen sich tote Zeilen (Dead Tuples), die VACUUM nicht bereinigen kann. Bei SQL Server schrumpft das Transaktionslog nicht und kann sogar den Datenträger füllen. - Quellen: - [InnoDB Multi-Versioning](https://dev.mysql.com/doc/refman/8.4/en/innodb-multi-versioning.html) · MySQL · Solange eine Transaktion alte Versionen sehen kann, lässt sich das Update-Undo-Log nicht verwerfen und das Rollback-Segment wächst; empfohlen wird, auch reine Lesetransaktionen häufig zu committen - [Routine Vacuuming (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/routine-vacuuming.html) · PostgreSQL · Alte Zeilenversionen lassen sich nicht löschen, solange andere Transaktionen sie sehen können; lange offene Transaktionen müssen beendet oder ihre Sessions getrennt werden - [Client Connection Defaults (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-client.html) · PostgreSQL · idle_in_transaction_session_timeout: trennt Sessions, die mit offener Transaktion untätig sind, damit sie Locks nicht lange halten - [Troubleshoot a full transaction log (SQL Server Error 9002)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002) · Microsoft SQL Server · Lange laufende aktive Transaktionen verhindern die Bereinigung des Transaktionslogs - [The INFORMATION_SCHEMA INNODB_TRX Table](https://dev.mysql.com/doc/refman/8.4/en/information-schema-innodb-trx-table.html) · MySQL · TRX_STARTED: Startzeitpunkt der Transaktion - [Purge Configuration](https://dev.mysql.com/doc/refman/8.4/en/innodb-purge-configuration.html) · MySQL · Purge bereinigt die Liste der Undo-Logs committeter Transaktionen (History List), der Rückstand steht als History list length im Abschnitt TRANSACTIONS von SHOW ENGINE INNODB STATUS - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · xact_start (Startzeitpunkt der Transaktion) und state (idle in transaction) in pg_stat_activity, n_dead_tup (geschätzte Zahl toter Zeilen) in pg_stat_user_tables #### db-redis-block · Langsame Redis-Befehle · Redis blocking commands (single-threaded) Redis arbeitet Befehle einzeln nacheinander ab. Ein einziger langsamer Befehl blockiert deshalb alle nachfolgenden Anfragen. - Warum → Folge → Auf dem Bildschirm: Im laufenden Betrieb Komplettsuche per KEYS oder komplettes Lesen bzw. Löschen von Ranglisten und Listen mit Millionen Elementen → Bis dieser Befehl fertig ist, warten alle anderen Anfragen (einige Dutzend ms bis einige Sekunden) → Funktionen mit Sessions, Ranglisten oder Cache stocken gleichzeitig, Login verzögert - Symptome: Freeze, Input-Lag, Kein Login / Endlos-Laden / Faktoren: Stillstand, Latenz - Wer: Ganzer Server, Nur eine bestimmte Funktion / Wann: Gelegentlich, zufällig, In festen Abständen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: KEYS durch SCAN ersetzen, große Keys aufteilen, zum Löschen UNLINK verwenden (Löschen im Hintergrund), Ablaufzeitpunkte verteilen, die in dieselbe Sekunde fallen. - Aufgaben Infrastrukturteam: Log langsamer Befehle (SLOWLOG) überwachen, gefährliche Befehle wie KEYS auf Produktionsservern sperren, große Keys regelmäßig prüfen, THP abschalten und Speicherreserve für fork vorhalten, RDB- und AOF-Persistenz auf dem Replikat ausführen. - Größenordnungen: Normale Befehle dauern unter 1 ms. Werden Millionen Elemente auf einmal verarbeitet, kann es mehrere hundert ms bis einige Sekunden dauern. - Im Graphen: Vereinzelte Spitzen ohne Muster (Redis-Antwortlatenz, Anzahl langsamer Befehle) - Wo nachsehen: Mit SLOWLOG GET Befehle prüfen, die slowlog-log-slower-than überschritten haben, mit CONFIG SET latency-monitor-threshold den Latency Monitor (standardmäßig aus) einschalten und mit LATENCY LATEST und LATENCY DOCTOR die Latenz je Event wie fork oder expire-cycle prüfen. Mit latest_fork_usec aus INFO und redis-cli --bigkeys auch fork-Dauer und große Keys prüfen - Spricht dafür: Zum Zeitpunkt des Stillstands stehen in SLOWLOG KEYS oder Befehle, die große Keys komplett verarbeiten, oder LATENCY verzeichnet zur selben Zeit fork- oder expire-cycle-Events von mindestens einigen Dutzend ms - Spricht dagegen: SLOWLOG und LATENCY leer, nur auf Seite des Spielservers langsam: Netzwerk oder Wartezeiten im Spielserver (SLOWLOG misst nur die Ausführungszeit des Befehls, ohne die Kommunikation mit dem Client) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch in dem Moment, in dem sich der Prozess per fork dupliziert, um eine Sicherungsdatei (RDB-Snapshot) zu erstellen oder das AOF neu zu schreiben, steht Redis still. Auf aktuellen Servern sind das etwa 10 ms pro GB Arbeitsspeicher, bei 30 GB also rund 300 ms. Mit aktivierten großen Pages (THP) wird nach dem fork bei jedem Schreibzugriff eine ganze große Page kopiert (Copy-on-Write), was Stillstand und Speicherverbrauch stark erhöht. Deshalb schaltet man THP meist ab und hält reichlich Speicherreserve vor. Auch wenn sehr viele Keys in derselben Sekunde ablaufen, steht Redis kurz still, weil es sie löschen muss. - Quellen: - [Diagnosing latency issues](https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency/) · Redis · Ein einzelner Thread arbeitet Anfragen nacheinander ab, ein langsamer Befehl blockiert alle folgenden; KEYS durch SCAN ersetzen; fork auf physischen Servern und aktuellen VMs gemessen etwa 9–13 ms pro GB; THP lässt Latenz und Speicherverbrauch durch das Kopieren nach dem fork sprunghaft steigen; massenhaftes Ablaufen in derselben Sekunde führt zu Stillstand - [KEYS](https://redis.io/docs/latest/commands/keys/) · Redis · Im Produktivbetrieb nur mit äußerster Vorsicht verwenden, kann bei großen Datenbanken die Performance ruinieren (auf einem Einsteiger-Laptop 40 ms für 1 Million Keys) - [UNLINK](https://redis.io/docs/latest/commands/unlink/) · Redis · Asynchrones Löschen: Der Key wird sofort entfernt, der Speicher in einem anderen Thread freigegeben - [SLOWLOG](https://redis.io/docs/latest/commands/slowlog/) · Redis · Log langsamer Befehle, die slowlog-log-slower-than überschreiten; die Ausführungszeit enthält keine I/O für die Kommunikation mit dem Client - [Redis latency monitoring](https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency-monitor/) · Redis · latency-monitor-threshold Standard 0 (aus), LATENCY LATEST und LATENCY DOCTOR, Latenzaufzeichnung je Event wie fork oder expire-cycle - [INFO](https://redis.io/docs/latest/commands/info/) · Redis · latest_fork_usec: Dauer des letzten fork (Mikrosekunden) - [Redis CLI](https://redis.io/docs/latest/develop/tools/cli/) · Redis · --bigkeys: durchsucht den Keyspace nach großen Keys #### db-plan-flip · Langsame Query durch geänderten Ausführungsplan · Query plan regression (stats, parameter sniffing) Ändert die DB bei unverändertem Code die Art, wie sie dieselbe Query abarbeitet (Ausführungsplan), dauert eine Query, die gestern 2 ms brauchte, heute mehrere hundert ms. - Warum → Folge → Auf dem Bildschirm: Automatische Statistikaktualisierung, DB-Neustart oder veränderte Datenverteilung lassen die DB den Ausführungsplan neu erstellen → Ein Plan ohne Index wird gewählt, dieselbe Query wird um einen zwei- bis dreistelligen Faktor langsamer und hält Verbindungen belegt → Ohne Deployment lädt eine bestimmte Funktion plötzlich langsam, und auch andere Anfragen warten - Symptome: Input-Lag, Kein Login / Endlos-Laden / Faktoren: Latenz, Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: DB-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Queries, deren Ergebnismenge stark vom Parameterwert abhängt, aufteilen oder Plan-Hints prüfen, Queries so gestalten, dass sie zuverlässig einen Index nutzen. - Aufgaben Infrastrukturteam: Slow-Query-Log und Ausführungspläne überwachen, gute Pläne fixieren (z. B. mit dem Query Store von SQL Server), Zeitpunkte der Statistikaktualisierung steuern. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (Durchschnittliche Ausführungszeit je Query) - Wo nachsehen: Durchschnittszeiten gleich aufgebauter Queries regelmäßig erfassen und den Verlauf prüfen. MySQL: AVG_TIMER_WAIT in events_statements_summary_by_digest, PostgreSQL: mean_exec_time in pg_stat_statements (bis 12 mean_time). Ausführungspläne vor und nach der Verlangsamung mit EXPLAIN oder PostgreSQL auto_explain vergleichen, bei SQL Server über die Ansicht Regressed Queries im Query Store - Spricht dafür: Zu einem Zeitpunkt ohne Deployment steigt die Durchschnittszeit einer Query stufenartig um einen zweistelligen Faktor, der Zeitpunkt fällt mit Statistikaktualisierung oder DB-Neustart zusammen, und der Ausführungsplan hat sich geändert - Spricht dagegen: Ausführungsplan unverändert, trotzdem langsamer: Datenwachstum, Warten auf Locks (db-hot-row) oder Datenträger - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: SQL Server verwendet einen Plan wieder, der für die zuerst übergebenen Werte erstellt wurde (Parameter Sniffing). Wird ein Plan, der für einen neuen Charakter mit wenigen Items entstand, für einen alten Charakter mit Zehntausenden Items verwendet, wird die Query deutlich langsamer; der umgekehrte Fall ist ebenso häufig. Löscht ein Neustart den Plan, ist zunächst alles in Ordnung, bis es wieder schlechter wird. - Quellen: - [Query Processing Architecture Guide](https://learn.microsoft.com/en-us/sql/relational-databases/query-processing-architecture-guide) · Microsoft SQL Server · Parameter Sniffing: Der Ausführungsplan wird beim Kompilieren oder Neukompilieren für die übergebenen Parameterwerte erstellt - [Parameter Sensitive Plan Optimization](https://learn.microsoft.com/en-us/sql/relational-databases/performance/parameter-sensitive-plan-optimization) · Microsoft SQL Server · Bei ungleichmäßiger Datenverteilung passt ein einzelner gecachter Plan nicht für alle Parameterwerte - [Monitor performance by using the Query Store](https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store) · Microsoft SQL Server · Pläne ändern sich durch Statistik-, Schema- oder Indexänderungen, der Plan-Cache hält nur den neuesten Plan; Plan Forcing im Query Store fixiert gute Pläne, die Ansicht Regressed Queries vergleicht langsamer gewordene Queries und ihre Pläne - [Statement Summary Tables](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html) · MySQL · events_statements_summary_by_digest: COUNT_STAR und AVG_TIMER_WAIT (Durchschnittszeit) je Gruppe gleich aufgebauter Queries - [pg_stat_statements — track statistics of SQL planning and execution](https://www.postgresql.org/docs/current/pgstatstatements.html) · PostgreSQL · calls, total_exec_time und mean_exec_time (durchschnittliche Ausführungszeit) je Anweisung - [pg_stat_statements (PostgreSQL 12 Documentation)](https://www.postgresql.org/docs/12/pgstatstatements.html) · PostgreSQL · Bis 12 heißen die Spalten total_time und mean_time - [auto_explain — log execution plans of slow queries](https://www.postgresql.org/docs/current/auto-explain.html) · PostgreSQL · Protokolliert die Ausführungspläne von Queries, die länger als auto_explain.log_min_duration dauern #### db-ddl-lock · Locks durch Schemaänderung (DDL) im laufenden Betrieb · Schema change lock (DDL / metadata lock) Werden einer Tabelle im laufenden Betrieb Spalten oder Indizes hinzugefügt, kann ein einziger, nur kurz benötigter Lock alle Anfragen auf diese Tabelle warten lassen. - Warum → Folge → Auf dem Bildschirm: Ein Hotfix fügt einer Tabelle im laufenden Betrieb Spalten oder Indizes hinzu → Die Schemaänderung wartet auf eine zuvor geöffnete lange Transaktion, alle nachfolgenden Anfragen warten auf die Schemaänderung → Funktionen, die diese Tabelle nutzen (Inventar, Post usw.), stehen komplett still und laufen in Timeouts - Symptome: Input-Lag, Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden / Faktoren: Stillstand - Wer: Nur eine bestimmte Funktion, Ganzer Server / Wann: Gelegentlich, zufällig, Direkt nach Login oder Wartung - Hauptzuständig: DB-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Hotfixes mit Schemaänderungen zeitlich mit der DB-Infrastruktur abstimmen, zuerst Code ausrollen, der auch ohne die neue Spalte funktioniert. - Aufgaben Infrastrukturteam: Kurzes Lock-Wait-Timeout setzen und bei Fehlschlag wiederholen, nur ausführen, wenn keine langen Transaktionen offen sind, Online-Schema-Change-Tools nutzen, große Tabellen im Wartungsfenster ändern. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (Auf Locks wartende Sessions, Query-Latenz der betroffenen Tabelle) - Wo nachsehen: MySQL: Sessions mit State Waiting for table metadata lock in SHOW PROCESSLIST zählen und mit sys.schema_table_lock_waits die blockierende Session (blocking_pid) finden. PostgreSQL: Anfragen mit granted = false und AccessExclusiveLock in pg_locks prüfen und mit pg_blocking_pids() die blockierende Session finden - Spricht dafür: Ab dem Start der Schemaänderung stauen sich alle Queries auf diese Tabelle im Lock-Warten, ganz vorn steht eine nicht beendete Transaktion oder die Anweisung der Schemaänderung - Spricht dagegen: Wartevorgänge nur bei bestimmten Zeilen, andere Zeilen derselben Tabelle laufen normal: Hot Row (db-hot-row) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: MySQL hält bei Schemaänderungen kurz einen Metadata Lock, PostgreSQL den stärksten Tabellen-Lock. Auch wenn die Änderung selbst sofort erledigt ist: Steht eine nicht beendete Transaktion davor, warten dahinter alle Anfragen. - Quellen: - [Online DDL Performance and Concurrency](https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-performance.html) · MySQL · Auch Online-DDL braucht zum Abschluss kurz einen exklusiven Metadata Lock; bei langen Transaktionen wartet es, und die wartende Lock-Anfrage blockiert alle nachfolgenden Transaktionen - [Server System Variables](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html) · MySQL · lock_wait_timeout: Wartelimit für Metadata Locks, Standard 31.536.000 s (1 Jahr) - [ALTER TABLE (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/sql-altertable.html) · PostgreSQL · ALTER TABLE ohne abweichende Angabe holt sich den stärksten Lock ACCESS EXCLUSIVE - [Client Connection Defaults (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-client.html) · PostgreSQL · lock_timeout: bricht die Anweisung ab, wenn länger als diese Zeit auf einen Lock gewartet wird - [General Thread States](https://dev.mysql.com/doc/refman/8.4/en/general-thread-states.html) · MySQL · Waiting for table metadata lock: Thread-Status beim Warten auf einen Metadata Lock - [The schema_table_lock_waits and x$schema_table_lock_waits Views](https://dev.mysql.com/doc/refman/8.4/en/sys-schema-table-lock-waits.html) · MySQL · Auf einen Metadata Lock wartende Session (waiting_query) und blockierende Session (blocking_pid) - [pg_locks (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/view-pg-locks.html) · PostgreSQL · granted = false: Der Lock wird noch erwartet; mode enthält den Lock-Typ, z. B. AccessExclusiveLock - [System Information Functions and Operators (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/functions-info.html) · PostgreSQL · pg_blocking_pids(): Liste der Sessions, die verhindern, dass die angegebene Session einen Lock bekommt ### L13 Serverarchitektur und Betrieb (13 Ursachen) #### in-gateway · Gateway oder Proxy als Zwischenstation · Gateway / proxy hop Steht zwischen Client und Spielserver ein Zwischenserver, kommt bei jeder Station Verarbeitungszeit hinzu, und dieser Server wird zum Single Point of Failure. - Warum → Folge → Auf dem Bildschirm: Aufbau Client ↔ Gateway ↔ Spielserver → Zusätzliche Verarbeitung und Wartezeit im Zwischenserver, bei Überlast sind alle betroffen → Höherer Ping für alle, fällt das Gateway aus, Verbindungsabbruch für alle Spieler, die darüber laufen - Symptome: Input-Lag, Verbindungsabbruch / Faktoren: Latenz, Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang, Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Gateways so auslegen, dass sich weitere Maschinen hinzufügen lassen, Session-Wiederaufnahme vorsehen, damit der Charakter nahtlos weiterläuft, wenn er sich nach dem Ausfall eines Gateways über ein anderes Gateway neu verbindet. Client: bei abgebrochener Gateway-Verbindung automatisch neu verbinden. - Aufgaben Infrastrukturteam: Gateways horizontal skalieren (weitere Maschinen hinzufügen), CPU, Verbindungszahl und Verarbeitungslatenz pro Gateway überwachen. - Größenordnungen: Im selben Rechenzentrum kostet jede Station normalerweise unter 1 ms. Ist das Gateway überlastet, steigt das auf Werte im zwei- bis dreistelligen Millisekundenbereich. - Im Graphen: Steigt mit Spielerzahl und Last (Verarbeitungslatenz des Gateways, CPU und Verbindungszahl des Gateways) - Wo nachsehen: CPU und Verbindungszahl des Gateways sowie Recv-Q der Gateway-Sockets (ss, netstat) prüfen, Latenz vor und hinter dem Gateway vergleichen. Bei HTTP- oder gRPC-Aufrufen über ein Service-Mesh die Istio-Standardmetrik istio_request_duration_milliseconds getrennt nach Sender (reporter=source) und Empfänger (reporter=destination) vergleichen - Spricht dafür: Verarbeitungszeit im Spielserver unverändert, nur die Latenz im Gateway-Abschnitt steigt, und zur selben Zeit ist die Gateway-CPU ausgelastet oder die Recv-Q staut sich - Spricht dagegen: Wege ohne Gateway (Direktverbindung, anderes Gateway) genauso langsam: eher Leitung oder Spielserver - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Mit einem Service-Mesh (etwa Istio) kommt der Sidecar-Proxy (Envoy), der neben jedem Server läuft, als weitere Station hinzu. Anfragen zwischen Diensten durchlaufen nacheinander den Sidecar des Senders und den Sidecar des Empfängers. Je mehr Funktionen der Proxy übernimmt, etwa das Sammeln von Logs und Metriken, desto länger werden Verarbeitungs- und Wartezeit. - Reale Fälle: riot-edge-2020 - Quellen: - [The Unique Architecture behind Amazon Games’ Seamless MMO New World](https://aws.amazon.com/blogs/gametech/the-unique-architecture-behind-amazon-games-seamless-mmo-new-world/) · AWS · Bei New World verbindet sich der Client mit einem von 4 Eingangsservern (REP) mit öffentlicher Adresse und kommuniziert darüber mit den dahinterliegenden Simulationsservern (Hubs) - [Designs, Lessons and Advice from Building Large Distributed Systems](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Keynote auf der LADIS 2009 (Jeff Dean). Round Trip innerhalb desselben Rechenzentrums etwa 0,5 ms - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Wird die Queue bei Überlast lang, wächst die Wartezeit auf ein Vielfaches der Verarbeitungszeit (100 ms Verarbeitung, Queue mit dem 10-Fachen der Thread-Zahl: 1,1 s) - [Performance and Scalability](https://istio.io/latest/docs/ops/deployment/performance-and-scalability/) · Istio · Im Sidecar-Modus durchlaufen Anfragen nacheinander den Sidecar-Proxy des Senders und den des Empfängers. Mit jeder zusätzlichen Funktion wird der Verarbeitungspfad im Proxy länger, und das Sammeln von Telemetrie erhöht die Wartezeit der nächsten Anfrage - [What is Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy) · Envoy · Envoy läuft als eigener Prozess neben jedem Anwendungsserver, die App kommuniziert über den Envoy auf localhost - [Istio Standard Metrics](https://istio.io/latest/docs/reference/config/metrics/) · Istio · istio_request_duration_milliseconds (Verteilung der Bearbeitungszeit von HTTP- und gRPC-Anfragen), das Label reporter unterscheidet den Proxy des Senders (source) und des Empfängers (destination) - [netstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/netstat.8.html) · net-tools · Recv-Q: Anzahl der Bytes auf einem verbundenen Socket, die das Anwenderprogramm noch nicht abgeholt hat #### in-zone-transfer · Zonenwechsel (Übergabe zwischen Servern) · Zone / server handoff Beim Betreten eines anderen Gebiets oder Dungeons werden die Charakterdaten an einen anderen Server übergeben. Dabei kommt es zu Verzögerungen und Fehlschlägen. - Warum → Folge → Auf dem Bildschirm: Dungeon-Eintritt oder Kontinentwechsel, der zuständige Server wechselt → Speichern → Übertragen → Laden, Wartezeit, wenn der Zielserver ausgelastet ist oder keine freie Dungeon-Instanz bereitsteht → Langes Laden, Eintritt schlägt fehl, Verbindungsabbruch während des Wechsels - Symptome: Kein Login / Endlos-Laden, Freeze, Verbindungsabbruch, Rubberbanding / Faktoren: Latenz, Stillstand - Wer: Nur ich, Bestimmter Ort oder Kanal / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Übergabedaten verkleinern, Zielserver vorab reservieren, bei Fehlschlag an den ursprünglichen Ort zurückversetzen. - Aufgaben Infrastrukturteam: Freie Instanzen auf Dungeon- und Zonenservern überwachen, vor der Stoßzeit genug Maschinen bereitstellen. - Im Graphen: Steigt mit Spielerzahl und Last (Dauer und Fehlschläge von Zonenwechseln) - Wo nachsehen: Vom Server protokollierte Dauer je Übergabeschritt (Speichern, Übertragen, Laden) und Fehlergründe auswerten, dazu Spielerzahl und freie Instanzen des Zielservers - Spricht dafür: Zur Zeit der Meldungen über langes Laden oder gescheiterten Eintritt steigt die Übergabedauer oder Fehlschläge häufen sich, und der Zielserver ist ausgelastet oder hat keine freien Instanzen mehr - Spricht dagegen: Übergabe schnell erledigt, Stillstand erst nach der Ankunft: eher „Spawn-Flut beim Betreten belebter Gebiete“ oder Laden im Client - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Auch in einer nahtlosen Welt ohne Ladebildschirme wechselt der zuständige Server, sobald man eine Servergrenze überschreitet. Nahe der Grenze kann es kurz stocken, oder der Charakter wird zurückgezogen (Rubberbanding). - Quellen: - [The Unique Architecture behind Amazon Games’ Seamless MMO New World](https://aws.amazon.com/blogs/gametech/the-unique-architecture-behind-amazon-games-seamless-mmo-new-world/) · AWS · Die Welt ohne Ladebildschirme ist in ein Raster aufgeteilt, das mehrere Server (Hubs) übernehmen. Bewegt sich ein Spieler, wird sein Zustand von Hub zu Hub übergeben. Sessionbasierte Modi beziehen freie Server aus einem gemeinsamen Pool #### in-cascade · Kaskadierender Ausfall · Cascading failure Wird ein Dienst langsam, hängen die Server, die ihn aufrufen, beim Warten auf Antworten fest, und selbst unbeteiligte Funktionen bleiben stehen. - Warum → Folge → Auf dem Bildschirm: Ein Dienst wie DB oder Authentifizierung wird langsam → Threads und Verbindungen der aufrufenden Server hängen beim Warten auf Antworten fest, Retries fehlgeschlagener Anfragen erhöhen die Last → Selbst scheinbar unbeteiligte Funktionen werden langsam oder bleiben stehen - Symptome: Freeze, Input-Lag, Kein Login / Endlos-Laden / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Timeout für jeden Aufruf, Circuit-Breaker, Isolation pro Funktion (Bulkhead), Retries mit wachsendem Abstand und begrenzter Anzahl, Antworten auf Health-Checks von aufwendiger Arbeit entkoppeln. - Aufgaben Infrastrukturteam: Health-Checks des Load-Balancers mit Spielraum bei Fehleranzahl und Intervall konfigurieren, damit kurz langsame Server nicht sofort herausfallen, Zahl der gleichzeitig entfernten Server begrenzen. - Im Graphen: Plateau am Limit (Antwortzeit und Fehlerrate pro Dienst, belegte Threads und Verbindungen) - Wo nachsehen: Antwortzeit, Fehlerrate und Retries pro Dienst mit gleicher Zeitachse auf einem Bildschirm darstellen und den Dienst finden, der zuerst langsam wurde. Hinter einem Load-Balancer: Antwortzeit der Ziele (bei AWS ALB TargetResponseTime), 5xx-Anzahl der Ziele (HTTPCode_Target_5XX_Count), Zahl der als fehlerhaft entfernten Ziele (UnHealthyHostCount) - Spricht dafür: Latenz eines Dienstes steigt zuerst, danach erreichen belegte Threads und Verbindungen der Aufrufer ihr Limit, Fehler greifen auf andere Dienste über, und Retries sowie entfernte Ziele nehmen gleichzeitig zu - Spricht dagegen: Mehrere Dienste im selben Moment langsam: zuerst Störungen gemeinsamer Ressourcen (DB, Netzwerk, Host) prüfen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch Health-Checks (Prüfungen, ob ein Server noch lebt) verstärken die Kaskade. Antwortet ein ausgelasteter Server zu spät auf die Prüfung, nimmt der Load-Balancer einen eigentlich funktionierenden Server aus dem Betrieb. Dessen Traffic landet bei den übrigen Servern, und der nächste Server wird ebenfalls langsam. - Reale Fälle: riot-edge-2020, riot-euw-2021, roblox-2021, aws-2021, aws-2025 - Quellen: - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Fällt ein überlasteter Server beim Health-Check durch und wird entfernt, konzentriert sich die Last auf die übrigen Server, und Retries erhöhen sie weiter. Empfohlen: begrenzte Retries, exponentielles Backoff mit Zufallsanteil, Deadlines - [Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) · Microsoft Azure · Bis zum Timeout blockierte Anfragen belegen Threads und DB-Verbindungen und lassen auch unbeteiligte Funktionen scheitern. Häufen sich Fehler innerhalb einer festen Zeit, werden Aufrufe sofort abgewiesen - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Bei einer Aufrufkette über 5 Ebenen mit je 3 Retries pro Ebene steigt die DB-Last auf das 243-Fache. Retries nur an einer Stelle durchführen und per Token-Bucket begrenzen - [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) · AWS · TargetResponseTime (Zeit vom Verlassen des Load-Balancers bis zum Antwortbeginn des Ziels), HTTPCode_Target_5XX_Count (vom Ziel erzeugte 5xx-Antworten), UnHealthyHostCount (Zahl fehlerhafter Ziele) #### in-subservice · Ausfall eines Zusatzservers · Auxiliary service outage Fällt ein Server aus, der getrennt vom Spielserver läuft, etwa für Chat, Gruppen oder das Auktionshaus, funktioniert nur diese eine Funktion nicht mehr. - Warum → Folge → Auf dem Bildschirm: Server für eine einzelne Funktion wird langsam oder fällt aus → Nur Anfragen an diese Funktion bleiben unbeantwortet → Chat geht nicht, Gruppeneinladung ohne Reaktion, Endlos-Laden im Auktionshaus (Kämpfe laufen normal) - Symptome: Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden / Faktoren: Stillstand, Paketverlust - Wer: Nur eine bestimmte Funktion / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: So auslegen, dass das Spiel bei Fehlern weiterläuft, Status pro Funktion anzeigen, nicht mehrere Funktionen auf einem einzigen zentralen Server bündeln. - Aufgaben Infrastrukturteam: Health-Checks und Alarme pro Zusatzserver, Redundanz und automatischer Neustart. - Im Graphen: Verbindungen brechen gleichzeitig ab (Erfolgsrate der Anfragen pro Funktion, Verbindungszahl und Health-Checks der Zusatzserver) - Wo nachsehen: Health-Checks, Prozessstatus und Verbindungszahl jedes Zusatzservers wie Chat, Gruppe oder Auktionshaus sowie Erfolgsrate und Antwortzeit der Anfragen pro Funktion prüfen. Hinter einem Load-Balancer: UnHealthyHostCount der Zielgruppe - Spricht dafür: Nur der Server der gemeldeten Funktion zeigt fehlgeschlagene Health-Checks oder einen Einbruch der Verbindungen, Tick und Kämpfe auf dem Spielserver normal - Spricht dagegen: Mehrere Funktionen gleichzeitig ausgefallen: eher der zentrale Server, der diese Funktionen gemeinsam weiterleitet, oder „Kaskadierender Ausfall“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Leitet ein einziger zentraler Server (World- oder Manager-Server) Gruppen, Gilden, Flüstern und Serverwechsel weiter, bleiben mehrere Funktionen gleichzeitig stehen, sobald dieser eine Server langsam wird. - Quellen: - [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead) · Microsoft Azure · Werden Komponenten in Pools isoliert, laufen die übrigen weiter, wenn eine ausfällt, und die Störung breitet sich nicht aus - [REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) · AWS · AWS Well-Architected. Auslegung, bei der Kernfunktionen auch bei Ausfall einer Abhängigkeit mit leicht veralteten oder ersatzweisen Daten weiterlaufen - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · UnHealthyHostCount: Zahl der Ziele, die der Health-Check als fehlerhaft eingestuft hat #### in-deploy · Deployment und Neustart · Deploy / rolling restart Werden Server für ein Update neu gestartet, ohne die Verbindungen umzuziehen, verlieren alle Spieler auf diesem Server die Verbindung. Speichervorgänge kurz vor dem Herunterfahren und anschließende Reconnects ballen sich. - Warum → Folge → Auf dem Bildschirm: Server werden für ein Hotfix-Deployment nacheinander neu gestartet → Herunterfahren ohne Umzug der Verbindungen auf andere Server, Speichervorgänge aller Spieler dieses Servers treffen gleichzeitig die DB → Verbindungsabbruch ohne Ankündigung, Reconnect-Ansturm - Symptome: Verbindungsabbruch, Kein Login / Endlos-Laden, Input-Lag / Faktoren: Stillstand - Wer: Ganzer Server, Bestimmter Ort oder Kanal / Wann: Gelegentlich, zufällig, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Draining-Funktion (nur neue Verbindungen sperren und warten, bis die vorhandenen Spieler gegangen sind), Charaktere auf andere Server verschieben, Speichern vor dem Herunterfahren zeitlich verteilen, nach dem Neustart erst Cache-Laden und JIT-Warm-up abschließen und dann Bereitschaft melden, bei Hot Reload vorab in einem eigenen Thread einlesen und zwischen zwei Ticks auf einmal austauschen. - Aufgaben Infrastrukturteam: Deployment-Tool wartet pro Maschine das Draining ab und startet dann neu, neu gestartete Server erst nach bestätigter Bereitschaft (Warm-up abgeschlossen) Traffic annehmen lassen, Deployment-Zeitpunkt ankündigen. - Größenordnungen: Bei 5.000 Spielern auf einem Server treffen kurz vor dem Herunterfahren innerhalb weniger Sekunden 5.000 Speichervorgänge auf die DB. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungen pro Server, DB-Schreibvorgänge) - Wo nachsehen: Aufzeichnungen des Deployment-Tools (Neustartzeit pro Server) als vertikale Linien (Annotationen) über die Graphen von Verbindungen, Verbindungsabbrüchen, DB-Schreibvorgängen und Login-Anfragen legen - Spricht dafür: Verbindungen pro Server brechen zu den Neustartzeiten nacheinander Server für Server ein, kurz davor schießen die DB-Schreibvorgänge hoch, kurz danach die Login-Anfragen - Spricht dagegen: Zeitpunkt der Abbrüche passt nicht zu den Aufzeichnungen über Deployment und Neustart: eher „Serverabsturz“ oder Netzwerkgeräte - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch die ersten Minuten nach dem Neustart sind langsam. Der Cache ist leer, DB-Abfragen häufen sich, und bei Java- oder C#-Servern ist die Optimierung des Codes zur Laufzeit (JIT-Warm-up) noch nicht abgeschlossen, sodass dieselbe Arbeit länger dauert. Auch das Neuladen von Skripten oder Datentabellen ohne Neustart (Hot Reload) hält den Tick während des Einlesens an und verursacht einen kurzen Freeze. - Quellen: - [Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/) · Google · Ein Server, der SIGTERM erhält, leitet im Lame-Duck-Zustand neue Anfragen an andere Server um und schließt nur laufende Anfragen ab. In den ersten Minuten nach dem Neustart fehlt noch die JIT-Optimierung, er braucht mehr Ressourcen und nimmt deshalb erst nach dem Warm-up Traffic an - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Readiness-Prüfung: kein Traffic, bis Verbindungsaufbau, Laden von Dateien und Cache-Warm-up abgeschlossen sind - [Edit target group attributes for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/edit-target-group-attributes.html) · AWS · Nach dem Abmelden eines Ziels erhält es keine neuen Verbindungen mehr, bestehende laufen per Draining aus (Standard 300 s) #### in-autoscale · Verzögertes Autoscaling · Autoscaling lag Bei großem Andrang werden automatisch weitere Server gestartet, doch die Vorbereitung dauert einige Minuten. In dieser Zeit sind die vorhandenen Server überlastet. - Warum → Folge → Auf dem Bildschirm: Eventstart, die Verbindungen schnellen hoch → Bis ein neuer Server läuft und bereit ist, vergehen einige Minuten → In den ersten Minuten nach Eventbeginn Zeitlupe, kein Login oder Endlos-Laden - Symptome: Zeitlupe, Kein Login / Endlos-Laden / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang, Direkt nach Login oder Wartung - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Auf Kanäle verteilen (wer schon in einem vollen Kanal ist, lässt sich nicht auf einen neuen Server verschieben), Start- und Ladezeit neuer Server verkürzen. - Aufgaben Infrastrukturteam: Vor Events vorab skalieren, vorgewärmte Reserveserver bereithalten, beim Herunterskalieren Server erst abschalten, wenn die verbliebenen Spieler gegangen sind. - Größenordnungen: 1 bis einige Minuten, bis die Last erkannt wird (weil Metriken über mehrere Minuten gemittelt werden), dann nochmals einige Minuten, um neue Server zu starten, Spieldaten zu laden und Caches zu füllen. - Im Graphen: Ansturm direkt nach Login oder Wartung (Anzahl Instanzen, CPU-Auslastung, wartende Verbindungen) - Wo nachsehen: Aktivitätsverlauf des Autoscalings (Zeitpunkt der Skalierungsentscheidung, Zeitpunkt der Inbetriebnahme neuer Instanzen) über die Graphen von CPU-Auslastung und Verbindungen legen. Bei AWS die Metriken der Auto-Scaling-Gruppe (nur sichtbar, wenn aktiviert): GroupDesiredCapacity (Sollanzahl), GroupPendingInstances (in Vorbereitung), GroupInServiceInstances (in Betrieb) - Spricht dafür: Nach dem Anstieg der Verbindungen wachsen einige Minuten lang nur Sollanzahl und Instanzen in Vorbereitung, die CPU der vorhandenen Server klebt am Limit, und erst ab dem Zeitpunkt, an dem die Instanzen in Betrieb zunehmen, entspannt sich die Lage - Spricht dagegen: Auch nach Inbetriebnahme neuer Instanzen langsam: Ursache außerhalb der Serveranzahl (gemeinsame Ressourcen wie die DB, „Kaskadierender Ausfall“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Autoscaling wird vor allem dort eingesetzt, wo neue Server einfach neue Spieler aufnehmen können, etwa bei Login, Gateways oder Dungeons. Auch das Herunterskalieren macht Probleme. Werden Server in den frühen Morgenstunden mit wenigen Spielern abgebaut, ohne zu warten, bis die verbliebenen Spieler gegangen sind, verlieren diese die Verbindung. - Reale Fälle: aws-2021, aws-2025 - Quellen: - [Target tracking scaling policies for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) · AWS · EC2-Basismetriken kommen im 5-Minuten-Intervall (mit Detailed Monitoring 1 Minute). Für schnelle Reaktion werden Metriken mit einem Intervall von 1 Minute oder kürzer empfohlen - [Amazon CloudWatch metrics for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-metrics.html) · AWS · Gruppenmetriken werden erst nach Aktivierung im 1-Minuten-Takt veröffentlicht, GroupDesiredCapacity (Anzahl, die gehalten werden soll), GroupPendingInstances (Instanzen, die noch nicht in Betrieb sind), GroupInServiceInstances (Instanzen in Betrieb) - [Scheduled scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) · AWS · Kapazität zu festgelegten Zeiten vorab erhöhen und senken, passend zu vorhersehbaren Laständerungen - [Decrease latency for applications with long boot times using warm pools](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) · AWS · Bei Apps mit langer Startzeit verringert ein Pool vorinitialisierter Instanzen (Warm Pool) die Skalierungsverzögerung #### in-monitoring · Überlastung durch Logging und Monitoring · Logging / monitoring overhead Bei einer Störung explodiert die Logmenge, und Server, die Logs synchron weitergeben, werden durch das Logging noch langsamer. - Warum → Folge → Auf dem Bildschirm: Fehler treten auf, das Volumen von Logs und Metriken schießt hoch → Log-Collector kommt nicht nach, Server mit synchronem Versand warten → Ruckeln und Freezes während der Störung werden durch das Logging verstärkt - Symptome: Ruckeln, Freeze / Faktoren: Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Asynchron senden, Sampling, bei vollem Puffer verwerfen, gleiche Fehlermeldungen gebündelt senden. - Aufgaben Infrastrukturteam: Kapazität des Log-Collectors auf das Spitzenvolumen bei Störungen auslegen, Alarm bei Rückstau im Collector. - Im Graphen: Vereinzelte Spitzen ohne Muster (Logvolumen, Warteschlange des Log-Collectors) - Wo nachsehen: Logzeilen und Bytes pro Sekunde auf dem Server sowie Warteschlange und verworfene Einträge des Log-Agents zusammen mit der Tick-Zeit auswerten. Bei hängenden Threads mit bcc offcputime -p prüfen, ob sie beim Schreiben oder Versenden von Logs warten - Spricht dafür: Zum Zeitpunkt der Tick-Spitze steigt die Logmenge um einen zweistelligen Faktor über den Normalwert, und die Wartezeit des Game-Threads konzentriert sich auf Call-Stacks des Log-Schreibens und -Versands - Spricht dagegen: Logmenge normal oder Game-Thread wartet nicht beim Logging: Die Log-Flut ist nur eine Folge der Störung, die Ursache des ersten Fehlers gesondert suchen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Logging in C#](https://learn.microsoft.com/en-us/dotnet/core/extensions/logging) · Microsoft · .NET-Logmethoden sind synchron. Bei langsamem Speicherziel wird empfohlen, zuerst in einen schnellen Speicher zu schreiben und später zu verschieben - [Asynchronous loggers](https://logging.apache.org/log4j/2.x/manual/async.html) · Apache Software Foundation · Asynchrones Logging fängt kurze Spitzen mit einer Queue ab. Bleibt die Ausgabe dauerhaft langsam, füllt sich die Queue, und das Tempo fällt auf das der langsamsten Ausgabe zurück, oder Logs werden je nach Richtlinie verworfen (Discard) - [Demonstrations of offcputime, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/offcputime_example.txt) · IO Visor · Summiert die Zeit, in der Threads angehalten waren und die CPU verlassen hatten (off-CPU), pro Call-Stack, -p wählt den Prozess #### in-clock-skew · Uhrenabweichung zwischen Servern · Clock skew between servers Gehen die Uhren der Server leicht unterschiedlich, werden Cooldowns, Buffs und Eventstarts auf jedem Server etwas anders bewertet. - Warum → Folge → Auf dem Bildschirm: Uhr eines Servers ohne laufende Zeitsynchronisation weicht um mehrere hundert ms bis einige Sekunden von den anderen Servern ab → Werden absolute Zeitpunkte wie das Ende eines Buffs zwischen Servern übergeben, stimmen die Entscheidungen nicht mehr überein → Nach einem Wechsel ist der Buff weg oder der Cooldown beginnt von vorn - Symptome: Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur ich / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Zwischen Servern Restzeiten übergeben (keine absoluten Zeitpunkte). - Aufgaben Infrastrukturteam: Zeitsynchronisation (NTP, chrony) überwachen, Alarm bei Uhrenabweichung zwischen Servern. - Größenordnungen: Läuft die Zeitsynchronisation (NTP, chrony) normal, liegen Server im selben Rechenzentrum meist innerhalb weniger ms. Stoppt die Synchronisation oder steht ein virtueller Server lange still und läuft dann weiter, wächst die Abweichung auf mehrere hundert ms bis einige Sekunden. - Im Graphen: Langsamer Anstieg (Uhrenoffset pro Server) - Wo nachsehen: Für jeden Server System time (Abweichung zwischen Systemuhr und NTP-Zeit), Last offset und Ref time (Zeitpunkt, zu dem zuletzt ein Messwert der Zeitquelle übernommen wurde) aus chronyc tracking sammeln und vergleichen - Spricht dafür: Offset des betroffenen Servers weicht um mehrere hundert ms oder mehr von den anderen ab, oder Ref time steht schon lange still, und die Abweichungen treten nur bei Wechseln von oder zu diesem Server auf - Spricht dagegen: Offset aller Server innerhalb weniger ms: eher Zeitberechnung im Spielcode oder „Fehler bei der Uhrensynchronisation“ im Client - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Springt die Uhr eines einzelnen Servers auf einmal vor oder zurück, behandelt das die Ursache „Sprung der Systemuhr (NTP-Step)“ in der Schicht Server-OS. - Quellen: - [RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification](https://www.rfc-editor.org/rfc/rfc5905) · IETF · NTP-Clients in einem schnellen LAN liegen meist innerhalb weniger hundert µs - [chrony – Frequently Asked Questions](https://chrony-project.org/faq.html) · chrony · Die Drift einer normalen Computeruhr liegt unter 100 ppm, bei virtuellen Maschinen kann sie größer sein. Eine pausierte und fortgesetzte VM kann eine falsche Uhrzeit haben und eine Step-Korrektur brauchen - [clock_gettime(2) — Linux manual page](https://man7.org/linux/man-pages/man2/clock_gettime.2.html) · Linux man-pages · CLOCK_REALTIME kann durch manuelle Änderung oder NTP-Korrektur sprunghaft verstellt werden, CLOCK_MONOTONIC ist von solchen Sprüngen nicht betroffen - [chronyc(1)](https://chrony-project.org/doc/4.6/chronyc.html) · chrony · System time (Abweichung zwischen NTP-Zeit und Systemuhr), Last offset (bei der letzten Korrektur geschätzter Offset), Ref time (Zeitpunkt, zu dem der letzte Messwert der Zeitquelle übernommen wurde) aus chronyc tracking #### in-bots · Zu viele Makros und Bots · Bots and macros Bots senden viel häufiger Anfragen als Menschen und zehren die Verarbeitungskapazität des Servers auf. - Warum → Folge → Auf dem Bildschirm: Massenhaft Bots online, die ohne Pause farmen, laufen oder handeln → Mehr Serverlast und DB-Last → Ein bestimmtes Farmgebiet oder der ganze Server wird langsam (Zeitlupe, Input-Lag) - Symptome: Zeitlupe, Input-Lag / Faktoren: Stillstand - Wer: Ganzer Server, Bestimmter Ort oder Kanal / Wann: Immer, Abendliche Stoßzeit - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Bots erkennen, Anfragefrequenz pro Account und Charakter begrenzen. - Aufgaben Infrastrukturteam: Verbindungs- und Anfragefrequenz pro IP begrenzen (großzügig, weil sich in PC-Bangs und Mobilfunknetzen viele Spieler eine IP teilen), Adressbereiche von Bots per Firewall oder WAF sperren. - Im Graphen: Nur einzelne Ausreißer (Anfragen pro Sekunde je Account und IP) - Wo nachsehen: Aus den Spielserver-Logs die Verteilung der Anfragen pro Sekunde je Account und Charakter sowie die Spitzenreiter auswerten. Ohne Code-Metriken: Anfragen pro IP aus Firewall oder WAF - Spricht dafür: Wenige Accounts oder IPs senden ununterbrochen mit einer Frequenz, die kein Mensch schafft, und ihre Begrenzung senkt die Serverlast deutlich - Spricht dagegen: Anfragen gleichmäßig über die Accounts verteilt: eher normaler Spielerzuwachs („Überschrittenes Tick-Budget“, „Verzögertes Autoscaling“) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Using rate-based rule statements in AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html) · AWS · Anfragen werden nach Kriterien wie der IP gezählt, bei zu vielen innerhalb eines festen Zeitfensters greift ein Rate-Limit - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Teilen sich mehrere Anschlüsse eine IP, treffen Sperren und Limits pro IP auch andere Nutzer #### in-external · Abhängigkeit von externen Diensten · External dependencies (auth, billing, platform) Sind externe Dienste wie Plattform-Login, Zahlung oder Identitätsprüfung langsam oder ausgefallen, bleibt der Vorgang an diesem Schritt hängen. - Warum → Folge → Auf dem Bildschirm: Störung oder Verzögerung beim externen Authentifizierungs- oder Zahlungsdienst → An diesem Schritt wird auf eine Antwort gewartet → Kein Login, Zahlung schlägt fehl. Wer schon spielt, merkt nichts - Symptome: Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback / Faktoren: Stillstand - Wer: Ganzer Server, Nur eine bestimmte Funktion / Wann: Direkt nach Login oder Wartung, Bei bestimmten Aktionen - Hauptzuständig: Extern (Extern) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Timeouts für externe Aufrufe mit verständlichem Hinweis, Authentifizierungsergebnisse cachen, Wiederholungs- und Ausgleichsverfahren für Zahlungen. - Aufgaben Extern: Authentifizierungs-, Zahlungs- oder Plattformanbieter um Bestätigung der Störung und Behebung bitten, Spieler darauf hinweisen, dass ein externer Dienst gestört ist. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (Antwortzeit und Fehlerrate externer Aufrufe, erfolgreiche Logins) - Wo nachsehen: Antwortzeit, Fehlerrate und Timeouts pro externem Aufruf wie Plattform-Login, Zahlung oder Identitätsprüfung sowie die Statusseite des Anbieters prüfen - Spricht dafür: Ab dem Zeitpunkt gehäufter Login- oder Zahlungsfehler steigen nur Fehler und Timeouts eines bestimmten externen Aufrufs um eine Stufe und bleiben dort, und die Statusseite des Anbieters meldet zur selben Zeit eine Störung - Spricht dagegen: Externe Aufrufe normal, Login trotzdem blockiert: eher der Login-Server selbst („Erschöpfter Thread-Pool“, DB) oder die Verbindungswarteschlange des Betriebssystems (Backlog) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Reale Fälle: fastly-2021, aws-2021, aws-2025 - Quellen: - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Beim Warten auf eine Antwort bleiben Ressourcen wie Threads und Verbindungen belegt, daher Timeouts setzen und APIs mit Seiteneffekten nur wiederholen, wenn Idempotenz garantiert ist - [Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) · Microsoft Azure · Aufrufe, die wahrscheinlich scheitern, sofort abweisen, ohne bis zum Timeout zu warten, damit die Antwortzeit gehalten wird - [REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) · AWS · AWS Well-Architected. Kernfunktionen auch bei Ausfall eines abhängigen Dienstes erhalten, notfalls mit leicht veralteten Daten (Grundlage für das Cachen von Authentifizierungsergebnissen) #### in-region-match · Fehlerhaftes Matchmaking oder falsche Regionszuweisung · Wrong region assignment (matchmaking / GeoDNS) Wird ein Spieler einem Server in einer weit entfernten Region zugewiesen, obwohl es eine nähere gibt, hat genau dieser Spieler dauerhaft hohen Ping, auch wenn seine Leitung in Ordnung ist. - Warum → Folge → Auf dem Bildschirm: Fehlerhafte GeoIP-Daten, VPN, Zuweisung der ganzen Gruppe nach dem durchschnittlichen Ping der Mitglieder, Regel zur Ausweitung auf ferne Regionen bei zu wenigen Spielern, Zuweisung nach dem Standort des DNS-Resolvers → Verbindung zu einem Server in einer Region in Übersee, obwohl eine nahe Region existiert → In einem Spiel mit Servern in mehreren Regionen hat nur man selbst (oder nur die eigene Gruppe) dauerhaft hohen Ping, dazu Input-Lag, Rubberbanding und verschluckte Skills - Symptome: Input-Lag, Rubberbanding, Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur ich, Bestimmte Region oder Provider / Wann: Immer, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam), Extern (Extern) - Aufgaben Entwicklungsteam: Server: Regionen anhand des vom Client gemessenen Pings pro Region zuweisen, ohne sich auf GeoIP zu verlassen, Regel zur Ausweitung auf ferne Regionen mit einer Ping-Obergrenze versehen, bei Gruppen neben dem Durchschnitt auch den höchsten Ping eines Gruppenmitglieds berücksichtigen, zugewiesene Region und den Ping zu diesem Zeitpunkt loggen. Client: Ping pro Region per UDP messen und mit der Matchmaking-Anfrage mitschicken, verbundene Region und Ping auf dem Bildschirm anzeigen, manuelle Regionswahl anbieten. - Aufgaben Infrastrukturteam: Bei Regionswahl per DNS prüfen, ob der autoritative DNS-Server EDNS Client Subnet unterstützt (sendet der Resolver des Spielers es nicht mit, erfolgt die Zuweisung nach dem Standort des Resolvers), GeoIP-Datenbank regelmäßig aktualisieren, Verbindungslogs der regionalen Server mit GeoIP-Land und ASN anreichern, um Länder und Provider zu finden, die in ferne Regionen geleitet werden. - Aufgaben Extern: Spieler bitten, VPN oder Ping-Booster abzuschalten und sich neu zu verbinden, Spielern mit Firmen- oder Auslands-DNS empfehlen, auf den DNS ihres Providers umzustellen, beim GeoIP-Anbieter die Korrektur falscher Standorte beantragen. - Größenordnungen: Landet ein Spieler aus Seoul in der Region US-Westküste und nicht in Tokio, steigt der Ping von etwa 30 ms auf etwa 130 ms. GeoIP liegt auf Länderebene zu etwa 99,8 % richtig. Auf Stadtebene liegen selbst in den USA nur etwa 66 % innerhalb von 50 km, und bei VPN-Nutzung liefert GeoIP den Standort des VPN-Servers. - Im Graphen: Nur einzelne Ausreißer (RTT (Ping) pro Spieler, Verteilung der zugewiesenen Regionen) - Wo nachsehen: Client-IPs aus den Verbindungsaufzeichnungen der regionalen Server (Zugriffslogs des Load-Balancers, VPC Flow Logs) mit GeoIP-Land und ASN anreichern und zählen, welche Länder und Provider sich mit welcher Region verbinden. Bei einem einzelnen Spieler die tatsächlich verbundene Region mit dem Ping zur nahen Region vergleichen (vom Spieler gemessen oder per mtr vom Server dieser Region zur Spieler-IP) - Spricht dafür: Spieler oder Länder mit hoher RTT sind mit einer fernen Region verbunden, obwohl eine nahe existiert, und der Ping zur nahen Region ist niedrig - Spricht dagegen: Korrekt der nahen Region zugewiesen, Ping trotzdem hoch: eher „Umweg-Routing“ oder Leitung bzw. WLAN des Spielers - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Bei der Regionswahl per DNS (geo- oder latenzbasiertes DNS) wird der Standort anhand der Adresse des DNS-Resolvers geschätzt, den der Spieler nutzt. Die Adresse des Spielers selbst sieht das DNS dabei nicht. Unterstützt der Resolver EDNS Client Subnet nicht (damit gibt er einen Teil der Spieleradresse weiter), werden Spieler mit Firmen-DNS oder weit entfernten DNS-Servern nach dem Standort des Resolvers zugewiesen. Auch Matchmaking-Systeme bewerten Gruppen teils nach dem durchschnittlichen Ping der Mitglieder oder lockern nach langer Wartezeit das Ping-Kriterium und weisen eine ferne Region zu. Bei AWS GameLift Servers ist der Durchschnitt ebenfalls das Standardkriterium für den Gruppen-Ping, und als Beispiel dient eine Konfiguration, die die Ping-Obergrenze schrittweise von 50 ms auf 100 ms und 200 ms anhebt. Bei Spielern mit VPN können sich die zusätzliche Latenz über den Relay-Server („Umweg über VPN oder Ping-Booster“) und die Zuweisung einer fernen Region überlagern. Unterscheiden lässt sich das daran, ob sich die zugewiesene Region ändert, wenn sie sich ohne VPN neu verbinden. Gibt es überhaupt keine nahe Region und verbindet man sich deshalb mit einer fernen, behandelt das „Signallaufzeit (physische Entfernung)“. - Quellen: - [RFC 7871: Client Subnet in DNS Queries](https://www.rfc-editor.org/rfc/rfc7871) · IETF · DNS, das je nach Standort unterschiedlich antwortet, schätzt den Standort anhand der Adresse des anfragenden Resolvers. Nutzt der Anwender einen weit entfernten zentralen Resolver, fallen die Antworten unpassend aus. EDNS Client Subnet (optional) gibt einen Teil der Nutzeradresse weiter - [How Amazon Route 53 uses EDNS0 to estimate the location of a user](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html) · AWS · Unterstützt der Resolver edns-client-subnet nicht, wird der Nutzerstandort anhand der Resolver-Adresse geschätzt und nach dem Standort des Resolvers geantwortet (gilt für geo- und latenzbasiertes Routing) - [Geolocation accuracy](https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy) · MaxMind · Länderebene etwa 99,8 %, US-Stadtebene (innerhalb von 50 km) etwa 66 %, bei VPN-Nutzung wird der Standort des VPN-Servers geliefert, Mobilfunk-IPs werden über große Gebiete genutzt und erlauben keinen genauen Standort, die Datenbank muss laufend aktualisiert werden, Korrekturanträge sind möglich - [FlexMatch rule types](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html) · AWS · Die Latenzregel (maxLatency) betrachtet die Spielerlatenz pro Standort, für Gruppen wird standardmäßig der Durchschnitt der Mitglieder verwendet (partyAggregation avg), die Queue kann auch in Regionen platzieren, die die Latenzregel nicht erfüllen - [Create a player latency policy](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/queues-design-latency.html) · AWS · Platzierung am Standort mit der niedrigsten durchschnittlichen Latenz aller Spieler, wobei auch Spieler mit extremer Latenz platziert werden, Beispiel für eine Richtlinie, die die Ping-Obergrenze von 50 ms auf 100 ms und 200 ms ausweitet - [Amazon GameLift Servers UDP ping beacons](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html) · AWS · Der Spielclient misst die Latenz zu UDP-Endpunkten an jedem Hosting-Standort und nutzt sie für Platzierung und Matchmaking, näher am echten Spiel-Traffic als ICMP-Ping - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Gemessene Median-RTT ab Seoul (Korea Central): Tokio (Japan East) 29 ms, US-Westküste 124–136 ms - [Flow log records](https://docs.aws.amazon.com/vpc/latest/userguide/flow-log-records.html) · AWS · srcaddr in Datensätzen der VPC Flow Logs: bei eingehendem Traffic die IP-Adresse des Absenders #### in-cert · Abgelaufenes oder falsch konfiguriertes TLS-Zertifikat · TLS certificate expiry / misconfiguration Läuft das Zertifikat eines Login-, API- oder Patchservers ab oder fehlt ein Zwischenzertifikat, scheitern ab diesem Moment die TLS-Verbindungen aller Clients, die sich neu verbinden. - Warum → Folge → Auf dem Bildschirm: Zertifikat abgelaufen, Server sendet das Zwischenzertifikat nicht mit, oder Datum und Uhrzeit auf dem Gerät des Spielers sind falsch → Client scheitert an der Zertifikatsprüfung und bricht die TLS-Verbindung ab → Kein Login / Endlos-Laden in der Login- oder Patchphase, nur HTTPS-Funktionen wie der Shop schlagen fehl. Bereits verbundene Spieler meist nicht betroffen - Symptome: Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback / Faktoren: Stillstand - Wer: Ganzer Server, Nur eine bestimmte Funktion, Nur ich / Wann: Direkt nach Login oder Wartung, Bei bestimmten Aktionen - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Zertifikatsfehler mit eigenem Fehlercode getrennt von anderen Verbindungsfehlern protokollieren und erklären, bei Datumsfehlern zum automatischen Stellen von Datum und Uhrzeit des Geräts auffordern, bei Certificate Pinning Backup-Keys mit einbauen und den Zeitplan für Zertifikatswechsel mit dem Infrastrukturteam abstimmen. - Aufgaben Infrastrukturteam: Netzwerk: Terminiert der Load-Balancer oder das CDN TLS, Status der automatischen Erneuerung verwalteter Zertifikate überwachen und auf die verbleibenden Tage alarmieren (bei ACM DaysToExpiry), DNS-Einträge für die Validierung erhalten. Server/OS: Terminiert der Server TLS, Erneuerung automatisieren und Konfiguration danach neu laden, Kette einschließlich Zwischenzertifikat konfigurieren, Restlaufzeit jeder Login-, API- und Patch-Adresse regelmäßig von außen prüfen und alarmieren. - Größenordnungen: Let’s-Encrypt-Zertifikate gelten 90 Tage, empfohlen wird eine Erneuerung alle 60 Tage. AWS Certificate Manager prüft per DNS validierte Zertifikate 45 Tage vor Ablauf und erneuert sie automatisch. Scheitert die automatische Erneuerung unbemerkt, werden genau zum Ablaufzeitpunkt alle neuen Verbindungen auf einmal blockiert. - Im Graphen: Verbindungen brechen gleichzeitig ab (Erfolgreiche Logins, TLS-Handshake-Fehler) - Wo nachsehen: Mit openssl s_client -connect HOST:443 -showcerts die Zertifikatsliste ansehen, die der Server tatsächlich sendet, und das Ablaufdatum (notAfter) jedes Zertifikats mit openssl x509 -noout -enddate prüfen. Terminiert der Load-Balancer TLS: Zahl der TLS-Aushandlungsfehler (bei AWS ALB und NLB ClientTLSNegotiationErrorCount) und erfolgreiche Logins - Spricht dafür: Ablaufdatum überschritten oder Zwischenzertifikat fehlt in der vom Server gesendeten Liste, und der Anstieg der Fehler beginnt zum Ablaufzeitpunkt oder zum Zeitpunkt des Zertifikatswechsels - Spricht dagegen: Zertifikatsliste und Ablaufdatum in Ordnung, nur einige Spieler scheitern: Datum und Uhrzeit auf deren Gerät oder die Root-Zertifikatsliste eines alten OS prüfen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Eine Konfiguration ohne Zwischenzertifikat kann im PC-Browser fehlerfrei wirken. Browser merken sich Zwischenzertifikate von anderen Websites und füllen die Lücke damit. Clients ohne einen solchen Speicher, etwa Android-Apps, scheitern. Auch die Laufzeiten werden kürzer. Let’s Encrypt will die Standardlaufzeit 2027 auf 64 Tage und 2028 auf 45 Tage verkürzen. Eine fest auf 60 Tage eingestellte Erneuerung lässt bei 64-Tage-Zertifikaten nur vier Tage Puffer und überschreitet bei 45-Tage-Zertifikaten den Ablauf. AWS Certificate Manager erneuert importierte Zertifikate nicht automatisch, und werden die DNS-Einträge für die Validierung gelöscht, scheitert die Erneuerung. Ein blockierter Login sieht ähnlich aus wie bei „DNS-Störung oder -Verzögerung“. Bei Zertifikatsproblemen wird die Serveradresse aber gefunden, und der Fehler tritt erst im TLS-Handshake auf. Außerdem fällt der Beginn mit dem Ablaufzeitpunkt oder dem Zeitpunkt des Zertifikatswechsels zusammen. - Quellen: - [RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://www.rfc-editor.org/rfc/rfc5280) · IETF · Ein Zertifikat gilt von notBefore bis notAfter, die Pfadvalidierung prüft für jedes Zertifikat der Kette, ob die aktuelle Zeit innerhalb der Gültigkeit liegt (geht die Uhr der prüfenden Seite falsch, scheitert sie) - [FAQ](https://letsencrypt.org/docs/faq/) · Let's Encrypt · Standardlaufzeit der Zertifikate 90 Tage, Erneuerung alle 60 Tage empfohlen - [Decreasing Certificate Lifetimes to 45 Days](https://letsencrypt.org/2025/12/02/from-90-to-45) · Let's Encrypt · Verkürzung der Standardlaufzeit im Februar 2027 auf 64 Tage und im Februar 2028 auf 45 Tage, eine Erneuerung im festen 60-Tage-Abstand reicht dann nicht mehr, empfohlen wird die Erneuerung nach etwa zwei Dritteln der Laufzeit - [Renewal for domains validated by DNS](https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html) · AWS · 45 Tage vor Ablauf wird geprüft, ob das Zertifikat in AWS-Diensten verwendet wird und der CNAME-Eintrag für die Validierung vorhanden ist, dann folgt die automatische Erneuerung. Gelingt die Validierung nicht, Benachrichtigung 30, 15, 7, 3 und 1 Tag vor Ablauf - [Managed certificate renewal in AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) · AWS · Importierte und bereits abgelaufene Zertifikate werden nicht automatisch erneuert - [Supported CloudWatch metrics](https://docs.aws.amazon.com/acm/latest/userguide/cloudwatch-metrics.html) · AWS · DaysToExpiry: verbleibende Tage bis zum Ablauf des Zertifikats, bis zum Ablauf zweimal täglich veröffentlicht - [Security with network protocols](https://developer.android.com/privacy-and-security/security-ssl) · Android (Google) · Sendet der Server das Zwischenzertifikat nicht mit, scheitern Android-Apps mit SSLHandshakeException. PC-Browser ergänzen es womöglich aus gespeicherten Zwischenzertifikaten und zeigen keinen Fehler. Die Kette des Servers mit openssl s_client prüfen - [Network security configuration](https://developer.android.com/privacy-and-security/security-config) · Android (Google) · Bei Certificate Pinning müssen für Schlüssel- und CA-Wechsel Backup-Keys mit eingebaut werden, sonst scheitern Verbindungen, bis die App aktualisiert ist - [openssl-s_client](https://docs.openssl.org/3.0/man1/openssl-s_client/) · OpenSSL · -showcerts: zeigt die vom Server gesendete Zertifikatsliste in der gesendeten Reihenfolge (keine validierte Kette) - [openssl-x509](https://docs.openssl.org/3.0/man1/openssl-x509/) · OpenSSL · -enddate: gibt das Ablaufdatum (notAfter) aus, -checkend: prüft, ob das Zertifikat innerhalb der angegebenen Sekunden abläuft - [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) · AWS · ClientTLSNegotiationErrorCount: Zahl der Verbindungen, bei denen keine TLS-Session zustande kam, etwa weil der Client die Prüfung des Serverzertifikats nicht bestanden und die Verbindung abgebrochen hat - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · ClientTLSNegotiationErrorCount: Zahl der TLS-Handshakes zwischen Client und TLS-Listener, bei denen die Aushandlung scheiterte #### in-login-queue · Obergrenze der Login-Warteschlange und zu kurze Reconnect-Karenzzeit · Login queue cap / no reconnect grace Strömen nach Release oder Wartung viele Spieler herein, erreicht die Login-Warteschlange ihre Obergrenze und weist neue Wartende ab. Wer schon wartet, verliert bei einem kurzen Verbindungsabbruch seinen Platz und muss sich wieder hinten anstellen. - Warum → Folge → Auf dem Bildschirm: Mehr Spieler wollen sich verbinden, als der Login-Server auf einmal aufnehmen kann, daher eine Warteschlange, und wird sie zu lang, werden zum Schutz des Servers neue Wartende abgewiesen → Je länger die Warteschlange, desto länger die Wartezeit, und schon ein kurzer WLAN- oder Mobilfunkaussetzer kostet in dieser Zeit den Platz → Kein Login / Endlos-Laden, Spiel beendet sich während des Wartens mit Fehler, erneutes Warten ganz hinten - Symptome: Kein Login / Endlos-Laden, Verbindungsabbruch / Faktoren: Stillstand - Wer: Ganzer Server, Nur ich / Wann: Direkt nach Login oder Wartung, Abendliche Stoßzeit - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Server: Obergrenze der Warteschlange an die tatsächliche Verarbeitungskapazität des Login-Servers anpassen, den Platz von Spielern mit Verbindungsabbruch während des Wartens eine gewisse Zeit freihalten (Reconnect-Karenzzeit), Position und voraussichtliche Wartezeit anzeigen, Länge der Warteschlange, Abweisungen und Abbrüche während des Wartens als Metriken erfassen. Client: bei Abbruch während des Wartens das Spiel offen lassen und automatisch auf denselben Platz neu verbinden, Retry-Abstände per exponentiellem Backoff und Jitter streuen. - Aufgaben Infrastrukturteam: Server/OS: vor dem Release per Lasttest die Kapazitätsgrenze der Login- und Lobby-Server messen, für den Release Reservemaschinen vorbereiten, die sich schnell hinzufügen lassen, Warteschlangen-Metriken im selben Graphen wie die Verbindungsversuche darstellen. - Größenordnungen: Beim Release einer Erweiterung von FINAL FANTASY XIV im Jahr 2021 wurden neue Wartende abgewiesen, sobald pro logischem Datenzentrum mehr als 17.000 Spieler warteten (Error 2002). Brach die Verbindung während des Wartens ab, wartete der Lobby-Server einige Dutzend Sekunden bis 1 Minute. Wer sich in dieser Zeit wieder verband, behielt seinen Platz in der Warteschlange. - Im Graphen: Plateau am Limit (Länge der Login-Warteschlange, Abweisungen wegen erreichter Obergrenze, Abbrüche während des Wartens) - Wo nachsehen: Länge der Warteschlange, durchschnittliche Wartezeit, Abweisungen wegen erreichter Obergrenze und Abbrüche während des Wartens aus Login- und Lobby-Server im selben Graphen wie die Verbindungsversuche darstellen - Spricht dafür: Nach Release oder Wartung erreicht die Warteschlangenlänge die Obergrenze und bleibt flach, währenddessen steigen die Abweisungen, und Abbrüche während des Wartens häufen sich bei Spielern mit WLAN oder Mobilfunk - Spricht dagegen: Warteschlange kurz, Login trotzdem langsam: eher DB (db-login-storm) oder Verbindungswarteschlange des Betriebssystems (so-backlog) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Wird die DB durch den Login-Ansturm langsam, behandelt das „Login-Ansturm und N+1-Queries“. Läuft die Verbindungswarteschlange des Betriebssystems über, behandelt das „Überlauf der Verbindungswarteschlange (Backlog)“. Dieser Eintrag betrifft das Design der Login-Warteschlange, die das Spiel bewusst vorschaltet. Die Obergrenze der Warteschlange ist eine Schutzvorrichtung für den Login-Server und lässt sich nicht abschaffen. Nur wenn überzählige Anfragen früh abgewiesen werden, können die übrigen weiter bearbeitet werden. Entscheidend ist deshalb, den Schaden für die Spieler durch Abweisung und Verbindungsabbruch gering zu halten. Je länger die Warteschlange wird, desto stärker treffen die Fehler Spieler mit instabiler Leitung wie WLAN oder Mobilfunk. - Reale Fälle: ffxiv-2021 - Quellen: - [Response to Congestion (as of Dec. 11)](https://na.finalfantasyxiv.com/lodestone/news/detail/6a94b30182b6d963994fdc0b789264ac9f24986f) · Square Enix · Über 17.000 Wartende pro logischem Datenzentrum: Neue Wartende werden abgewiesen, damit der Login-Server nicht abstürzt (Error 2002). Bei Abbruch während des Wartens wartet der Lobby-Server einige Dutzend Sekunden bis 1 Minute. Wer sich darin wieder verbindet, behält seinen Platz, danach geht es ganz hinten weiter - [Using load shedding to avoid overload](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/) · Amazon Builders' Library · Load Shedding: überzählige Anfragen früh abweisen, damit bearbeitbare Anfragen weiter bearbeitet werden ### Synchronisationsdesign (16 Ursachen) #### sy-request-response · Feedback erst nach der Serverantwort (Request-Response) · Request-response (no client-side feedback) Nach einem Tastendruck gibt es weder Animation noch Ton, bis die Antwort des Servers eintrifft. Der Ping bestimmt direkt die Reaktionszeit. - Warum → Folge → Auf dem Bildschirm: Skills, Bewegung und Aufheben erst nach Bestätigung durch den Server abgespielt → Ab dem Tastendruck keinerlei Reaktion für die Dauer von Round Trip + Tick-Wartezeit → Bei 150 ms Ping wirkt jede Aktion um 0,2 s träge - Symptome: Input-Lag / Faktoren: Latenz - Wer: Nur ich / Wann: Immer, Bei bestimmten Aktionen - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Animation, Ton und Effekte sofort beim Tastendruck starten (clientseitiges Feedback), nur Ergebnisse (Schaden, Belohnungen) nach Bestätigung durch den Server anzeigen, Bewegung und Standardangriffe vorhersagen und sofort umsetzen, nach einer Positionskorrektur des Servers die noch unbestätigten Eingaben ab dieser Position erneut anwenden. Server: Bewegung aus den empfangenen Eingaben selbst berechnen und Korrekturwerte nur senden, wenn die Abweichung von der vom Client vorhergesagten Position einen Schwellenwert überschreitet. - Größenordnungen: Reaktionszeit ≈ Ping + halbes Tick-Intervall + ein Frame. Bei 20 Ticks pro Sekunde und 150 ms Ping etwa 190 ms. - Im Graphen: Von Anfang an dauerhaft hoch (Zeit von der Eingabe bis zum Start des Feedbacks, RTT (Ping)) - Wo nachsehen: Im Client-Log eines Entwicklungs-Builds Zeitpunkt des Tastendrucks, Start der ersten Animation bzw. des ersten Tons und Ankunft der Serverantwort protokollieren und neben die RTT im Spiel legen. Mit der Netzwerkemulation der Engine (Unreal NetEmulation.PktLag) oder mit Linux tc netem auf dem Testserver Latenz hinzufügen und bei unterschiedlichem Ping messen - Spricht dafür: Feedback startet immer genau mit dem Eintreffen der Serverantwort, die Zeit von der Eingabe bis zum Feedback entspricht RTT + Tick-Wartezeit und wächst genau um die hinzugefügte Latenz - Spricht dagegen: Feedback startet sofort beim Tastendruck, nur Ergebnisse wie Schadenszahlen kommen später: korrektes Design. Auch bei niedrigem Ping mehr als ein Tick-Intervall Verzögerung: „Doppeltes Warten auf den Tick“ oder Frame-Probleme im Client - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Für Spiele, die keine schnelle Reaktion brauchen, etwa rundenbasierte Spiele, Kartenspiele oder Idle-Games, ist dieses Verfahren am einfachsten und sichersten. Problematisch wird es, wenn ein Spiel mit Echtzeitsteuerung auch Bewegung und Standardangriffe so umsetzt. - Quellen: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Ein Client, der nur auf Serverergebnisse wartet, zeigt bei 500 ms Latenz jede Aktion erst 500 ms später. Abhilfe durch clientseitige Vorhersage und Serverabgleich - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Local Predicted führt sofort beim Tastendruck aus, die endgültige Entscheidung trifft der Server. Server Initiated hat keine Vorhersage, der ausführende Spieler sieht die Latenz - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Der Client sagt Bewegungen voraus und speichert sie. Der Server korrigiert nur, wenn die Abweichung den Grenzwert (MAXPOSITIONERRORSQUARED) überschreitet, danach wendet der Client die gespeicherten Bewegungen erneut an - [Using Network Emulation in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-network-emulation-in-unreal-engine) · Epic Games · Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar - [tc-netem(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-netem.8.html) · iproute2 · Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden #### sy-chatty · Protokoll mit vielen aufeinanderfolgenden Round Trips (chatty) · Chatty protocol / sequential round trips Braucht eine einzige Aktion mehrere Round Trips zum Server nacheinander, vervielfacht sich der Ping um deren Anzahl. - Warum → Folge → Auf dem Bildschirm: Shop öffnen → Liste anfordern → Preis prüfen → kaufen → Inventar aktualisieren, jeweils als eigene Anfrage → Nächste Anfrage erst nach der Antwort auf die vorige → Bei 150 ms Ping dauert ein Kauf fast 1 s. Ladezeiten auffällig lang - Symptome: Input-Lag, Kein Login / Endlos-Laden / Faktoren: Latenz - Wer: Nur eine bestimmte Funktion, Nur ich / Wann: Bei bestimmten Aktionen, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Protokoll so ändern, dass mehrere Schritte in einer Anfrage und einer Antwort gebündelt werden (z. B. das aktualisierte Inventar gleich in die Kaufantwort packen). Client: benötigte Daten vorab laden, UI, die nicht auf das Ergebnis wartet. - Größenordnungen: Dauer ≈ Anzahl der Round Trips × (Ping + Serververarbeitung + Tick-Wartezeit). Bei 5 Round Trips und 150 ms Ping etwa 0,85–1 s. - Im Graphen: Von Anfang an dauerhaft hoch (Abschlusszeit pro Funktion, Round Trips pro Aktion) - Wo nachsehen: In einem serverseitigen Paketmitschnitt (Wireshark) zählen, wie oft Anfragen und Antworten abwechselnd hin- und hergehen, während ein Testaccount eine Aktion wie einen Shop-Kauf oder einen Login einmal ausführt, und die Abstände messen. Gibt es ein Request-Log auf dem Server, nach Session-ID gruppieren und Anzahl der Anfragen sowie Ankunfts- und Antwortzeit jeder Anfrage prüfen - Spricht dafür: Pro Aktion mehrere Anfragen nacheinander, jede wartet auf die vorige Antwort, Abschlusszeit etwa Round Trips × RTT, und dieselbe Funktion ist für Spieler aus Regionen mit höherem Ping proportional langsamer - Spricht dagegen: Nur ein, zwei Round Trips, aber eine einzelne Antwort dauert lange: Ursache bei Serververarbeitung oder DB. Alle Spieler unabhängig vom Ping gleich langsam: Serverlast prüfen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Chatty I/O antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/chatty-io/) · Microsoft Azure · Viele kleine I/O-Anfragen summieren sich zu einer Latenz, die die Reaktionsfähigkeit stark verschlechtert. Empfehlung: Anfragen zu weniger, größeren bündeln #### sy-no-queue · Kein Input-Buffering für Skills · No input/spell queue Lässt sich der nächste Skill erst auslösen, wenn der Server das Ende des vorigen bestätigt hat, schiebt sich zwischen alle Skills einer Kombo ein Round Trip. - Warum → Folge → Auf dem Bildschirm: Nächster Skill-Input wird erst „nach Bestätigung des vorigen Skills“ angenommen → Zwischen zwei Skills jeweils eine Lücke in Höhe des Pings → Lücken in jeder Kombo, je höher der Ping, desto weniger DPS - Symptome: Input-Lag, Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur ich, Nur eine bestimmte Funktion / Wann: Bei bestimmten Aktionen - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Zeitfenster fürs Input-Buffering, das Eingaben auch in einer bestimmten Zeit vor Ende des Cooldowns (z. B. 0,3–0,4 s) annimmt und sofort an den Server schickt. Server: etwas zu früh eintreffende Eingaben nicht ablehnen und genau bei Ende des Cooldowns ausführen. - Größenordnungen: Bei einer Kombo mit 1 s Cooldown und 150 ms Ping bleibt zwischen den Skills jeweils mindestens 0,15 s leer. In derselben Zeit lassen sich über 13 % weniger Skills einsetzen. - Im Graphen: Von Anfang an dauerhaft hoch (Lücke zwischen Skills, RTT (Ping)) - Wo nachsehen: Im Server-Log pro Charakter Ende des Skill-Cooldowns, Ankunft der nächsten Skill-Anfrage und Ausführungszeitpunkt protokollieren und die Lücke dazwischen mit der RTT des Spielers vergleichen - Spricht dafür: Zwischen Ende des Cooldowns und Ausführung des nächsten Skills liegt immer etwa eine RTT, je höher der Ping, desto länger die Lücke und desto weniger Skills in derselben Zeit - Spricht dagegen: Lücke unabhängig vom Ping konstant: Design von globalem Cooldown oder Animationslänge. Lücke schlägt nur gelegentlich stark aus: Jitter, Paketverlust oder „Überschrittenes Tick-Budget“ prüfen - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: World of Warcraft zum Beispiel hat ein Zeitfenster fürs Input-Buffering, das Spieler in den Einstellungen anpassen können. Ist das Zeitfenster länger als der Round Trip, schiebt sich kaum noch Ping zwischen die Skills einer Kombo. - Quellen: - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · In EverQuest 2 sinkt mit steigender Latenz der Schaden, den ein Charakter austeilt, und Kämpfe dauern länger (bei 0→500 ms etwa 5 s mehr bei einem Kampf von rund 2 Minuten) #### sy-short-window · Kurze Zeitfenster, die der Ping aufzehrt · Timing window too short for latency + reaction Ist die Reaktionszeit für Ausweichen, Parieren oder Blocken kurz, zehrt der Ping sie auf, und manche Angriffe lassen sich gar nicht mehr vermeiden. - Warum → Folge → Auf dem Bildschirm: Kurze Zeitfenster wie 0,5 s Vorwarnung vor einem Bossangriff oder 0,2 s Parier-Zeitfenster → Vorwarnung kommt spät an (Latenz Server→Client + Interpolation), die eigene Eingabe ebenfalls (Latenz Client→Server + Tick-Wartezeit) → Eindeutig ausgewichen und trotzdem getroffen, Parade wird verschluckt - Symptome: Verschluckte Aktion / Rollback, Input-Lag / Faktoren: Latenz - Wer: Nur ich, Nur eine bestimmte Funktion / Wann: Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Server: Vorwarnungen für Angriffe mit Serverzeit vorab einplanen und früh senden, Zeitfenster um den Ping verlängern (Lag-Compensation). Client: empfangene Vorwarnungen zur eingeplanten Serverzeit abspielen. - Aufgaben Infrastrukturteam: Server nahe an Regionen mit vielen Spielern platzieren (regionale Server), um den Ping selbst zu senken. - Größenordnungen: Bei 150 ms Ping und 100 ms Interpolation dauert es etwa 0,18 s, bis die Vorwarnung auf dem eigenen Bildschirm erscheint, und etwa 0,1 s, bis die eigene Eingabe beim Server ankommt. Mit 0,25 s menschlicher Reaktionszeit ist eine Vorwarnung von 0,5 s kaum noch zu schaffen. - Im Graphen: Nur einzelne Ausreißer (Fehlerquote beim Ausweichen und Parieren (nach Ping-Bereich)) - Wo nachsehen: Im Server-Log Beginn und Ende des Zeitfensters, Ankunft der Spielereingabe am Server und RTT des Spielers protokollieren, Fehlerquote nach Ping-Bereichen (z. B. in 50-ms-Schritten) aufschlüsseln - Spricht dafür: Je höher der Ping-Bereich, desto deutlich höher die Fehlerquote, und fehlgeschlagene Eingaben treffen kurz nach Ende des Zeitfensters ein (innerhalb von RTT plus Interpolationszeit) - Spricht dagegen: Fehlerquote in allen Ping-Bereichen ähnlich: Schwierigkeit des Angriffsmusters. Eingabe trifft innerhalb des Zeitfensters ein und zählt trotzdem als Fehlschlag: Code der Trefferabfrage oder Servervalidierung prüfen - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Einfache Reaktionszeit im Mittel etwa 231 ms (213 ms nach Korrektur der Gerätelatenz), neuere große Studien 233–400 ms - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Je präziser eine Aktion und je kürzer ihre Frist, desto latenzempfindlicher (Grenze bei etwa 100 ms in der Ego-Perspektive, etwa 500 ms in der Third-Person-Perspektive, etwa 1.000 ms in der Gottperspektive) - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Verfahren, bei dem Events zur Serverzeit (ServerTime) eingeplant werden, damit alle Clients sie im selben Moment abspielen #### sy-no-lagcomp · Trefferabfrage ohne Lag-Compensation · Server-now hit validation Prüft der Server Treffer nur gegen die „aktuelle Position auf dem Server“, weicht die Trefferabfrage von dem ab, was man auf dem eigenen Bildschirm gesehen hat. - Warum → Folge → Auf dem Bildschirm: Gegner auf dem eigenen Bildschirm an seiner Position von vor etwa 0,2 s (bei 150 ms Ping und 100 ms Interpolation) → Server prüft gegen die aktuelle Position, an der anvisierten Stelle ist der Gegner schon weg → Eindeutig getroffen und trotzdem daneben. Auf bewegte Ziele muss man vorhalten - Symptome: Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur ich / Wann: Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: auf den Zeitpunkt zurückspulen, den der Angreifer gesehen hat, und dann prüfen (Lag-Compensation), oder auf Zielauswahl (Tab-Targeting) umstellen. Client: beim Angriff den selbst gesehenen Zeitpunkt (die gerade interpolierte Serverzeit) mitschicken. - Im Graphen: Nur einzelne Ausreißer (Trefferquote auf bewegte Ziele (nach Ping-Bereich)) - Wo nachsehen: Im Log der Trefferabfrage auf dem Server Angriffszeitpunkt, Zielposition auf dem Bildschirm des Angreifers (vom Client gemeldeter Wert), für die Trefferabfrage verwendete Zielposition auf dem Server und RTT des Angreifers gemeinsam protokollieren. Zeichnet ein Entwicklungs-Build die vom Server verwendete Position über das Client-Bild, ist es sofort zu sehen - Spricht dafür: Bei Fehlschüssen beträgt der Abstand der beiden Positionen etwa Zielgeschwindigkeit × (RTT des Angreifers + Interpolationszeit), und mit steigendem Ping sinkt nur die Trefferquote auf bewegte Ziele - Spricht dagegen: Auch stehende Ziele werden verfehlt: Problem mit Hitbox oder Kollisionsprüfung. Abweichung trotz Zurückspulen: prüfen, ob der Client dem Server eine falsche Interpolationszeit meldet - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Ohne Lag-Compensation muss man um die Latenz vorhalten. Bei der Lag-Compensation spult der Server um Latenz und Interpolationszeit zurück und prüft dann den Treffer - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Der Server spult für die Trefferabfrage auf den Spielzustand zurück, den der Spieler im Moment des Schusses gesehen hat, der Client schickt die gesehene Simulationszeit mit - [Source SDK 2013: player_lagcompensation.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player_lagcompensation.cpp) · Valve · Zurückgespulte Zeit in der Source-Engine = Netzwerklatenz + Interpolationszeit #### sy-lagcomp-overreach · Übermäßige Lag-Compensation · Excessive lag compensation Spult der Server für den Angreifer zu weit zurück, wird der Getroffene noch erwischt, obwohl er schon in Deckung ist. - Warum → Folge → Auf dem Bildschirm: Server spult für Angreifer mit hohem Ping weit zurück und prüft dann → Auf dem Bildschirm des Getroffenen ist er bereits in Deckung → „Hinter der Wand getroffen“, Spieler mit hohem Ping im Vorteil - Symptome: Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Nur ich, Bestimmte Region oder Provider / Wann: Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Obergrenze fürs Zurückspulen festlegen (z. B. 200–250 ms), bei Angreifern mit höherem Ping nur bis zur Grenze zurückspulen und den Rest selbst vorhalten lassen. - Im Graphen: Nur einzelne Ausreißer (Zurückgespulte Zeit pro Treffer (nach Ping des Angreifers)) - Wo nachsehen: Im Log der Trefferabfrage auf dem Server pro Treffer zurückgespulte Zeit, RTT des Angreifers und Serverzeitpunkt protokollieren, zu dem der Getroffene in Deckung gegangen ist. In einem Entwicklungs-Build die zurückgespulten Hitboxen auf dem Bildschirm anzeigen (Source-Engine: sv_showlagcompensation) - Spricht dafür: Treffer aus Meldungen „hinter der Wand getroffen“ häufen sich bei Angreifern mit langer Zurückspulzeit, und die zurückgespulte Zeit wächst ohne Obergrenze mit dem Ping des Angreifers - Spricht dagegen: Treffer hinter der Wand auch bei kurzer Zurückspulzeit: Problem mit Hitbox oder Kollisionsprüfung. Hat der Getroffene hohen Ping, kam seine Bewegung zu spät beim Server an - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Die Trefferabfrage mit Zurückspulen folgt dem Prinzip „Vorrang für den Schützen“. Vorgeschlagen ist auch eine Ausnahme mit „Vorrang für den Getroffenen“: Ist der Getroffene auf seinem Bildschirm schon in Sicherheit, wird nicht zurückgespult. - Quellen: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Ohne Grenze fürs Zurückspulen könnte jemand mit 500 ms Latenz noch 0,5 s nach dem Gang in Deckung treffen, daher die Grenze - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Phänomen „hinter der Ecke getroffen“ (shot around the corner), Zurückspulgrenzen kommerzieller FPS, Vorschlag, nicht zurückzuspulen, wenn der Getroffene in Sicherheit ist - [Source SDK 2013: player_lagcompensation.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player_lagcompensation.cpp) · Valve · Zurückspulgrenze der Source-Engine sv_maxunlag, Standard 1 s (Maximum 1 s), sv_showlagcompensation zeigt die zurückgespulten Hitboxen auf dem Bildschirm an #### sy-client-auth · Client-Autorität · Client-authoritative results Entscheidet jeder Client selbst über seine Ergebnisse, läuft es auf dem eigenen Bildschirm flüssig. Die Ergebnisse weichen aber von denen auf anderen Bildschirmen ab, und das System ist anfällig für Cheats. - Warum → Folge → Auf dem Bildschirm: Position und Treffer legt der Client fest, der Server leitet nur weiter → Zwei Spieler behaupten beide, zuerst getroffen zu haben, der Server kann es nicht prüfen → Gegner teleportiert oder läuft durch Wände, „Ich habe getroffen, aber es zählt nicht“ - Symptome: Teleportieren, Verschluckte Aktion / Rollback / Faktoren: Latenz - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: wichtige Ergebnisse (Treffer usw.) selbst prüfen, Bewegung auf Geschwindigkeit und Distanz prüfen. Client: vom Server abgelehnte oder korrigierte Ergebnisse auf den Serverwert zurücksetzen. - Im Graphen: Von Anfang an dauerhaft hoch (Anzahl unmöglicher Bewegungsgeschwindigkeiten und widersprüchlicher Treffermeldungen) - Wo nachsehen: Auf dem Server die vom Client gemeldeten Positionen und Treffer unverändert aufzeichnen, aus aufeinanderfolgenden Positionsmeldungen die Bewegungsgeschwindigkeit berechnen und Meldungen über der Höchstgeschwindigkeit sowie Fälle zählen, in denen zwei Spieler beide melden, zuerst getroffen zu haben - Spricht dafür: Server leitet Meldungen ungeprüft an andere Clients weiter, und unmögliche Geschwindigkeiten oder widersprüchliche Treffermeldungen treten unabhängig von Patch und Region stetig auf - Spricht dagegen: Berechnet oder prüft der Server die Ergebnisse selbst, ist es nicht diese Ursache. Teleportieren hat dann eher mit Paketverlust oder dem Interpolationspuffer zu tun - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Lässt man den Client Ergebnisse melden, geht das nur, wenn man dem Client vertrauen kann. Wegen Cheats setzt man auf einen autoritativen Server - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Modell mit Server-Autorität: Der Server vertraut nie dem Spielzustand, den der Client gesehen hat - [Distributed authority topologies (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/distributed-authority.html) · Unity · Wird die Autorität auf Clients verteilt, wird Cheaten leichter, und es gibt keine einzelne Simulation mehr, die alle Objekte steuert #### sy-lockstep · Warten auf den langsamsten Spieler im Lockstep · Lockstep waits for the slowest peer Berechnen alle gemeinsam denselben Zug, müssen alle warten, sobald die Eingabe eines Einzelnen zu spät kommt. - Warum → Folge → Auf dem Bildschirm: Berechnung eines Zugs erst möglich, wenn die Eingaben aller Spieler da sind → Eingabe eines Spielers kommt durch Jitter oder Paketverlust zu spät → Alle stocken gleichzeitig, im schlimmsten Fall erscheint das Fenster „Warte auf Spieler“ - Symptome: Freeze, Ruckeln, Input-Lag / Faktoren: Jitter, Paketverlust, Stillstand - Wer: Bestimmter Ort oder Kanal / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Input-Delay automatisch an den Ping anpassen, nur den Nachzügler kurz abkoppeln, damit die anderen ohne Warten weiterspielen. Client: festgelegtes Input-Delay anwenden, bei P2P ohne Relay-Server übernimmt der Host-Client auch die Anpassung des Input-Delays und den Umgang mit Nachzüglern. - Größenordnungen: Ist das Input-Delay kürzer als „Zeit, bis die Eingabe beim Gegenüber ankommt, + Jitter“, stockt das Spiel häufiger. Diese Zeit beträgt bei direktem Austausch den halben Ping, über einen Relay-Server etwa die Hälfte der Summe beider Pings. - Im Graphen: Vereinzelte Spitzen ohne Muster (Wartezeit pro Zug, Ankunftsverzögerung der Eingaben pro Spieler) - Wo nachsehen: Pro Zug die Ankunftszeit der Eingaben jedes Spielers und die Wartezeit des Zugs protokollieren und bei angehaltenen Zügen prüfen, auf wessen Eingabe gewartet wurde. Mit Relay-Server ist das auch im serverseitigen Paketmitschnitt an den Ankunftsabständen der Eingabepakete pro Spieler zu sehen - Spricht dafür: Bei jedem angehaltenen Zug kam die Eingabe derselben Person erst nach Ablauf des Input-Delays an, und genau dann schlagen Jitter oder Paketverlust dieser Person aus - Spricht dagegen: Alle Eingaben pünktlich da und trotzdem Stillstand: Rechenzeit des langsamsten PCs oder Serververarbeitung. Kein Stillstand, aber unterschiedliche Ergebnisse auf zwei Bildschirmen: auseinanderlaufende Berechnung (Desync), also „Abweichende Pfadberechnung bei Befehlssynchronisation“ prüfen - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Frame n lässt sich erst berechnen, wenn alle Eingaben da sind, sonst wird gewartet. Ist der Playout-Puffer, der Jitter abfängt, zu klein, stockt es - [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) · Game Developer · Befehle werden zur Ausführung zwei Züge später eingeplant, die Zuglänge passt sich an den langsamsten Rechner und den Ping an (Speed Control) - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Input-Delay (incoming delay) in Höhe der Latenz „A→Server + Server→B“, damit alle die Eingaben im selben Moment anwenden #### sy-rollback · Fehlvorhersagen beim Rollback-Netcode · Rollback misprediction Die Eingabe des Gegners wird vorhergesagt und vorab angezeigt. Liegt die Vorhersage falsch, wird zurückgespult und neu berechnet. Je höher der Ping, desto weiter wird zurückgespult. - Warum → Folge → Auf dem Bildschirm: Gegner ändert seine Eingabe (anders als vorhergesagt) → Tatsächliche Eingabe kommt um den halben Ping später an, entsprechend weit wird zurückgespult und neu berechnet → Bewegungen des Gegners überspringen einige Frames oder ändern sich abrupt - Symptome: Teleportieren / Faktoren: Latenz, Jitter - Wer: Nur ich / Wann: Bei bestimmten Aktionen, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: 1–3 Frames Input-Delay beimischen, um die Rollback-Weite zu senken, Obergrenze fürs Zurückspulen festlegen. - Größenordnungen: Bei 100 ms Ping (50 ms pro Richtung) werden bei 60 FPS etwa 3 Frames zurückgespult. Mit 2 Frames Input-Delay sinkt das auf 1 Frame. - Im Graphen: Vereinzelte Spitzen ohne Muster (Zurückgespulte Frames, RTT (Ping)) - Wo nachsehen: Im Client bei jedem Rollback Anzahl der zurückgespulten Frames, RTT zu diesem Zeitpunkt, eingestelltes Input-Delay und Dauer von Zurückspulen und Neuberechnung protokollieren - Spricht dafür: In den Momenten, in denen die Bewegungen des Gegners gesprungen sein sollen, ist die Zahl der zurückgespulten Frames hoch, die mittlere Rollback-Weite liegt etwa bei (Latenz pro Richtung − Input-Delay) ÷ Frametime und wächst mit dem Ping - Spricht dagegen: Ruckeln trotz geringer Rollback-Weite: Leistungsproblem, die Neuberechnung dauert länger als ein Frame. Ergebnisse auf beiden Bildschirmen bleiben auch nach dem Zurückspulen unterschiedlich: auseinanderlaufende Berechnung (Desync) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [GGPO Rollback Networking SDK](https://www.ggpo.net/) · GGPO · Die Eingabe des Gegners wird vorhergesagt und vorab weitergerechnet. Weicht die tatsächliche Eingabe ab, wird vom Zeitpunkt der Abweichung bis jetzt neu berechnet - [8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2'](https://www.gdcvault.com/play/1025471/8-Frames-in-16ms-Rollback) · GDC · Rollback beseitigt das lokale Input-Delay des Lockstep, bis zu 8 Frames werden innerhalb von 16 ms zurückgespult und neu berechnet #### sy-no-timestamp · Wiedergabe bei Ankunft ohne Zeitstempel · Events played on arrival (no timestamps) Bekommen Server-Events keinen Entstehungszeitpunkt und werden sofort bei Ankunft abgespielt, überträgt sich der Netzwerk-Jitter direkt auf das Timing der Darstellung. - Warum → Folge → Auf dem Bildschirm: Events wie „Angriff beginnt“ oder „Effekt abspielen“ sofort bei Ankunft ausgeführt → Jedes Paket kommt zu einer anderen Zeit an, Abstände unregelmäßig → Angriffsketten mal schneller, mal langsamer, Timing der Bossmuster jedes Mal anders - Symptome: Ruckeln, Zeitraffer / Faktoren: Jitter - Wer: Nur ich / Wann: Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: Events zum mitgelieferten Zeitpunkt abspielen (zeitgeplante Events, Interpolationspuffer). Server: Events mit dem Entstehungszeitpunkt (Serverzeit) versehen und senden. - Im Graphen: Vereinzelte Spitzen ohne Muster (Abstand der Event-Wiedergabe, Ankunftsabstand der Pakete) - Wo nachsehen: Entstehungszeitpunkt der Events im Server-Log und Ankunfts- und Wiedergabezeitpunkt im Client-Log über die Event-Nummer zuordnen und die Abstände vergleichen. In einem Entwicklungs-Build mit hinzugefügtem Jitter nachstellen (Jitter-Wert von tc netem, minimale und maximale Latenz der Unreal-Netzwerkemulation) - Spricht dafür: Entstehungsabstände auf dem Server gleichmäßig, Wiedergabeabstände folgen unverändert den unregelmäßigen Ankunftsabständen - Spricht dagegen: Ankunftsabstände gleichmäßig, aber Wiedergabe unregelmäßig: Frame-Problem im Client („Frametime-Spikes“). Schon die Entstehungsabstände auf dem Server schwanken: „Überschrittenes Tick-Budget“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Jedes Update bekommt die Serverzeit, gezeichnet wird die Position zur Zielzeit, also aktuelle Zeit minus Interpolationszeit (100 ms) - [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/) · Gaffer On Games · Empfangene Snapshots sofort zu zeichnen, ruckelt wegen Jitter. Sammelt man sie kurz im Interpolationspuffer und zeichnet dann, wird die Darstellung flüssig - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Beispiel, in dem ein RPC den Sendezeitpunkt mitführt und die Empfangsseite den Effekt passend zur Serverzeit abspielt - [tc-netem(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-netem.8.html) · iproute2 · Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden - [Using Network Emulation in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-network-emulation-in-unreal-engine) · Epic Games · Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar #### sy-double-tick · Doppeltes Warten auf den Tick · Double tick quantization Werden Anfragen bis zum nächsten Tick gesammelt und erst dann verarbeitet, und geht auch das Ergebnis erst im darauffolgenden Tick hinaus, kommt das Tick-Intervall zweimal hinzu. - Warum → Folge → Auf dem Bildschirm: Empfangene Anfrage wird im nächsten Tick verarbeitet → Auch das Ergebnis wird für den nächsten Sende-Tick gesammelt und dann verschickt → Leitungs-Ping niedrig, aber Reaktion konstant um etwa das 1,5-Fache des Tick-Intervalls verzögert. Bei 10 Ticks pro Sekunde im Mittel 0,15 s, schlimmstenfalls 0,2 s - Symptome: Input-Lag / Faktoren: Latenz - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Antwort im selben Tick senden, in dem verarbeitet wurde, Tickrate erhöhen, wichtige Antworten sofort senden. - Größenordnungen: Bei 10 Ticks pro Sekunde dauert ein Tick 100 ms, allein durch das Warten auf Ticks kommen im Mittel 150 ms und schlimmstenfalls 200 ms hinzu. Bei nur einmaligem Warten sind es im Mittel 50 ms. - Im Graphen: Von Anfang an dauerhaft hoch (Zeit von Ankunft der Anfrage bis zum Senden der Antwort) - Wo nachsehen: Im serverseitigen Paketmitschnitt den Abstand zwischen Ankunft des Anfragepakets und Abgang des Antwortpakets messen, während ein Testaccount dieselbe Aktion (z. B. ein Item benutzen) mehrmals ausführt. Gibt es ein Server-Log, Ankunftszeit der Anfrage, Nummer des verarbeitenden Ticks und Sendezeit der Antwort prüfen - Spricht dafür: Verweildauer im Server im Mittel etwa das 1,5-Fache des Tick-Intervalls, maximal etwa das Doppelte, und unabhängig von der RTT konstant - Spricht dagegen: Verweildauer im Server im Mittel um die Hälfte des Tick-Intervalls: nur einmaliges Warten auf den Tick. Unregelmäßig länger als das Tick-Intervall: „Überschrittenes Tick-Budget“ prüfen - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Eine eingetroffene Eingabe wartet bis zu einen Tick auf die nächste Tick-Grenze, Anwenden und Senden kosten noch einmal einen Frame. Je höher die Tickrate, desto geringer - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Ein Teil der Latenz kommt aus dem Netzwerk, ein Teil aus der Tickrate des Servers - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Änderungen an NetworkVariable werden bis zum nächsten Netzwerk-Tick gesammelt und dann gemeinsam gesendet #### sy-strict-check · Zu strenge Servervalidierung · Over-strict server validation Prüft der Server Bewegungsgeschwindigkeit, Cooldowns und Reichweite zu streng, lehnt er auch normale Eingaben ab, die durch Jitter gebündelt ankommen. - Warum → Folge → Auf dem Bildschirm: Strenge Kriterien wie „maximal zurücklegbare Strecke pro Tick“ oder „0 ms Toleranz beim Cooldown“ → Kommen durch Jitter zwei Befehle im selben Tick an, wird das als Regelverstoß gewertet → Rubberbanding, Skill wird trotz abgelaufenem Cooldown abgelehnt - Symptome: Rubberbanding, Verschluckte Aktion / Rollback / Faktoren: Jitter - Wer: Nur ich / Wann: Gelegentlich, zufällig, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Prüfung nach dem Prinzip eines akkumulierten Kontingents (Token-Bucket), Spielraum in Höhe von Ping und Jitter einplanen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Anzahl der Ablehnungen und Positionskorrekturen durch die Servervalidierung) - Wo nachsehen: Im Server-Log bei jeder Ablehnung und Positionskorrektur den Grund, die Zahl der in diesem Tick eingetroffenen Befehle des Spielers und den Ankunftsabstand zum vorigen Befehl protokollieren - Spricht dafür: Ablehnungen und Korrekturen häufen sich in Momenten, in denen 2 oder mehr Befehle im selben Tick eintreffen, über einige Sekunden summiert liegen Bewegung und Nutzungsanzahl innerhalb der Regeln - Spricht dagegen: Auch über einige Sekunden summiert über den Regeln: echtes Speedhacking oder Cheats möglich. Ablehnungen häufen sich bei einem bestimmten Provider und abends: „Gehäufte False Positives der Validierung bei bestimmten Providern“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Ein pro Tick wachsendes Budget für die Befehlsverarbeitung (maximal 24 Ticks, sv_maxusrcmdprocessticks) lässt gebündelt eintreffende Befehle zu. Laut Entwicklerkommentar hatten auch normale Spieler Ruckeln, als strenger blockiert wurde - [RFC 2697: A Single Rate Three Color Marker](https://www.rfc-editor.org/rfc/rfc2697) · IETF · Token-Bucket: Bewertung anhand der mittleren Rate (CIR) und der auf einmal zulässigen Burst-Größe (CBS) #### sy-host · Host-Architektur (Spieler-PC als Server) · Listen server / host advantage Übernimmt der PC eines Spielers die Rolle des Servers, bestimmen dessen Leitung und PC-Leistung das Spielgefühl aller. - Warum → Folge → Auf dem Bildschirm: PC des Hosts übernimmt die Serverrolle (P2P, Listen-Server) → Ist Leitung oder PC des Hosts langsam, trifft es alle, der Host selbst hat Ping 0 → Nur der Host im Vorteil, verlässt er das Spiel, Freeze oder Verbindungsabbruch für alle - Symptome: Ruckeln, Freeze, Verbindungsabbruch / Faktoren: Latenz, Stillstand - Wer: Bestimmter Ort oder Kanal / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Server: auf dedizierte Server umstellen, die die Entscheidungen treffen, bis dahin beim Matchmaking Spieler mit guter Leitung und gutem PC als Host wählen. Client: Host-Migration unterstützen, beim Matchmaking Ping zu den anderen Teilnehmern, Upload-Geschwindigkeit und PC-Leistung messen und melden. - Aufgaben Infrastrukturteam: Hardware und Instanzen für dedizierte Server bereitstellen, nahe an Regionen mit vielen Spielern platzieren. - Im Graphen: Nur einzelne Ausreißer (Lag-Meldungen und Verbindungsabbrüche pro Host) - Wo nachsehen: Im Match-Log Upload-Geschwindigkeit des Hosts, RTT jedes Teilnehmers zum Host, Frametime auf dem PC des Hosts und Zeitpunkt protokollieren, zu dem der Host gegangen ist, und Lag-Meldungen sowie Verbindungsabbrüche nach Host gruppieren. Spieler können es auch prüfen, indem sie mit denselben Leuten erneut spielen und nur den Host wechseln - Spricht dafür: Lags und Verbindungsabbrüche häufen sich in den Lobbys eines bestimmten Hosts, ist dessen Upload niedrig oder seine Frametime lang, verschlechtert es sich für alle Teilnehmer zugleich, und ohne Host-Migration brechen alle Verbindungen ab, sobald der Host geht - Spricht dagegen: Unabhängig vom Host leiden nur Teilnehmer aus derselben Region: Problem mit Leitung oder Route. Bei dedizierten Servern ist es nicht diese Ursache - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Networking Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine) · Epic Games · Der Host eines Listen-Servers ist gegenüber anderen Clients im Vorteil und trägt hohe Last, weil er Server und Rendering zugleich übernimmt - [Distributed authority topologies (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/distributed-authority.html) · Unity · Verlässt der Session-Owner das Spiel, wird unter den verbleibenden Clients automatisch ein neuer Owner gewählt - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Auch P2P-Spiele lassen sich als Client-Server-Architektur betrachten, bei der der Host zugleich die Serverrolle übernimmt #### sy-optimistic-reject · Ablehnung durch den Server nach clientseitigem Feedback · Client-side feedback rejected by server Erkennt der Server einen Treffer oder Skill, den der eigene Bildschirm schon gezeigt hat, nachträglich nicht an, wird ein eindeutig gesehenes Ergebnis rückgängig gemacht. - Warum → Folge → Auf dem Bildschirm: Treffereffekt und Skill-Animation laufen vor der Bestätigung durch den Server (clientseitiges Feedback) → Server prüft Reichweite, Zielposition, Cooldown und Ressourcen erneut und lehnt ab → Blut spritzt, aber kein Schaden, Skill-Animation ohne Wirkung, nur der Cooldown läuft - Symptome: Verschluckte Aktion / Rollback, Rubberbanding / Faktoren: Latenz - Wer: Nur ich, Nur eine bestimmte Funktion / Wann: Bei bestimmten Aktionen - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: nur Teile, die eine Bestätigung brauchen, wie Schadenszahlen, Tod und Belohnungen, mit dem Serverergebnis anzeigen, häufige Ablehnungsgründe vorab selbst prüfen, bei Ablehnung Cooldown und Ressourcen zurücksetzen und den Grund anzeigen. Server: bei der Prüfung von Reichweite und Zielposition Spielraum in Höhe des Pings lassen, Ablehnungen mit Grund senden, Ablehnungsquote pro Skill als Metrik erfassen. - Größenordnungen: Die Ablehnung kommt um Ping + Tick-Wartezeit nach dem Tastendruck. Bei 150 ms Ping glaubt man etwa 0,2 s lang, getroffen zu haben. - Im Graphen: Nur einzelne Ausreißer (Ablehnungsquote des Servers pro Skill (nach Ping-Bereich)) - Wo nachsehen: Auf dem Server Ablehnungsquote und Ablehnungsgründe (Reichweite, Zielposition, Cooldown, Ressourcen) pro Skill erfassen und nach RTT-Bereichen der Spieler aufschlüsseln. Im Client zählen, wie oft eine mit clientseitigem Feedback dargestellte Aktion abgelehnt wurde - Spricht dafür: Ablehnungen häufen sich bei bestimmten Skills und den Gründen Reichweite und Zielposition, und die Ablehnungsquote steigt mit dem Ping - Spricht dagegen: Ablehnungsgrund Cooldown oder Ressourcen und unabhängig vom Ping: prüfen, ob sich die Datenwerte (Cooldown, Kosten) von Client und Server unterscheiden. Keine Ablehnungen, aber das Feedback beginnt erst nach der Serverantwort: „Feedback erst nach der Serverantwort (Request-Response)“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Clientseitiges Feedback ist das beste Mittel, um den Ping zu verbergen. Je stärker sich aber die Informationen unterscheiden, die Client und Server für ihre Entscheidung nutzen (Position des Gegners, verbleibende Ressourcen), desto häufiger kommt es zu Ablehnungen. Wer die Ablehnungsquote pro Skill als Metrik erfasst, findet leichter die Stellen, an denen die Entscheidungen auseinanderlaufen. - Quellen: - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Local-Predicted-Fähigkeiten laufen sofort auf dem Client, die endgültige Entscheidung trifft aber der Server, der das Ergebnis auch umkehren kann - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Waffenschüsse werden auf dem Client vorhergesagt und die Effekte vorab abgespielt, Vorhersagefehler werden mit dem Serverergebnis korrigiert #### sy-path-mismatch · Abweichende Pfadberechnung bei Befehlssynchronisation · Command sync with divergent pathing Werden nur Befehle wie „geh dorthin“ ausgetauscht und beide Seiten berechnen den Pfad selbst, laufen Charaktere oder Monster schon bei kleinen Rechenunterschieden einen anderen Weg und werden dann an die richtige Position zurückgezogen. - Warum → Folge → Auf dem Bildschirm: Bei Klickbewegung und Monsterverfolgung nur das Ziel senden, den Pfad berechnet der Client separat → Durch Unterschiede in Geländedaten, Kollisionen mit anderen Charakteren oder Berechnungsreihenfolge Bewegung auf einem anderen Pfad als auf dem Server → Monster läuft durch die Wand und wird plötzlich versetzt, der per Klick gesteuerte Charakter ändert rutschend die Richtung - Symptome: Teleportieren, Rubberbanding / Faktoren: Latenz - Wer: Bestimmter Ort oder Kanal, Nur ich / Wann: Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: auch Zwischenpunkte des Pfads (Wegpunkte) mitsenden, Positionen regelmäßig abgleichen. Client: Abweichungen weich angleichen, dieselben Geländedaten wie der Server verwenden. - Im Graphen: Vereinzelte Spitzen ohne Muster (Anzahl und Distanz der Positionskorrekturen pro Objekt) - Wo nachsehen: Pro Objekt die Differenz zwischen der vom Server gesendeten und der vom Client berechneten Position protokollieren und die Koordinaten der Korrekturen auf einer Karte eintragen. Fasst man Pfadergebnisse oder Positionen beider Seiten als Prüfsumme zusammen und vergleicht sie regelmäßig, lässt sich der Zeitpunkt finden, ab dem sie auseinanderlaufen - Spricht dafür: Korrekturen häufen sich an bestimmten Geländestellen (Schwellen, enge Durchgänge, Hänge) oder an belebten Orten und wiederholen sich an derselben Stelle auch bei Spielern mit unauffälligen Netzwerkmetriken - Spricht dagegen: Korrekturen nur in Momenten mit Ausschlägen bei Paketverlust oder Jitter, unabhängig vom Ort: Leitungsproblem. Springt ein einzelnes Monster auf mehreren Bildschirmen gleichzeitig: prüfen, ob die Autorität über das Monster bei einem langsamen Client liegt - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Dieses Verfahren ist ein Grund, warum Spiele mit Klickbewegung und Tab-Targeting wenig empfindlich auf Ping reagieren. Dafür gibt es keine Garantie, dass beide Seiten zum selben Ergebnis kommen, und ein Mechanismus, der die Positionen gelegentlich abgleicht, ist unverzichtbar. Gleitkommaberechnungen können je nach CPU-Typ, Compiler und dessen Optimierungseinstellungen (einschließlich der Unterschiede zwischen Debug- und Release-Build) leicht abweichende Ergebnisse liefern. In Architekturen wie Lockstep und Rollback, die nur Eingaben austauschen und identische Rechenergebnisse auf beiden Seiten voraussetzen, können sich diese kleinen Unterschiede aufsummieren, bis der Spielzustand auf beiden Bildschirmen auseinanderläuft (Desync). - Quellen: - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Selbst wenn es auf derselben Maschine deterministisch ist, können Gleitkommaergebnisse bei anderem Compiler, OS oder CPU abweichen - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Sendet man den Zustand zusammen mit den Eingaben, lassen sich beide Seiten auch ohne perfekten Determinismus abgleichen - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Bei Paketverlust oder wenn zwei Charaktere an dieselbe Stelle wollen, laufen die Simulationen von Server und Client auseinander und müssen korrigiert werden - [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) · Game Developer · Winzige Unterschiede wachsen mit der Zeit, die Pfade der Dorfbewohner weichen immer weiter ab. Welt, Objekte und Pfadsuche werden per Prüfsumme verglichen, um Abweichungen (out-of-sync) zu finden - [Floating Point Determinism](https://gafferongames.com/post/floating_point_determinism/) · Gaffer On Games · Derselbe Gleitkommacode kann je nach Compiler, CPU-Architektur sowie Debug- oder Release-Build unterschiedliche Ergebnisse liefern. Fall, in dem CPUs von AMD und Intel bei transzendenten Funktionen leicht unterschiedliche Werte lieferten - [/fp (Specify floating-point behavior)](https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior) · Microsoft · /fp:fast kann die Reihenfolge von Gleitkommaoperationen ändern oder Operationen zusammenfassen, sodass die Ergebnisse von anderen /fp-Einstellungen abweichen. Auch per FMA zusammengefasste Operationen können sich vom Ergebnis getrennter Multiplikation und Addition unterscheiden #### sy-low-send-rate · Niedrige Snapshot-Senderate · Low snapshot / update rate Sendet der Server Positionsupdates (Snapshots) nur wenige Male pro Sekunde, muss der Interpolationspuffer entsprechend lang sein, und andere Charaktere erscheinen weiter in der Vergangenheit. - Warum → Folge → Auf dem Bildschirm: Um Datenvolumen zu sparen, nur 5–10 Positionsupdates pro Sekunde → Für eine flüssige Darstellung muss der Puffer das Doppelte des Paketabstands (200–400 ms) betragen, ist er kürzer, bleibt die Darstellung schon bei einem einzigen verlorenen Paket stehen → Richtungswechsel des Gegners erscheinen verspätet und passen nicht zur Trefferabfrage. Bei kurzem Puffer Ruckeln, bei Paketverlust Teleportieren - Symptome: Ruckeln, Teleportieren, Verschluckte Aktion / Rollback / Faktoren: Latenz, Paketverlust - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: nahe oder kämpfende Objekte häufig senden, entfernte selten, nur Änderungen senden (Delta-Kompression), um die Größe pro Update zu senken und die Rate zu erhöhen. Client: Länge des Interpolationspuffers automatisch an den Paketabstand anpassen. - Größenordnungen: Bei 10 Updates pro Sekunde beträgt der Paketabstand 100 ms, der Puffer 200 ms. Mit 75 ms Latenz pro Richtung bei 150 ms Ping sieht man den Gegner etwa 0,3 s in der Vergangenheit. - Im Graphen: Von Anfang an dauerhaft hoch (Ankunftsabstand der Pakete pro Client, Länge des Interpolationspuffers) - Wo nachsehen: Im serverseitigen Paketmitschnitt nur den Datenstrom zu einem Spieler filtern und mit den I/O Graphs von Wireshark Pakete pro Sekunde und Abstände ansehen. Gibt es spielseitige Logs, zusätzlich Update-Abstand pro Objekt und Reserve im Interpolationspuffer des Clients (verbleibende Zeit bis zum nächsten Snapshot) prüfen - Spricht dafür: Positionsupdates durchgehend selten mit 5–10 pro Sekunde (Abstand 100–200 ms), Interpolationspuffer auf über 200 ms eingestellt oder Pufferreserve häufig bei 0 - Spricht dagegen: Updates gehen dicht hinaus, nur die Ankunftsabstände schwanken: eher Jitter oder Paketverlust. Nur entfernte Objekte werden bei Gedränge selten aktualisiert: „Sendebudget und Priorität pro Verbindung“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Bei 10 Updates pro Sekunde übersteht eine Interpolation von 200 ms einen einzelnen Ausfall. Standard bei Half-Life: 20 Updates pro Sekunde, 100 ms Interpolation - [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/) · Gaffer On Games · Bei 10 pro Sekunde sind 350 ms Verzögerung nötig, um bis zu zwei aufeinanderfolgende Verluste zu überstehen, bei 30 pro Sekunde sinkt das auf 150 ms - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Über akkumulierte Prioritäten werden wichtige Objekte häufiger gesendet, die übrigen reihum innerhalb des Bandbreitenlimits - [8.8. The “I/O Graphs” Window](https://www.wireshark.org/docs/wsug_html_chunked/ChStatIOGraphs.html) · Wireshark · Stellt Anzahl der Pakete und Bytes, die zum Anzeigefilter passen, als Graph pro Zeitintervall dar ### Probleme, die nur einige betreffen (24 Ursachen) #### pt-slow-burst · Laggender Spieler bewegt sich auf fremden Bildschirmen schubweise · Laggy player seen by others (bursty inputs) Die Eingaben eines Spielers mit schlechter Leitung kommen unregelmäßig und gebündelt beim Server an. Wendet der Server pro Tick alles an, was gerade eingetroffen ist, sehen andere diesen Charakter stocken und dann mehrere Schritte auf einmal machen. - Warum → Folge → Auf dem Bildschirm: Pro Tick kommen mal 0, mal 2–3 Bewegungsbefehle des langsamen Spielers an → Server wendet sie gesammelt im Ankunfts-Tick an, die Position des Charakters ändert sich treppenförmig → Auf anderen Bildschirmen stockt nur dieser Charakter und bewegt sich dann im Zeitraffer. Alles andere läuft normal - Symptome: Zeitraffer, Teleportieren / Faktoren: Jitter, Paketverlust - Wer: Nur ein bestimmter Charakter wirkt seltsam, Bestimmte Region oder Provider / Wann: Immer, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Befehle über einen Eingabepuffer pro Spieler gleichmäßig verteilt anwenden, anhand der Sequenznummern der Eingaben im ursprünglichen Abstand anwenden. Nur den Interpolationspuffer auf den anderen Bildschirmen zu verlängern, reicht nicht (der Positionsverlauf auf dem Server ist selbst schon treppenförmig). - Aufgaben Extern: Hinweis an langsame Spieler: LAN-Kabel verwenden, WLAN und Router prüfen. - Größenordnungen: Bei 80 ms Jitter schwankt die Zahl der Befehle pro Tick auf einem 20-Tick-Server (50 ms) zwischen 0 und 3. - Im Graphen: Nur einzelne Ausreißer (Angewandte Befehle pro Tick und Spieler, Jitter pro Spieler) - Wo nachsehen: Im serverseitigen Paketmitschnitt nur die Pakete des gemeldeten Spielers filtern, pro Tick-Intervall (z. B. 50 ms) die Zahl der eingetroffenen Pakete zählen und mit anderen Spielern vergleichen. Gibt es ein Server-Log, pro Spieler und Tick die Zahl der angewandten Bewegungsbefehle und die Sequenznummern der Eingaben prüfen - Spricht dafür: Nur die Pakete des gemeldeten Spielers kommen gebündelt an, pro Tick wechselnd 0 und 2–3, Jitter und Paketverlust dieses Spielers sind hoch, die Pakete anderer Spieler kommen gleichmäßig. Wechselt der Spieler auf LAN-Kabel, wird es weniger - Spricht dagegen: Mehrere Charaktere bewegen sich gleichzeitig im Zeitraffer: Tick-Verzögerung auf dem Server oder Leitung des Betrachters. Ankunft und Anwendung gleichmäßig, aber nur dieser Charakter springt: Interpolations- oder Darstellungsproblem beim Betrachter - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: In einer Architektur mit autoritativem Server ist das normales Verhalten. Der Lag eines einzelnen langsamen Spielers zeigt sich für andere nur als „seltsame Bewegung dieses Spielers“ und wirkt sich weder auf die Steuerung anderer noch auf Monsterbewegungen aus. Alles, was direkt mit diesem Spieler zu tun hat (Handel, Gruppenmechaniken, PvP-Trefferabfrage), verzögert sich allerdings mit. - Quellen: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Der Server legt eingetroffene Eingaben in Tick-Reihenfolge in eine Bewegungs-Queue pro Spieler und füllt Lücken mit Vorhersagen. Korrekturen sieht nur dieser Spieler, alle anderen sehen eine flüssige Bewegung - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Auch 60-mal pro Sekunde gesendete Pakete kommen gebündelt an, etwa 2 in einem Frame und 0 im nächsten - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Gebündelt eingetroffene Befehle werden verteilt auf die Server-Ticks verarbeitet (meter out) #### pt-event-server · Zeitraffer bei Servern, die sofort bei Ankunft verarbeiten · Event-driven processing of bursty inputs Auf einem Server, der Pakete sofort bei Ankunft verarbeitet und weitermeldet, werden die gebündelt eintreffenden Aktionen eines langsamen Spielers direkt hintereinander ausgeführt. - Warum → Folge → Auf dem Bildschirm: Skill- und Bewegungsanfragen des langsamen Spielers kommen gebündelt an → Server führt sie sofort der Reihe nach aus und meldet sie umgehend an alle → Für andere setzt dieser Spieler mehrere Skills in einem Augenblick ein oder bewegt sich wie im Vorspulen - Symptome: Zeitraffer / Faktoren: Jitter - Wer: Nur ein bestimmter Charakter wirkt seltsam / Wann: Bei bestimmten Aktionen, Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Aktionen im Abstand ihrer Eingabezeitpunkte ausführen (Zeitpunkte nur innerhalb eines Toleranzbereichs anerkennen) oder gebündelte Aktionen nicht ablehnen und im Mindestabstand (globaler Cooldown) nacheinander ausführen, Cooldown nicht allein anhand der Ankunftszeit prüfen (sonst werden normale Eingaben verschluckt). Client: Aktionen mit Eingabezeitpunkt senden. - Im Graphen: Nur einzelne Ausreißer (Ausführungsabstand der Aktionen pro Spieler) - Wo nachsehen: Im Server-Log pro Spieler Ankunftszeit, Ausführungszeit und (falls vorhanden) den vom Client mitgeschickten Eingabezeitpunkt jeder Aktion protokollieren und Ausführungs- mit Eingabeabständen vergleichen. Zusätzlich im serverseitigen Paketmitschnitt die Ankunftsabstände der Pakete dieses Spielers prüfen - Spricht dafür: Eingabeabstände normal, aber Ankunfts- und Ausführungsabstände auf dem Server auf wenige ms zusammengedrängt, und diese Momente decken sich mit den Zeitpunkten, zu denen andere Zeitraffer melden - Spricht dagegen: Schon die Eingabezeitpunkte liegen dicht beieinander: Client oder Makro. Ausführungsabstände auf dem Server gleichmäßig, gebündelt wirkt es nur auf fremden Bildschirmen: Leitung des Betrachters - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Der Server berechnet die Bewegung bei jedem empfangenen ServerMove und bestimmt das Zeitintervall aus der Zeitstempeldifferenz zur vorigen Bewegung. Weicht der Zeitstempel zu stark von der Serverzeit ab, wird die Bewegung verworfen - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Werden Eingaben sofort bei Ankunft angewandt, sind die Abstände trotz Senden mit 60 Hz ungleichmäßig und die Ergebnisse schwanken #### pt-input-buffer · Größe des Eingabepuffers pro Spieler · Per-player server input buffer (jitter buffer) Sammelt der Server pro Spieler ein paar Eingaben und entnimmt pro Tick eine, sieht es für andere flüssig aus. Die eigenen Aktionen werden auf dem Server aber entsprechend später bestätigt. - Warum → Folge → Auf dem Bildschirm: Server sammelt die Eingaben des langsamen Spielers im Puffer und wendet pro Tick eine an → Bei kleinem Puffer läuft er oft leer, der Charakter bleibt stehen oder der Server bewegt ihn per Schätzung anhand der letzten Eingabe weiter. Bei großem Puffer werden die eigenen Eingaben spät bestätigt → Klein: Stocken auf fremden Bildschirmen, groß: eigene Skill-Ergebnisse kommen spät (Input-Lag) - Symptome: Ruckeln, Input-Lag / Faktoren: Jitter - Wer: Nur ein bestimmter Charakter wirkt seltsam, Nur ich / Wann: Immer - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Puffergröße pro Spieler automatisch an den Leitungszustand anpassen, bei Rückstand zwei Eingaben auf einmal entnehmen und aufholen, Clients von Spielern, deren Puffer oft leerläuft, anweisen, Eingaben früher zu senden. Client: Eingaben nach Anweisung des Servers etwas früher senden (Anpassung der Client-Zeit). - Größenordnungen: Das hängt vom Spiel ab, meist sind es 1–3 Ticks. VALORANT hält den Serverpuffer auf seinen 128-Tick-Servern noch kürzer, im Mittel bei einem halben Frame (etwa 4 ms). Verbreitet ist eine adaptive Lösung, die den Puffer nur bei Spielern mit hohem Jitter vergrößert. - Im Graphen: Nur einzelne Ausreißer (Länge des Eingabepuffers und Leerläufe pro Spieler) - Wo nachsehen: Auf dem Server pro Spieler und Tick die Zahl der im Eingabepuffer verbliebenen Eingaben, die Zahl der Fälle, in denen der Puffer leer war und per Schätzung anhand der letzten Eingabe aufgefüllt wurde, und die Zeit von Ankunft bis Anwendung einer Eingabe protokollieren - Spricht dafür: Spieler mit kleinem Puffer haben viele Leerläufe und stocken genau dann kurz auf fremden Bildschirmen, bei Spielern mit großem Puffer ist die Zeit von Eingabe bis Anwendung um die Pufferlänge verlängert - Spricht dagegen: Puffer läuft fast nie leer, und trotzdem ist auf fremden Bildschirmen Ruckeln zu sehen: Interpolationsproblem beim Betrachter. Großer Input-Lag trotz kurzem Puffer: die RTT selbst oder „Doppeltes Warten auf den Tick“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Der Server passt die Zeitbasis des Clients so an, dass die Eingabe-Queue gerade groß genug ist, um ungleichmäßige Ankünfte bei minimaler Latenz abzufangen. Ziel der Pufferung auf dem Server: im Mittel ein halber Frame - [NetworkTimeSystem class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkTimeSystem.html) · Unity · LocalBufferSec: Zeit, die der Server Client-Nachrichten puffert. Die Client-Zeit wird vorgezogen, damit Nachrichten früher beim Server ankommen - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Spieler mit schlechter Leitung können den Pufferwert erhöhen #### pt-isp-validation · Gehäufte False Positives der Validierung bei bestimmten Providern · Anti-cheat / movement validation false positives on bad ISPs Bei Spielern, deren Leitung hohen Jitter hat, kommen Eingaben gebündelt an und bleiben deshalb oft in den Geschwindigkeits- und Cooldown-Prüfungen des Servers hängen. - Warum → Folge → Auf dem Bildschirm: Jitter auf den Leitungen eines bestimmten Providers oder einer Region steigt abends → Server wertet gebündelt eintreffende normale Eingaben als Geschwindigkeits- oder Cooldown-Verstoß → Nur Kunden dieses Providers haben Rubberbanding und abgelehnte Skills, im schlimmsten Fall wirft der Server sie raus (Verbindungsabbruch) - Symptome: Rubberbanding, Verschluckte Aktion / Rollback, Verbindungsabbruch / Faktoren: Jitter - Wer: Bestimmte Region oder Provider, Nur ich / Wann: Abendliche Stoßzeit, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Prüfung über ein über einige Sekunden akkumuliertes Kontingent, Kriterien anhand des Leitungszustands (Ping, Jitter) lockern, Warnstufe vor dem Rauswurf, gebündelte Eingaben über einen Eingabepuffer pro Spieler gleichmäßig auf die Ticks verteilen und so False Positives schon an der Wurzel reduzieren. - Aufgaben Infrastrukturteam: Verteilung von Verlustrate und Jitter pro Provider nach Tageszeit auswerten und mit dem Entwicklungsteam teilen, Route im Abschnitt dieses Providers prüfen (mtr in beide Richtungen), bei Bedarf Route ändern oder an den Provider eskalieren. - Im Graphen: Nur zu bestimmten Tageszeiten hoch (Validierungsablehnungen und Rauswürfe pro Provider (ASN), Jitter pro Provider) - Wo nachsehen: Server-Logs zu Validierungsablehnungen, Korrekturen und Rauswürfen um Provider (ASN) der Client-IP und Zeitpunkt ergänzen und nach Provider und Tageszeit zählen. Das Infrastrukturteam lässt zur selben Zeit mtr in beide Richtungen zu diesem Provider laufen und prüft Jitter und Paketverlust - Spricht dafür: Ablehnungen und Rauswürfe häufen sich bei einem bestimmten Provider und nehmen abends zu, zur selben Zeit ist der Jitter dieses Providers ebenfalls hoch, und die über einige Sekunden summierte Bewegung liegt innerhalb der Regeln - Spricht dagegen: Unabhängig vom Provider wiederholt es sich nur bei bestimmten Accounts: echte Cheats möglich. Anstieg bei allen Providern zugleich: serverseitige Ursache, bei der Ticks in Verzug geraten und Befehle gebündelt angewandt werden („Überschrittenes Tick-Budget“) - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Ein pro Tick wachsendes Befehlsbudget verhindert zu schnelle Bewegung, strengere Grenzen verursachen laut Entwicklerkommentar aber auch bei normalen Spielern Ruckeln - [RFC 2697: A Single Rate Three Color Marker](https://www.rfc-editor.org/rfc/rfc2697) · IETF · Token-Bucket: Bewertung anhand der mittleren Rate und der zulässigen Burst-Größe - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Bei großer Differenz zwischen Client- und Server-Zeitstempel wird die Bewegung verworfen oder über ein Verfahren zum Ausgleich der Zeitdifferenz behandelt, die Berechnung mit Serverzeit verhindert Speedhacks #### pt-raid-member · Ein laggendes Gruppenmitglied und Boss-Mechaniken · One laggy member in a synchronized mechanic Bei Raid-Mechaniken, auf die alle im selben Moment reagieren müssen, wird die verspätete Reaktion eines einzelnen langsamen Spielers zum Fehlschlag der ganzen Gruppe. - Warum → Folge → Auf dem Bildschirm: Gemeinsame Mechaniken wie „alle gleichzeitig verteilen“ oder „einer drückt einen Knopf“ → Der langsame Spieler sieht die Vorwarnung spät, und auch seine Eingabe kommt spät an → Wegen dieses einen Spielers Wipe, die anderen Gruppenmitglieder empfinden es als „Schuld des Laggers“ - Symptome: Verschluckte Aktion / Rollback, Input-Lag / Faktoren: Latenz - Wer: Bestimmter Ort oder Kanal, Nur ein bestimmter Charakter wirkt seltsam / Wann: Bei großem Andrang, Bei bestimmten Aktionen - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Zeitfenster der Mechanik um den Ping großzügiger bemessen, Vorwarnungen vorab mit Serverzeit senden, so designen, dass der Fehler eines Einzelnen nicht zum Wipe führt. Client: empfangene Vorwarnungen passend zur Serverzeit abspielen. - Im Graphen: Nur einzelne Ausreißer (RTT der Spieler, die einen Mechanik-Fehlschlag ausgelöst haben) - Wo nachsehen: Im Mechanik-Log des Servers den auslösenden Spieler, die Ankunftszeit seiner Eingabe, das Zeitfenster sowie RTT und Paketverlust dieses Spielers protokollieren - Spricht dafür: Die Eingaben, die zum Wipe geführt haben, stammen meist von derselben Person, deren RTT deutlich über dem Gruppendurchschnitt liegt, und die Eingabe kommt direkt nach dem Zeitfenster an - Spricht dagegen: Fehlschläge verteilen sich gleichmäßig auf die Gruppe: das Zeitfenster selbst ist zu kurz („Kurze Zeitfenster, die der Ping aufzehrt“). Eingabe des langsamen Spielers kam innerhalb des Zeitfensters an und scheitert trotzdem: Code der Mechanik-Auswertung auf dem Server - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Verfahren, bei dem Events zur Serverzeit eingeplant werden, damit alle sie im selben Moment abspielen - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Einfache Reaktionszeit im Mittel etwa 231 ms #### pt-mob-control · Autorität über Monster bei einem langsamen Client · Monster movement delegated to a player client Manche Spiele übertragen die Berechnung von Monsterbewegungen an den Client eines Spielers in der Nähe, um den Server zu entlasten. Hat dieser Spieler eine schlechte Leitung, bewegt sich das Monster auf allen Bildschirmen seltsam. - Warum → Folge → Auf dem Bildschirm: Server überträgt die Berechnung der Monsterbewegung an den Client des nächstgelegenen (oder zuerst eingetroffenen) Spielers → Ergebnismeldungen des zuständigen Spielers kommen verspätet oder gebündelt beim Server an → Nur dieses Monster stockt auf den Bildschirmen aller in der Umgebung und teleportiert dann. Auf dem Bildschirm des zuständigen Spielers selbst sieht alles normal aus - Symptome: Teleportieren, Ruckeln, Zeitraffer / Faktoren: Jitter, Paketverlust - Wer: Nur ein bestimmter Charakter wirkt seltsam, Bestimmter Ort oder Kanal / Wann: Immer, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Autorität an Spieler mit guter Leitung übergeben (nach Ping und Paketverlust), bei ausbleibenden Meldungen sofort durch den Server zurückholen, wichtige Monster wie Bosse direkt auf dem Server berechnen. - Im Graphen: Nur einzelne Ausreißer (Meldeabstände pro Monster (nach Client mit Autorität)) - Wo nachsehen: Auf dem Server pro Monster den Client mit Autorität sowie dessen Meldeabstand, RTT und Paketverlust protokollieren. Im serverseitigen Paketmitschnitt sind auch die Ankunftsabstände der Pakete dieses Clients zu sehen - Spricht dafür: Die Autorität über alle seltsam laufenden Monster liegt bei derselben Person, deren Meldeabstände unregelmäßig sind oder abreißen, und nach Übergabe der Autorität an jemand anderen ist sofort alles normal - Spricht dagegen: Monster, die der Server selbst berechnet, springen genauso: Tick-Verzögerung auf dem Server oder Leitung des Betrachters. Springen weiter trotz Wechsel der Autorität: „Abweichende Pfadberechnung bei Befehlssynchronisation“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Der zuständige Spieler merkt nichts, deshalb kommen Meldungen nur als „das Monster verhält sich seltsam“ an. Sehen alle außer einem dasselbe Monster seltsam, zuerst prüfen, wer die Autorität über dieses Monster hat. - Quellen: - [Authority (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/authority.html) · Unity · Im Modell der verteilten Autorität übernimmt jede Spielinstanz (Client) die Autorität über einen Teil der Netzwerkobjekte und berechnet diese - [Distributed authority topologies (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/distributed-authority.html) · Unity · Wird die Autorität auf Clients verteilt, gibt es keine einzelne Simulation mehr, und das System wird anfällig für Cheats #### pt-heavy-char · Aufgeblähte Daten eines bestimmten Charakters · One character with oversized data (inventory, mail, buffs) Bei einem Charakter mit Tausenden Items oder Postnachrichten, ungewöhnlich langen Freundes- oder Blocklisten oder sehr vielen Buffs ist die Datenmenge beim Login, beim Speichern und beim Melden an die Umgebung um ein Vielfaches größer als bei anderen. Unabhängig von der Leitung ist es nur mit diesem Charakter langsam. - Warum → Folge → Auf dem Bildschirm: Lange gespielter Charakter oder Event-Belohnungen: Tausende Einträge in Inventar und Postfach → Bei jedem Login, Gebietswechsel und Speichern entsprechend viele DB-Lese- und Schreibvorgänge, auch die an die Umgebung zu sendenden Ausrüstungs- und Buff-Daten sind groß → Nur dieser Charakter hat lange Ladezeiten beim Betreten und stockt beim Öffnen von Inventar oder Postfach. Wartet der Server im Game-Thread auf das Speichern, stehen auch Spieler in der Umgebung kurz still - Symptome: Kein Login / Endlos-Laden, Input-Lag, Freeze / Faktoren: Stillstand - Wer: Nur ich, Nur eine bestimmte Funktion / Wann: Direkt nach Login oder Wartung, Bei bestimmten Aktionen, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: DB-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Obergrenzen für Inventar und Postfach mit automatischem Aufräumen alter Post, nur benötigte Teile nachladen, nur Änderungen und außerhalb des Game-Threads speichern. - Aufgaben Infrastrukturteam: Im Slow-Query-Log wiederholte langsame Abfragen zum selben Charakter finden und an das Entwicklungsteam weitergeben, Top-Liste der Charaktere mit den meisten Item- und Postzeilen bereitstellen. - Größenordnungen: Ist jedes Item eine Zeile in der DB, liest ein Charakter mit 5.000 Items bei jedem Login 5.000 Zeilen. Das ist das Zigfache eines normalen Charakters. - Im Graphen: Nur einzelne Ausreißer (Login- und Speicherzeit pro Charakter, gelesene DB-Zeilen pro Charakter) - Wo nachsehen: Im Slow-Query-Log der DB (MySQL slow query log, PostgreSQL log_min_duration_statement) wiederholte langsame Abfragen und Speichervorgänge mit derselben Charakter-ID suchen und eine Top-Liste der Zeilenzahl pro Charakter in den Item- und Posttabellen erstellen - Spricht dafür: Langsame Queries häufen sich bei wenigen Charakter-IDs, deren Item- und Postzeilen das Zigfache des Durchschnitts betragen, und auch von einem anderen PC und über eine andere Leitung ist es genauso langsam - Spricht dagegen: Auch andere Charaktere desselben Accounts oder andere Spieler sind langsam: DB-Hardware oder Locks. Derselbe Charakter läuft auf einem anderen PC normal: Umgebung des Spielers - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Ist derselbe Charakter auch von einem anderen PC und über eine andere Leitung genauso langsam, während andere Charaktere desselben Accounts normal laufen, stehen die Charakterdaten unter Verdacht. Deshalb gehört der Charaktername unbedingt in jede Meldung. - Quellen: - [Extraneous Fetching antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/extraneous-fetching/) · Microsoft Azure · Werden mehr Daten als nötig abgerufen, steigt die I/O-Last und die Antworten werden langsamer - [PostgreSQL Documentation: Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html) · PostgreSQL · log_min_duration_statement: protokolliert SQL-Anweisungen ab einer bestimmten Dauer, um langsame Queries zu verfolgen - [The Slow Query Log](https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html) · MySQL · Slow-Query-Log, das Queries über long_query_time protokolliert #### pt-phase · Unterschiede bei Kanal, Instanz oder Phasing · Different channel / instance / phase Befinden sich zwei Charaktere in verschiedenen Kanälen oder Instanzen oder in unterschiedlichen „Phasen“, in denen je nach Questfortschritt andere NPCs sichtbar sind, sehen sie unterschiedliche Welten. - Warum → Folge → Auf dem Bildschirm: Zweiter Charakter einem anderen Kanal zugewiesen oder auf einer anderen Queststufe → Server schickt diesem Charakter den betreffenden NPC nicht (korrektes Verhalten) → NPC fehlt nur auf einer Seite. Sieht wie ein Bug aus, ist aber so gewollt - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Immer, Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Kanal- und Phasing-Informationen an den Client senden, QA-Checkliste um „Kanal und Queststufe beider Charaktere prüfen“ ergänzen. Client: Kanal und Phase auf dem Bildschirm anzeigen. - Im Graphen: Nur einzelne Ausreißer (Objekte in der Umgebung pro Client, Kanal und Phase) - Wo nachsehen: Kanalnummer und Stufe der betreffenden Quest bei beiden Charakteren im Spiel vergleichen und mit gleichem Kanal und gleicher Stufe erneut prüfen. Gibt es ein Log der Objektübertragung auf dem Server, den Grund prüfen, warum dieser NPC nicht an den Charakter gesendet wurde (Kanal, Phase) - Spricht dafür: Kanal oder Queststufe der beiden Charaktere unterscheiden sich, nach Angleichung ist der NPC sichtbar - Spricht dagegen: Gleicher Kanal und gleiche Stufe, trotzdem fehlt der NPC auf einer Seite: eher „Verworfene Spawn-Meldungen während des Ladens“, „Verlust gebündelter Spawn-Daten direkt nach dem Betreten“ oder „Reihenfolgefehler bei der Sichtbereichsregistrierung“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Mehr dazu: Zu prüfen ist auch, ob der Questfortschritt pro Account oder pro Charakter gespeichert wird. Bei zwei Charakteren desselben Accounts kann der Fortschritt des einen die Phase des anderen ändern. - Quellen: - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Der Server repliziert pro Verbindung nur relevante (relevant) Actors, nicht relevante werden nicht gesendet - [Object visibility (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/basics/object-visibility.html) · Unity · CheckObjectVisibility legt pro Client fest, welche Objekte sichtbar sind, ausgeblendete Objekte werden an diesen Client nicht gesendet #### pt-loading-drop · Verworfene Spawn-Meldungen während des Ladens · Spawn messages dropped before the client is ready Direkt beim Betreten einer Zone schickt der Server Spawn-Meldungen für die NPCs in der Umgebung, aber der Client lädt noch die Karte und verwirft sie. - Warum → Folge → Auf dem Bildschirm: Server sendet direkt nach dem Betreten Spawn-Meldungen für Objekte in der Umgebung → Client lädt noch, es gibt noch keinen Message-Handler, die Meldungen werden verworfen → Server betrachtet sie als gesendet und schickt sie nicht erneut. Der NPC bleibt unsichtbar, bis man den Sichtbereich verlässt und zurückkommt - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Direkt nach Login oder Wartung, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: nach dem Laden „bereit“ melden oder während des Ladens empfangene Pakete zwischenspeichern und danach verarbeiten. Server: Umgebungsdaten erst nach Empfang von „bereit“ senden. - Größenordnungen: Laden zwei Clients auf demselben PC gleichzeitig oder ist der ladende Client ein Hintergrundfenster, teilen sie sich CPU und Datenträger und werden zusätzlich gedrosselt, sodass das Laden dort ein Vielfaches länger dauern kann. Auch wenn der Server das Betreten schneller verarbeitet, tritt derselbe Bug zutage. - Im Graphen: Nur einzelne Ausreißer (Ladezeit pro Client, während des Ladens verworfene Nachrichten) - Wo nachsehen: Anzahl und Art der Nachrichten, die der Client während des Ladens empfangen und verworfen hat, sowie den Zeitpunkt des Ladeendes mit dem Zeitpunkt vergleichen, zu dem der Server die Spawn-Meldungen gesendet hat. Laden zwei Clients auf demselben PC gleichzeitig oder liegt der ladende Client im Hintergrund, lässt es sich leicht nachstellen - Spricht dafür: Der Server hat die Spawn-Meldung für den unsichtbaren NPC gesendet, sie kam vor dem Ladeende an, und in dieser Zeit ist die Zahl der verworfenen Nachrichten gestiegen. Tritt nur beim Client mit der längeren Ladezeit auf - Spricht dagegen: Spawn-Meldung kam nach dem Ladeende an und der NPC ist trotzdem unsichtbar: „Verlorener Basis-Snapshot“ oder „Verwechslung durch wiederverwendete Objekt-IDs“. Server hat die Meldung für diesen NPC gar nicht gesendet: „Reihenfolgefehler bei der Sichtbereichsregistrierung“ oder „Unterschiede bei Kanal, Instanz oder Phasing“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · SpawnTimeout: Nachrichten für noch nicht erzeugte Objekte werden zurückgehalten und verworfen, wenn das Objekt nicht rechtzeitig erzeugt wird - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Nicht mehr relevante Actors werden auf dem Client gelöscht und bei erneuter Relevanz neu repliziert #### pt-aoi-race · Reihenfolgefehler bei der Sichtbereichsregistrierung · Interest-management race on enter/leave Fällt der Moment, in dem ein Charakter im Sichtbereichsraster registriert wird, mit dem Moment zusammen, in dem ein NPC die Rasterzelle wechselt, kann die Spawn-Meldung für diesen NPC ausbleiben. - Warum → Folge → Auf dem Bildschirm: Betreten, Kanalwechsel oder Teleport werden im selben Moment verarbeitet, in dem sich ein NPC bewegt → Bei der Berechnung der „neu sichtbaren Objekte“ fehlt dieser NPC → Nur einige bestimmte NPCs sind unsichtbar, oder bereits verschwundene NPCs stehen noch da - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Beim Bewegen oder Zonenwechsel, Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Sichtbereichs-Updates in einem Thread und in fester Reihenfolge verarbeiten, regelmäßig die gesamte „Sichtliste“ neu abgleichen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Abweichungen zwischen Sichtliste auf dem Server und Objektliste im Client) - Wo nachsehen: Auf dem Server Registrierungen im Sichtbereichsraster, Zellwechsel von Objekten sowie gesendete Spawn- und Despawn-Meldungen mit Tick-Nummer protokollieren und regelmäßig die „Sichtliste“ des Servers mit der Liste des Clients vergleichen - Spricht dafür: Der fehlende NPC hat im selben Tick die Zelle gewechselt, in dem Betreten oder Teleport des Charakters verarbeitet wurden, und für diesen NPC ist keine gesendete Spawn-Meldung protokolliert - Spricht dagegen: Spawn-Meldung gesendet, aber vom Client nicht empfangen oder verworfen: Problem bei der Zustellung („Verlust gebündelter Spawn-Daten direkt nach dem Betreten“, „Verworfene Spawn-Meldungen während des Ladens“). Fehlt immer derselbe NPC: „Unterschiede bei Kanal, Instanz oder Phasing“ oder „Unterschiedliche Anzeigeoptionen“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · MMORPGs u. a. teilen die Welt in ein Raster mit einer Actor-Liste pro Zelle und senden ausgehend von der Zelle, in der sich der Client befindet - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Relevanz wird pro Verbindung bestimmt, nicht mehr relevante Actors werden auf dem Client gelöscht #### pt-baseline · Verlorener Basis-Snapshot · Lost baseline for delta compression Sendet der Server nur „Änderungen seit dem letzten Mal“, lassen sich spätere Änderungen nicht anwenden, wenn die einmalig gesendete Gesamtinformation (Basis) verloren geht. - Warum → Folge → Auf dem Bildschirm: Paket mit der Gesamtinformation eines Objekts (Basis) geht verloren oder wird vor der Verarbeitung verworfen → Client hat kein Objekt, auf das er spätere Änderungen anwenden kann, und ignoriert sie → Das Objekt ist unsichtbar oder taucht erst viel später plötzlich auf - Symptome: Unsichtbar / Geisterobjekte, Teleportieren / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Basis unbedingt erneut senden, bis eine Empfangsbestätigung (ACK) kommt, Änderungen nur relativ zu einer vom Client bestätigten Basis erzeugen. Client: ACK für die Basis erst senden, wenn sie tatsächlich angewandt ist, bei Änderungen für unbekannte Objekte erneut beim Server anfordern. - Im Graphen: Vereinzelte Spitzen ohne Muster (Empfangene Änderungen für unbekannte Objekte) - Wo nachsehen: Anzahl und Objekt-IDs der Änderungen, die der Client ohne Basis empfangen und verworfen hat, mit den Zeitpunkten abgleichen, zu denen der Server die Basis dieses Objekts gesendet und das ACK erhalten hat. In der Entwicklungsumgebung mit hinzugefügtem Paketverlust nachstellen (loss bei tc netem, Paketverlustrate der Unreal-Netzwerkemulation) - Spricht dafür: Für das unsichtbare Objekt hat der Server die Basis gesendet, aber kein ACK erhalten und trotzdem weiter nur Änderungen geschickt, die der Client verworfen hat - Spricht dagegen: Basis mit ACK bestätigt und im Client angewandt, trotzdem unsichtbar: „Verlorene Despawn-Meldung (Geisterobjekt)“ oder „Verwechslung durch wiederverwendete Objekt-IDs“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Snapshot Compression](https://gafferongames.com/post/snapshot_compression/) · Gaffer On Games · Änderungen dürfen nur relativ zu einer Basis (baseline) erzeugt werden, deren Empfang die Gegenseite bestätigt hat (ack), der Anfangszustand wird separat gesendet - [Quake III Arena source: code/server/sv_snapshot.c](https://raw.githubusercontent.com/id-Software/Quake-III-Arena/master/code/server/sv_snapshot.c) · id Software · Delta-Kompression relativ zu dem vom Client bestätigten Snapshot, ist die Basis zu alt, wird ein vollständiger Snapshot gesendet - [tc-netem(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-netem.8.html) · iproute2 · Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden - [Using Network Emulation in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-network-emulation-in-unreal-engine) · Epic Games · Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar #### pt-ghost · Verlorene Despawn-Meldung (Geisterobjekt) · Missed despawn (ghost entity) Geht umgekehrt die Meldung „verschwunden“ verloren, bleiben bereits tote oder gegangene NPCs und Spieler nur auf dem eigenen Bildschirm stehen. - Warum → Folge → Auf dem Bildschirm: Meldungen zu Tod, Abmeldung oder Verlassen des Sichtbereichs gehen verloren oder kommen in falscher Reihenfolge an → Client hält das Objekt für noch vorhanden → Monster reagiert nicht auf Angriffe, ein Spieler, der längst weg ist, steht noch da - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: regelmäßig die „aktuelle Sichtliste“ senden. Client: Objekte löschen, die nicht in der Liste stehen, Objekte ausblenden, die sich bewegen müssten, aber lange kein Update bekommen haben. - Im Graphen: Vereinzelte Spitzen ohne Muster (Objekte, die nur noch im Client existieren) - Wo nachsehen: Die vom Server gesendete „aktuelle Sichtliste“ mit der Objektliste des Clients vergleichen, nur im Client vorhandene Objekte zählen und Sende- und Empfangslogs der Despawn-Meldungen über die Objekt-ID abgleichen - Spricht dafür: Der Server hat die Despawn-Meldung für das Geisterobjekt gesendet, aber im Client ist kein Empfang protokolliert, oder der Despawn kam vor dem Spawn an und die Reihenfolge ist vertauscht - Spricht dagegen: Das Objekt steht auch in der Sichtliste des Servers: Aufräumen auf Serverseite fehlt. Direkt nachdem ein neues Objekt mit derselben ID aufgetaucht ist: „Verwechslung durch wiederverwendete Objekt-IDs“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Nicht mehr relevante dynamische Actors werden auf dem Client gelöscht - [Object visibility (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/basics/object-visibility.html) · Unity · Wird ein Objekt ausgeblendet, despawnt und löscht dieser Client es #### pt-spawn-burst · Verlust gebündelter Spawn-Daten direkt nach dem Betreten · Initial spawn burst lost (unreliable channel, receive buffer, fragmentation) Beim Betreten einer Zone schickt der Server die Spawn-Daten von Dutzenden bis Hunderten Objekten in der Umgebung auf einmal. Gehen sie über einen Unreliable-Kanal oder läuft der Empfangspuffer über, während der Client beim Laden den Socket nicht liest, verschwindet ein Teil davon und kommt nicht wieder. - Warum → Folge → Auf dem Bildschirm: Direkt nach dem Betreten kommen Spawn-Daten gebündelt in kurzer Zeit an → Ladender Client liest den Socket spät, und der Empfangspuffer des OS läuft über, oder große UDP-Pakete werden fragmentiert und gehen schon bei einem einzigen verlorenen Fragment komplett verloren. Ein Unreliable-Kanal sendet auch nicht erneut → Nur beim langsamer ladenden Client fehlen einige NPCs. Verlässt man den Sichtbereich und kommt zurück, sind sie da - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Direkt nach Login oder Wartung, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Spawn- und Despawn-Meldungen nur über einen zuverlässigen Kanal mit garantierter Retransmission senden, Anfangsdaten aufgeteilt senden. Client: Empfang in einem vom Laden getrennten Thread, Empfangspuffer vergrößern. - Größenordnungen: Der Standardwert des UDP-Empfangspuffers auf dem PC unterscheidet sich je nach OS, liegt aber meist bei einigen Dutzend bis einigen hundert KB. Sind die Eintrittsdaten einer belebten Stadt größer, läuft er über, sobald der Socket wegen des Ladens auch nur kurz nicht gelesen wird. - Im Graphen: Ansturm direkt nach Login oder Wartung (Empfangsmenge direkt nach dem Betreten, fehlende Spawn-Meldungen) - Wo nachsehen: Zahl der direkt nach dem Betreten vom Server gesendeten Spawn-Meldungen mit der Zahl der vom Client empfangenen vergleichen und prüfen, über welchen Kanal (reliable oder unreliable) gesendet wurde. Im serverseitigen Paketmitschnitt die Datenmenge an diesen Spieler direkt nach dem Betreten und fragmentierte Pakete (Wireshark-Filter ip.flags.mf == 1 || ip.frag_offset > 0) prüfen - Spricht dafür: Weniger empfangen als gesendet, die fehlenden Meldungen liegen im gebündelten Abschnitt direkt nach dem Betreten, gesendet über einen Unreliable-Kanal oder große Pakete fragmentiert. Tritt beim langsamer ladenden Client häufiger auf - Spricht dagegen: Gesendet und empfangen gleich viele, trotzdem unsichtbar: nach dem Empfang verworfen („Verworfene Spawn-Meldungen während des Ladens“) oder Problem bei der Sichtbereichsberechnung. Fehlen unabhängig vom Betreten immer wieder: Paketverlust auf der Leitung - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Ein fragmentiertes Paket geht komplett verloren, wenn auch nur ein Fragment fehlt - [UDP vs. TCP](https://gafferongames.com/post/udp_vs_tcp/) · Gaffer On Games · UDP garantiert weder Zustellung noch Reihenfolge, verlorene Pakete muss man selbst erkennen und erneut senden - [Socket.ReceiveBufferSize Property](https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.receivebuffersize) · Microsoft · Die Standardgröße des Socket-Empfangspuffers unterscheidet sich je nach OS - [Display Filter Reference: Internet Protocol Version 4](https://www.wireshark.org/docs/dfref/i/ip.html) · Wireshark · Filtert fragmentierte IP-Pakete über ip.flags.mf (More fragments) und ip.frag_offset (Fragment Offset) #### pt-id-reuse · Verwechslung durch wiederverwendete Objekt-IDs · Entity ID reused without a generation counter Verwendet der Server beim Respawn eines getöteten NPCs dieselbe Objekt-ID erneut, hält ein Client, der zwischendurch die Despawn-Meldung verpasst hat, den neuen NPC fälschlich für den alten. - Warum → Folge → Auf dem Bildschirm: NPC stirbt und erscheint mit derselben Objekt-ID erneut → Client, der die Despawn-Meldung verpasst hat, ignoriert die Spawn-Meldung als „bereits bekanntes Objekt“ oder lässt es im toten Zustand → NPC fehlt nur auf einem Bildschirm oder liegt dort am Boden, manchmal erscheint er im Aussehen eines anderen NPCs - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Gelegentlich, zufällig, Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Objekt-IDs mit einer Generationsnummer versehen, um Wiederverwendung zu erkennen. Client: bei einer Spawn-Meldung mit bereits bekannter ID das bestehende Objekt löschen und neu erzeugen. - Im Graphen: Vereinzelte Spitzen ohne Muster (Spawn-Meldungen mit bereits bekannter ID) - Wo nachsehen: Auf dem Server Erzeugungs- und Löschzeitpunkte pro Objekt-ID (mit Generationsnummer, falls vorhanden) protokollieren und zählen, wie oft der Client eine Spawn-Meldung mit bereits bekannter ID erhalten hat und wie viele Löschungen mit Neuerzeugung beim Sichtbereichs-Update als „unverändert“ behandelt wurden - Spricht dafür: Der unsichtbare oder am Boden liegende NPC hat dieselbe ID wie ein kurz zuvor gestorbener NPC, und in der Zwischenzeit hat dieser Client die Despawn-Meldung nicht erhalten oder der Server hat weder Despawn- noch Spawn-Meldung gesendet - Spricht dagegen: IDs haben eine Generationsnummer, die auch beim Vergleich verwendet wird: nicht diese Ursache. Unsichtbar ohne wiederverwendete ID: eher verlorene Spawn-Meldung - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Mehr dazu: Das passiert auch auf Serverseite. Vergleicht der Server die Objektliste im Sichtbereich nur über IDs, wertet er einen NPC, der zwischen zwei Sichtbereichs-Updates gestorben und mit derselben ID respawnt ist, als „unverändert“ und sendet weder Despawn- noch Spawn-Meldung. Laufen die Sichtbereichs-Updates pro Spieler zeitversetzt, trifft es nur die Clients, deren Update genau in diesen Moment fällt. - Quellen: - [Entity struct (Entities 1.3)](https://docs.unity3d.com/Packages/com.unity.entities@1.3/api/Unity.Entities.Entity.html) · Unity · Ein Entity besteht aus Index und Generationsnummer (Version), so lässt sich unterscheiden, ob ein wiederverwendeter Index noch gültig ist - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · RecycleNetworkIds, NetworkIdRecycleDelay: Netzwerk-IDs werden erst nach einer Wartezeit wiederverwendet #### pt-port-collision · Kollision fester UDP-Ports · Two clients bound to the same local UDP port Ist der Client so gebaut, dass er einen festen lokalen Port verwendet, kann ein zweiter Client auf demselben PC den Port nicht nutzen oder teilt sich die Pakete mit dem ersten. - Warum → Folge → Auf dem Bildschirm: Zwei Clients wollen denselben lokalen UDP-Port öffnen (per Wiederverwendungsoption gewaltsam geteilt) → Das OS übergibt eingehende Pakete nur an einen Socket oder garantiert nicht, welcher sie bekommt. Auch Router und Server sehen beide Clients unter derselben Adresse → Ein Client bekommt keine Weltpakete, NPCs und andere Spieler sind unsichtbar oder es kommt zum Verbindungsabbruch - Symptome: Unsichtbar / Geisterobjekte, Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC / Wann: Direkt nach Login oder Wartung, Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: lokalen Port automatisch vom OS wählen lassen (bind auf Port 0). Server: Verbindungen über ein pro Verbindung ausgegebenes Session-Token unterscheiden. - Im Graphen: Nur einzelne Ausreißer (Empfangene Pakete pro Client) - Wo nachsehen: Auf dem PC des Spielers bei laufenden zwei Clients in der Eingabeaufforderung mit netstat -ano -p udp die lokalen UDP-Ports pro Spielprozess (PID) anzeigen. Auf Serverseite prüfen, ob beide Sessions mit derselben öffentlichen IP und demselben Port ankommen - Spricht dafür: Beide Spielprozesse sind an denselben lokalen Port gebunden, oder auf dem Server erscheinen beide Sessions mit derselben IP und demselben Port. Mit nur einem Client normal - Spricht dagegen: Beide Clients nutzen unterschiedliche lokale Ports, und einer verhält sich trotzdem seltsam: „Fehlerhafte Session-Zuordnung nach IP oder Gerät“ oder „Multi-Client-Beschränkung“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE](https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse) · Microsoft · Ein zweites bind auf denselben Port mit SO_REUSEADDR übernimmt den Port, und welcher Socket die Pakete bekommt, ist nicht vorhersehbar - [bind function (winsock.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-bind) · Microsoft · bind auf Port 0 weist einen eindeutigen Port aus dem dynamischen Portbereich (49152–65535) zu - [netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) · Microsoft · -a zeigt TCP- und UDP-Ports, -n numerische Adressen, -o die Prozess-ID (PID), -p udp nur UDP #### pt-session-key · Fehlerhafte Session-Zuordnung nach IP oder Gerät · Session keyed by IP or machine ID Unterscheiden der Server oder ein Zwischenserver Verbindungen anhand von IP oder Geräte-ID, werden zwei Clients auf demselben PC (gleiche öffentliche IP) als ein Spieler erkannt. - Warum → Folge → Auf dem Bildschirm: Session-Tabelle nach IP oder IP + Geräte-ID aufgebaut → Daten des zweiten Clients überschreiben die erste Session oder vermischen sich mit ihr → Ein Client sieht keine NPCs, der andere hat einen Verbindungsabbruch oder bekommt fremde Daten - Symptome: Unsichtbar / Geisterobjekte, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC, Gleicher Haushalt, Bestimmte Region oder Provider / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: auf Server und Zwischenservern Verbindungen über ein eindeutiges Session-Token pro Verbindung unterscheiden, unbedingt beheben, denn auch mehrere Personen im selben Haushalt (hinter dem NAT des Routers) und Nutzer von Mobilfunkleitungen, bei denen der Provider eine IP auf mehrere Kunden verteilt (CGNAT), haben dasselbe Problem. Client: für jeden gestarteten Client ein eigenes Session-Token verwenden. - Im Graphen: Nur einzelne Ausreißer (Gleichzeitige Sessions pro öffentlicher IP, überschriebene Sessions) - Wo nachsehen: In den Logs von Server und Zwischenservern den zur Session-Suche verwendeten Schlüssel, das Session-Token sowie IP und Port des Clients protokollieren und prüfen, ob sich die bestehende Session ändert, sobald von derselben IP eine zweite Verbindung kommt. Lässt sich mit zwei nacheinander gestarteten Clients auf demselben PC nachstellen - Spricht dafür: Sobald sich der zweite Client verbindet, ändern sich Adresse oder Charakterdaten der ersten Session, und auch andere Spieler hinter demselben Router oder derselben Mobilfunkleitung (CGNAT) haben dieselben Verbindungsabbrüche - Spricht dagegen: Zwei Sessions derselben IP bleiben mit unterschiedlichen Tokens getrennt erhalten: nicht diese Ursache. Beide Prozesse nutzen denselben lokalen Port: „Kollision fester UDP-Ports“ - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Teilen sich mehrere Kunden über NAT oder CGN eine IPv4-Adresse, lassen sich Nutzer allein anhand der IP nicht unterscheiden #### pt-multiclient · Multi-Client-Beschränkung · Multi-client restriction policy Beschränken ein Sicherheitsmodul oder eine Serverrichtlinie mehrere Clients auf einem PC, wird der Start oder Login des zweiten Clients blockiert, oder der zuerst gestartete verliert die Verbindung. Manche Spiele sperren nur Funktionen des zusätzlichen Clients. - Warum → Folge → Auf dem Bildschirm: Sicherheitsmodul erkennt Mehrfachstart, oder der Server beschränkt zusätzliche Logins vom selben Gerät → Zweiter Start oder Login wird abgelehnt oder eine Seite getrennt. Selten werden nur einige Funktionen des zusätzlichen Clients gesperrt → Kein Login oder Verbindungsabbruch auf einer Seite. In Spielen, die nur Funktionen sperren, fehlen auf einer Seite NPCs oder Shops - Symptome: Kein Login / Endlos-Laden, Unsichtbar / Geisterobjekte, Verbindungsabbruch / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: bei einer Beschränkung eine klare Hinweismeldung anzeigen, im Sicherheitsmodul eine Ausnahme für QA einrichten. Server: auch bei der Beschränkung auf ein Gerät eine Ausnahme für QA einrichten. - Im Graphen: Nur einzelne Ausreißer (Abgelehnte Logins und Trennungen nach Grund (Mehrfach-Login)) - Wo nachsehen: Meldung beim Start des zweiten Clients und Trennungsmeldung des zuerst gestarteten prüfen. Prüfen, ob in den Server-Logs zu abgelehnten Logins und Rauswürfen Grundcodes wie Mehrfach-Login oder gleiches Gerät auftauchen - Spricht dafür: Beim zweiten Start oder Login erscheint eine Ablehnungsmeldung oder der zuerst gestartete Client wird mit dem Grund Mehrfach-Login getrennt, mit nur einem Client gibt es kein Problem - Spricht dagegen: Ohne Ablehnungs- oder Trennungsgrund sind beide verbunden, aber nur einer sieht keine NPCs: „Kollision fester UDP-Ports“, „Fehlerhafte Session-Zuordnung nach IP oder Gerät“ oder Ursachen bei Laden oder Darstellung - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [CreateMutexW function (synchapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexw) · Microsoft · Existiert ein benannter Mutex bereits, liefert die Funktion ERROR_ALREADY_EXISTS, was zur Erkennung von Mehrfachstarts und zur Beschränkung auf eine Instanz genutzt wird #### pt-background · Drosselung von Hintergrundfenstern · Background window throttling Bei einem Client im Hintergrundfenster reduzieren Spiel, Engine und OS Frames und Verarbeitung. Empfangene Pakete werden nicht rechtzeitig verarbeitet, stauen sich oder laufen über. - Warum → Folge → Auf dem Bildschirm: Hintergrund-Framelimit in Spieloptionen oder Grafiktreiber (z. B. beim NVIDIA-Treiber zwischen 20 und 200 pro Sekunde einstellbar), Energiesparmodus, Engine-Einstellung zum Pausieren im Hintergrund. Auch das OS teilt dem Fenster im Vordergrund bevorzugt CPU und GPU zu → Pro Frame werden weniger Pakete verarbeitet, die Warteschlange wächst, und läuft der Empfangspuffer über, werden Pakete verworfen → Holt man das Fenster nach vorn, erscheint alles auf einmal, oder einige NPCs bleiben dauerhaft unsichtbar - Symptome: Unsichtbar / Geisterobjekte, Zeitraffer, Verbindungsabbruch / Faktoren: Stillstand, Paketverlust - Wer: Nur ein Client auf demselben PC / Wann: Nach Inaktivität, Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Netzwerkempfang in einem von der Game-Loop getrennten Thread weiterlaufen lassen, auch im Hintergrund einen Mindestdurchsatz garantieren, Einstellung der Engine für Ausführung im Hintergrund aktivieren (Unity: runInBackground). - Aufgaben Extern: Hinweis an Spieler: Hintergrund-Framelimit im Grafiktreiber und Energiesparmodus des PCs deaktivieren. - Größenordnungen: Ist in Unity runInBackground deaktiviert, hält die Game-Loop an, sobald das Fenster den Fokus verliert. Läuft der Empfang nur in dieser Loop, werden in der Zeit überhaupt keine Pakete verarbeitet. - Im Graphen: Lücke, dann alles auf einmal (Frame-Abstand im Client, verarbeitete Pakete pro Frame) - Wo nachsehen: Auf demselben PC ein Fenster im Vordergrund und das andere im Hintergrund platzieren und mit vertauschten Rollen vergleichen. Mit PresentMon den Frame-Abstand beider Prozesse messen, gibt es spielseitige Logs, Fensterfokus und verarbeitete Pakete pro Frame prüfen - Spricht dafür: Nur als Hintergrundfenster steigt der Frame-Abstand stark (bei Treiberlimit flach auf dem Abstand, der der eingestellten Framerate entspricht) oder die Verarbeitung stoppt, und beim Fensterwechsel wandert das Problem zum anderen Client - Spricht dagegen: Tritt im Vordergrundfenster genauso auf: nicht die Hintergrunddrosselung. Unabhängig von der Fensterlage immer derselbe Client: „Unterschiedliche Anzeigeoptionen“ oder „Abweichende Client-Version oder Spieldaten“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Standardwert von runInBackground ist false, die App pausiert dann im Hintergrund - [Manage 3D Settings (reference) — NVIDIA Control Panel Help](https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/mergedProjects/nv3d/Manage_3D_Settings_(reference).htm) · NVIDIA · Background Application Max Frame Rate: begrenzt die maximale Framerate von Spielen im Hintergrund auf 20–200 pro Sekunde - [Priority Boosts](https://learn.microsoft.com/en-us/windows/win32/procthread/priority-boosts) · Microsoft · Windows hebt die Priorität des Prozesses im Vordergrundfenster auf mindestens das Niveau von Hintergrundprozessen an - [PresentMon README](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README.md) · Intel · Werkzeug, das CPU-, GPU- und Display-Frametimes von Windows-Grafikanwendungen pro Anwendung erfasst #### pt-asset-lock · Zugriffskonflikte bei Cache- und Asset-Dateien · Shared cache / asset file lock conflicts Schreiben zwei Clients gleichzeitig in denselben Cache-Ordner oder sperren Dateien, kann einer von ihnen NPC-Modelle oder Texturen nicht laden. - Warum → Folge → Auf dem Bildschirm: Zwei Clients schreiben gleichzeitig in Cache- und Patchdateien desselben Installationsordners → Dateisperre schlägt fehl oder eine halb geschriebene Datei wird gelesen, Laden scheitert → Namensschild vorhanden, aber kein Charaktermodell, oder durchsichtige NPCs - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Stillstand - Wer: Nur ein Client auf demselben PC / Wann: Direkt nach Login oder Wartung, Beim Bewegen oder Zonenwechsel - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Cache-Ordner pro Client, bei fehlgeschlagener Dateisperre erneut versuchen, bei Ladefehlern zumindest ein Standardmodell anzeigen. - Im Graphen: Nur einzelne Ausreißer (Fehlgeschlagene Asset-Ladevorgänge pro Client) - Wo nachsehen: Auf dem PC des Spielers mit Process Monitor nur die Pfade von Installations- und Cache-Ordner filtern und die Ergebnisse von Öffnen und Schreiben beider Spielprozesse prüfen. Gibt es ein Client-Log, nach fehlgeschlagenen Asset-Ladevorgängen und dem Fehlercode beim Öffnen (ERROR_SHARING_VIOLATION) suchen - Spricht dafür: Das Öffnen der Datei des unsichtbaren Modells endete mit Freigabeverletzung oder fehlgeschlagener Sperre, und zur selben Zeit schrieb der andere Client in diese Datei. Mit nur einem Client oder getrennten Installations- und Cache-Ordnern verschwindet es - Spricht dagegen: Dasselbe Modell fehlt auch mit nur einem Client: beschädigte Datei oder „Abweichende Client-Version oder Spieldaten“. Datei korrekt geöffnet, aber nicht gezeichnet: „Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Creating and Opening Files](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-and-opening-files) · Microsoft · Eine ohne Freigabemodus geöffnete Datei kann von anderen Prozessen nicht geöffnet werden, es tritt ERROR_SHARING_VIOLATION auf - [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) · Microsoft · Zeichnet Dateisystem-, Registry- und Prozessaktivität in Echtzeit auf und lässt sich nach allen Feldern wie dem Pfad filtern #### pt-vram · Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM · Memory / VRAM exhaustion Teilen sich zwei Clients den Grafikspeicher, ist kein Platz für neu benötigte Modelle und Texturen, und manches wird nicht gezeichnet. - Warum → Folge → Auf dem Bildschirm: Zwei Clients teilen sich VRAM und RAM. Das OS kürzt mitunter zuerst das Grafikspeicherbudget von Hintergrundfenstern → Engine kann neue Modelle und Texturen nicht laden oder lagert sie ständig aus und wieder ein → NPCs erscheinen spät, verschwommen oder gar nicht, Ruckeln - Symptome: Unsichtbar / Geisterobjekte, Ruckeln / Faktoren: Stillstand - Wer: Nur ein Client auf demselben PC / Wann: Beim Bewegen oder Zonenwechsel, Bei großem Andrang - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Extern (Extern) - Aufgaben Entwicklungsteam: Qualität automatisch an das Speicherbudget anpassen, bei Ladefehlern ein Ersatzmodell anzeigen. - Aufgaben Extern: Hinweis an Spieler mit zwei gleichzeitig laufenden Clients: Grafikqualität senken oder Low-Spec-Modus nutzen, empfohlene VRAM- und RAM-Ausstattung nennen. - Im Graphen: Plateau am Limit (Dedizierter GPU-Speicher pro Prozess) - Wo nachsehen: Im Task-Manager des Spielers auf der Registerkarte „Details“ die Spalte „Dedizierter GPU-Speicher“ hinzufügen und die Summe beider Clients mit der VRAM-Kapazität der Grafikkarte vergleichen. Im Spiel das von DXGI QueryVideoMemoryInfo gemeldete Budget (Budget) und die aktuelle Nutzung (CurrentUsage) protokollieren - Spricht dafür: Die Summe beider Clients verläuft flach nahe der VRAM-Kapazität, und Ladefehler bei Modellen und Texturen häufen sich, sobald die aktuelle Nutzung das Budget überschreitet. Mit geringerer Qualität oder nur einem Client verschwindet es - Spricht dagegen: Unsichtbar trotz freiem VRAM: „Zugriffskonflikte bei Cache- und Asset-Dateien“ oder „Unterschiedliche Anzeigeoptionen“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Residency (Direct3D 12)](https://learn.microsoft.com/en-us/windows/win32/direct3d12/residency) · Microsoft · Das Videospeicherbudget kann beim Wechsel zu einer anderen App stark sinken, bei Überschreitung kommt es zu Stillstand oder fehlgeschlagener Erzeugung. Außerhalb des Vordergrunds ist auch die Reservierung nicht garantiert - [GPUs in the task manager](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) · Microsoft · Fügt man im Task-Manager auf der Registerkarte „Details“ Spalten hinzu, sieht man dedizierten und gemeinsam genutzten GPU-Speicher pro Prozess. Dedizierter GPU-Speicher ist das VRAM der Grafikkarte - [DXGI_QUERY_VIDEO_MEMORY_INFO structure (dxgi1_4.h)](https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_4/ns-dxgi1_4-dxgi_query_video_memory_info) · Microsoft · Budget (vom OS festgelegtes Videospeicherbudget) und CurrentUsage (aktuelle Nutzung der App). Übersteigt die Nutzung das Budget, kann es ruckeln #### pt-display-option · Unterschiedliche Anzeigeoptionen · Different display settings Unterscheiden sich Optionen wie die Begrenzung angezeigter Charaktere, ausgeblendete NPC-Namensschilder oder -Modelle oder ein Low-Spec-Modus zwischen zwei Clients, sehen sie Unterschiedliches. - Warum → Folge → Auf dem Bildschirm: Nur ein Client mit „Begrenzung angezeigter Charaktere in der Umgebung“ oder Low-Spec-Modus → Entfernte oder niedrig priorisierte NPCs werden nicht gezeichnet (korrektes Verhalten) → NPC fehlt nur auf einer Seite - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Stillstand - Wer: Nur ein Client auf demselben PC, Nur ich / Wann: Bei großem Andrang, Immer - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Kenntlich machen, dass ein Objekt per Option ausgeblendet ist, Einstellungsdateien pro Client trennen, damit sie sich nicht vermischen. - Im Graphen: Nur einzelne Ausreißer (Gezeichnete Objekte pro Client) - Wo nachsehen: Begrenzung angezeigter Charaktere, ausgeblendete Namensschilder oder Modelle und Low-Spec-Modus beider Clients nebeneinander vergleichen und einen Client an den anderen angleichen. Auch prüfen, ob beide Clients eine gemeinsame Einstellungsdatei nutzen und sich gegenseitig überschreiben - Spricht dafür: Bei gleichen Einstellungen zeigen beide Bildschirme dasselbe, und die unsichtbaren NPCs waren entfernte Objekte außerhalb der Anzeigegrenze oder niedrig priorisierte Objekte - Spricht dagegen: Auch bei identischen Einstellungen fehlt der NPC auf einer Seite: eher „Unterschiede bei Kanal, Instanz oder Phasing“ oder verlorene Spawn-Meldung - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [Changing the Quantity of Characters Displayed On-screen (FINAL FANTASY XIV UI Guide)](https://na.finalfantasyxiv.com/uiguide/faq/faq-other/setting_ch_quantity.html) · Square Enix · Mit der Einstellung zur Anzeigebegrenzung (Character and Object Quantity) lässt sich die Zahl der gezeichneten Charaktere und Objekte steuern #### pt-version · Abweichende Client-Version oder Spieldaten · Client version / data table mismatch Ist der zweite Client eine andere Installation oder nicht vollständig gepatcht, kennt er neue NPC-IDs vom Server nicht und ignoriert sie stillschweigend. - Warum → Folge → Auf dem Bildschirm: Installation in einem anderen Ordner oder während des Patchens gestarteter Client → Unbekannte NPC- oder Modell-IDs werden übersprungen → Nur neu hinzugefügte NPCs fehlen auf einer Seite - Symptome: Unsichtbar / Geisterobjekte / Faktoren: Paketverlust - Wer: Nur ein Client auf demselben PC / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Client: beim Login die Datenversion senden, bei unbekannten IDs loggen und einen Ersatz anzeigen. Server: beim Login die Datenversion prüfen, bei Abweichung Login ablehnen und auf den Patch hinweisen. - Im Graphen: Nur einzelne Ausreißer (Empfangene unbekannte IDs pro Client-Version) - Wo nachsehen: Pfad der ausführbaren Datei beider Clients sowie die auf dem Bildschirm und im Log angezeigte Client- und Datenversion vergleichen. Im Spiel die beim Login gesendete Datenversion und die Zahl übersprungener unbekannter NPC- und Modell-IDs protokollieren - Spricht dafür: Version oder Installationsordner der beiden Clients unterscheiden sich, die unsichtbaren NPCs kamen mit einem kürzlichen Patch hinzu und sind in der vollständig gepatchten Installation sichtbar - Spricht dagegen: Version und Installationsordner gleich, aber NPC fehlt auf einer Seite: „Unterschiede bei Kanal, Instanz oder Phasing“ oder Ursachen bei Laden oder Zustellung - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · Bei unterschiedlicher ProtocolVersion kommunizieren die Seiten nicht miteinander, ForceSamePrefabs prüft beim Verbindungsaufbau Unterschiede in der Prefab-Liste #### pt-priority · Sendebudget und Priorität pro Verbindung · Per-connection bandwidth budget and priority Begrenzt der Server die Sendemenge pro Verbindung und sendet Nahes zuerst, bekommen Verbindungen mit niedrigem Limit entfernte NPCs spät oder gar nicht. - Warum → Folge → Auf dem Bildschirm: An belebten Orten sendet der Server innerhalb eines Sendelimits pro Verbindung nach Wichtigkeit → Verbindungen mit niedrig geschätzter Bandbreite (z. B. Hintergrundfenster mit verspäteten Empfangsbestätigungen) schieben weiter hinten eingereihte Objekte immer wieder auf → Entfernte NPCs erscheinen nur auf einer Seite spät oder gar nicht - Symptome: Unsichtbar / Geisterobjekte, Input-Lag / Faktoren: Latenz - Wer: Nur ein Client auf demselben PC, Bestimmter Ort oder Kanal / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: Priorität aufgeschobener Objekte mit der Zeit steigern (gegen Starvation), Mindest-Update-Intervall garantieren. Client: auch im Hintergrund Empfangsbestätigungen rechtzeitig senden, damit die Bandbreitenschätzung nicht sinkt. - Im Graphen: Steigt mit Spielerzahl und Last (Aufgeschobene Objekte pro Verbindung, Sendemenge pro Verbindung) - Wo nachsehen: Auf dem Server pro Verbindung und Tick gesendete Bytes, Sendelimit (geschätzte Bandbreite), Zahl der nicht gesendeten, aufgeschobenen Objekte und Zeit seit dem letzten Senden pro Objekt protokollieren. In Unreal zeigt Networking Insights pro Verbindung die Paketgröße und die darin enthaltenen replizierten Objekte - Spricht dafür: Der unsichtbare NPC ist ein auf dieser Verbindung lange aufgeschobenes Objekt, das Limit dieser Verbindung liegt unter dem anderer, und je größer das Gedränge, desto mehr Objekte werden aufgeschoben - Spricht dagegen: Keine aufgeschobenen Objekte, und auch dieser NPC wurde rechtzeitig gesendet: Ursache in einer späteren Stufe (Empfangspuffer, Laden, Anzeigeoptionen). Alle Verbindungen am Limit: Problem bei Sendemenge oder Sichtbereichsdesign des gesamten Servers - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Ist die Bandbreite ausgelastet, werden die zu replizierenden Actors nach Priorität (Entfernung, Blickrichtung, Zeit seit der letzten Replikation) ausgewählt. Nicht jeder Actor wird jedes Mal repliziert - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Akkumulierte Priorität: Objekte, die nicht mehr ins aktuelle Paket passen, kommen ins nächste zuerst, das Bandbreitenlimit wird in Echtzeit angepasst - [Networking Insights in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-insights-in-unreal-engine) · Epic Games · Zeigt pro Verbindung die Größe gesendeter und empfangener Pakete sowie die darin enthaltenen replizierten Objekte und Eigenschaften #### pt-clock-hold · Zurückgehaltene Objekte durch falsch geschätzte Serverzeit · Clock estimate error holds or discards entities Liegt die vom Client geschätzte Serverzeit falsch, hält er gerade eingetroffene Objektdaten als „noch in der Zukunft“ zurück oder verwirft sie als „zu alt“. - Warum → Folge → Auf dem Bildschirm: Schätzung der Serverzeit weicht bei einem Client stark ab (Messung während des Ladens, Rückkehr aus dem Energiesparmodus) → Referenzzeit der Interpolation und Zeitstempel der Objektdaten passen nicht zusammen → Objekte erscheinen spät oder stehen bewegungslos da - Symptome: Unsichtbar / Geisterobjekte, Ruckeln / Faktoren: Latenz - Wer: Nur ein Client auf demselben PC / Wann: Nach Inaktivität, Direkt nach Login oder Wartung - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Zeitsynchronisation regelmäßig wiederholen und bei großer Abweichung sofort zurücksetzen, während des Ladens oder direkt nach dem Aufwachen gemessene Werte nicht verwenden. - Im Graphen: Nur einzelne Ausreißer (Fehler der geschätzten Serverzeit pro Client) - Wo nachsehen: Im Client geschätzte Serverzeit, RTT, Zeitpunkte erneuter Zeitsynchronisation und die Zahl zurückgehaltener oder verworfener Objektdaten protokollieren. Direkt nach dem Laden oder nach dem Aufwachen aus dem Energiesparmodus nachstellen - Spricht dafür: Nur beim betroffenen Client überschreitet der Schätzfehler die Reset-Schwelle (Unity: hardResetThresholdSec, Standard 0,2 s), es gibt Einträge über als zukünftig zurückgehaltene oder als veraltet verworfene Objektdaten, und nach erneuter Zeitsynchronisation ist sofort alles normal - Spricht dagegen: Schätzfehler klein und Objekte trotzdem spät: „Sendebudget und Priorität pro Verbindung“ oder Ursachen beim Laden - Prüfmittel: Logs oder Metriken aus Spielserver bzw. Client nötig - Quellen: - [NetworkTimeSystem class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkTimeSystem.html) · Unity · Übersteigt die Zeitdifferenz hardResetThresholdSec (Standard 0,2 s), wird hart angeglichen, sonst über adjustmentRatio schrittweise schneller oder langsamer nachgeführt - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · LocalTime läuft dem Server voraus, ServerTime hinterher. Bei spät eintreffenden Nachrichten kann die Wartezeit negativ werden ### Grundursachen von TCP-Retransmissions (20 Ursachen) #### rt-wireless · Verlust auf der Funkstrecke · Wi-Fi / cellular link loss 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 → Folge → Auf dem Bildschirm: Schwaches Signal oder starke Funkstörungen, Übertragungen auf der Funkstrecke scheitern mehrmals hintereinander → Über dem Wiederholungslimit des Funkgeräts (meist einige bis gut zehn Versuche) wird das Paket verworfen → Freeze für die Wartezeit bis zur TCP-Retransmission, nachfolgende Pakete warten im Empfangspuffer, danach Zeitraffer - Symptome: Freeze, Zeitraffer, Teleportieren / Faktoren: Paketverlust, Jitter - Wer: Nur ich, Gleicher Haushalt / Wann: Gelegentlich, zufällig, Beim Bewegen oder Zonenwechsel - 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: ffxiv-2021 - Quellen: - [net/wireless/core.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/wireless/core.c?h=v6.12) · Linux kernel · Standard-Wiederholungslimit im Linux-WLAN-Stack: 7 für kurze Frames, 4 für lange Frames (dot11ShortRetryLimit, dot11LongRetryLimit) - [RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks](https://www.rfc-editor.org/rfc/rfc3481) · IETF · Mobilfunknetze haben dank Retransmission auf der Sicherungsschicht wenig IP-Verlust, die Wiederherstellung zeigt sich aber als Jitter und Latenzsprünge - [Wi-Fi roaming support in Apple devices](https://support.apple.com/guide/deployment/wi-fi-roaming-support-dep98f116c0f/web) · 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 - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · Definition von RACK (zeitbasierte Verlusterkennung) und TLP (erneutes Senden des letzten Pakets) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · 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 - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_NODELAY schaltet den Nagle-Algorithmus ab, auch kleine Datenmengen werden sofort gesendet - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · RTO-Minimum TCP_RTO_MIN = 200 ms - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · ss -ti zeigt retrans:laufende/kumulierte Retransmissions und rtt:RTT/RTT-Abweichung (rttvar) #### rt-queue-drop · Warteschlangenüberlauf am Engpass (Verlust durch Überlast) · Tail drop at a congested bottleneck Ist die Warteschlange an der engsten Stelle voll, etwa am Router, am Übergabepunkt zwischen Providern oder an der Leitung des Rechenzentrums, werden neu ankommende Pakete verworfen. - Warum → Folge → Auf dem Bildschirm: Videos, Downloads oder Traffic anderer Nutzer füllen den Engpass → Solange die Warteschlange voll ist, werden neu ankommende Pakete nacheinander verworfen (Tail Drop). Auch die nicht verworfenen Pakete warten am Ende der vollen Warteschlange → Mehrere Pakete verschwinden auf einmal: langer Freeze, dann Zeitraffer, häufig abends - Symptome: Freeze, Zeitraffer, Rubberbanding / Faktoren: Paketverlust, Latenz - Wer: Gleicher Haushalt, Bestimmte Region oder Provider, Ganzer Server / Wann: Abendliche Stoßzeit, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Extern (Extern), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Bei gehäuften Verlusten oder sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen (mit Hinweis auf mögliche große Übertragungen über dieselbe Leitung). - Aufgaben Infrastrukturteam: Reserven auf der Leitung des Rechenzentrums schaffen, Zähler für in der Warteschlange verworfene Pakete (output drops) an den eigenen Leitungen und Switch-Ports prüfen, bei verstopfter Providerstrecke über andere Leitungen oder Peerings umleiten. - Aufgaben Extern: Spieler auf SQM (fq_codel, CAKE) und ECN am Router hinweisen (damit die Senderate sinkt, bevor die Warteschlange überläuft), beim Provider einen Ausbau des Engpasses anfragen. - Größenordnungen: Im Moment des Überlaufs verschwindet einige Dutzend ms lang ein großer Teil der ankommenden Pakete auf einmal. Weil Pakete in Folge verloren gehen und dabei leicht auch die Retransmission verloren geht, läuft es oft auf ein RTO hinaus. - Im Graphen: Nur zu bestimmten Tageszeiten hoch (Retransmission-Rate, RTT (Ping)) - Wo nachsehen: Retransmission-Rate des Servers (Zuwachs von TcpRetransSegs ÷ TcpOutSegs, nstat im Minutentakt) und RTT pro Verbindung nach Region, Provider und Tageszeit aufschlüsseln, dazu verworfene ausgehende Pakete (ifOutDiscards) an den eigenen Leitungen und Switch-Ports prüfen. mtr zur betroffenen Region zur Stoßzeit und zu ruhigen Zeiten aufzeichnen und vergleichen - Spricht dafür: Retransmission-Rate steigt nur in der abendlichen Stoßzeit, kurz vor dem Verlust steigt zuerst die RTT (die Warteschlange füllt sich). In mtr nehmen nur zur Stoßzeit ab einem bestimmten Hop bis zum Ziel Verlust und Latenz gemeinsam zu - Spricht dagegen: RTT steigt vor dem Verlust nicht: „Policer verwirft Überschuss“. Verlust unabhängig von der Tageszeit immer ähnlich: „Physische Fehler“ oder „Routenwechsel oder defekter ECMP-Pfad“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: riot-direct-2015 - Quellen: - [RFC 7567: IETF Recommendations Regarding Active Queue Management](https://www.rfc-editor.org/rfc/rfc7567) · IETF · Tail Drop hält Warteschlangen lange voll, erhöht so die Latenz und verursacht gehäufte Verluste, dazu Empfehlungen für AQM - [RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm](https://www.rfc-editor.org/rfc/rfc8290) · IETF · fq_codel: hält Warteschlangen mit Queues pro Flow und AQM kurz und verringert so Bufferbloat - [RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP](https://www.rfc-editor.org/rfc/rfc3168) · IETF · ECN: meldet Überlast per Markierung im IP-Header, ohne Pakete zu verwerfen - [Smart Queue Management](https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/) · Bufferbloat.net · SQM: kombiniert Scheduling pro Flow, Verwaltung der Warteschlangenlänge (AQM) und Shaping - [Cake](https://www.bufferbloat.net/projects/codel/wiki/Cake/) · Bufferbloat.net · CAKE: SQM für Router, das einen Shaper mit einer Warteschlangenverwaltung nach Art von fq_codel kombiniert - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · In nstat angezeigte TcpRetransSegs und TcpOutSegs (RetransSegs und OutSegs im Abschnitt Tcp) - [nstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/nstat.8.html) · iproute2 · nstat zeigt standardmäßig den Zuwachs seit dem letzten Aufruf - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifOutDiscards: Zahl ausgehender Pakete, die verworfen wurden, obwohl kein Fehler vorlag, etwa um Pufferplatz freizumachen - [An Internet-Wide Analysis of Traffic Policing](https://research.google/pubs/an-internet-wide-analysis-of-traffic-policing/) · Google · Unterscheidung: Bei Warteschlangenüberlauf steigen vor dem Verlust zuerst Wartezeit und RTT, Policing verwirft den Überschuss ohne RTT-Anstieg (SIGCOMM 2016) #### rt-burst · Überlauf flacher Puffer durch Sende-Bursts · Sender bursts overflow shallow buffers 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 → Folge → Auf dem Bildschirm: Zu Beginn jedes Ticks gehen die Pakete für alle Spieler auf einmal raus → 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) → Teleportieren oder kurzer Freeze bei mehreren Spielern gleichzeitig, Durchschnittsmetriken zeigen die Ursache nicht - Symptome: Teleportieren, Freeze, Zeitraffer / Faktoren: Paketverlust - Wer: Bestimmter Ort oder Kanal, Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Netzwerk-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: 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 Microbursts](https://research.facebook.com/publications/high-resolution-measurement-of-data-center-microbursts/) · Meta · Ü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 page](https://man7.org/linux/man-pages/man8/tc-fq.8.html) · iproute2 · 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.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_bbr.c?h=v6.12) · Linux kernel · BBR legt pacing_rate anhand der geschätzten Engpass-Bandbreite fest und sendet danach - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux 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 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · 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 MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifOutDiscards: Zahl ausgehender Pakete, die verworfen wurden, obwohl kein Fehler vorlag, etwa um Pufferplatz freizumachen - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Zeigt pro Retransmission eine Zeile mit Adresse und Port der Gegenseite und dem Verbindungszustand #### rt-policer · Policer verwirft Überschuss · Traffic policing Provider-Tarife, Limits von Cloud-Instanzen und DDoS-Schutzgeräte verwerfen Pakete oberhalb einer festgelegten Rate teils sofort, ohne sie in eine Warteschlange zu stellen. - Warum → Folge → Auf dem Bildschirm: Kurzfristige Sendemenge überschreitet erlaubte Rate oder erlaubten Burst → Überschüssige Pakete werden ohne Warteschlange sofort verworfen (Policing) → In Momenten mit großem Burst verschwinden mehrere Pakete: Freeze, danach Zeitraffer, die Durchschnittsrate liegt scheinbar unter dem Limit - Symptome: Freeze, Zeitraffer, Teleportieren / Faktoren: Paketverlust - Wer: Ganzer Server, Bestimmte Region oder Provider, Nur ich / Wann: Bei großem Andrang, Abendliche Stoßzeit - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Die gebündelte Sendemenge jedes Ticks über den Tick verteilen und so die kurzfristige Sendemenge unter den erlaubten Burst drücken, bei Erreichen eines PPS-Limits die Nachrichten eines Ticks in einem Paket zusammenfassen. - Aufgaben Infrastrukturteam: Netzwerk: Überschreitungszähler der Policer an den Geräten prüfen, Policer durch Shaper ersetzen, erlaubten Burst erhöhen. Server/OS: Metriken für Überschreitungen der Cloud-Limits prüfen (bei AWS bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S), größere Instanz wählen, Pacing auf dem Server (Linux-fq-Queue). - Größenordnungen: Ein Shaper (stellt Pakete in eine Warteschlange und verzögert sie) erhöht die Latenz, ein Policer (verwirft sofort) erhöht den Paketverlust. Eine TCP-Spielverbindung kann bei einem einzigen Verlust mehrere hundert ms stillstehen. Wird das Limit nur kurz überschritten, wirkt sich daher meist der Policer stärker aus. - Im Graphen: Plateau am Limit (Sendemenge in kurzen Intervallen, Überschreitungszähler von Policer und allowance) - Wo nachsehen: Überschreitungs- (exceed) und Drop-Zähler des Geräts mit dem Policer prüfen, in der Cloud bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S. Bei Verbindungen mit Verlust die RTT unmittelbar vor dem Verlust anhand von rtt in ss -ti oder per Paketmitschnitt prüfen - Spricht dafür: Überschreitungszähler steigen, die in kurzen Intervallen gemessene Sendemenge verläuft bei einem bestimmten Wert flach wie abgeschnitten. Vor dem Verlust steigt die RTT nicht, nur in Momenten mit großem Burst verschwinden mehrere Pakete auf einmal - Spricht dagegen: Vor dem Verlust steigt zuerst die RTT: Warteschlangenüberlauf („Warteschlangenüberlauf am Engpass“, „Überlauf flacher Puffer durch Sende-Bursts“). Überschreitungszähler unverändert: andere Ursache - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 2475: An Architecture for Differentiated Services](https://www.rfc-editor.org/rfc/rfc2475) · IETF · Definition: Shaping verzögert Pakete, bis sie dem Traffic-Profil entsprechen, Policing verwirft Pakete, die das Profil überschreiten - [An Internet-Wide Analysis of Traffic Policing](https://research.google/pubs/an-internet-wide-analysis-of-traffic-policing/) · Google · Übertragungen mit Policing haben im Schnitt eine 6-mal höhere Verlustrate, dasselbe Ziel lässt sich mit Pacing oder Shaping erreichen. Unterscheidung: Policing verwirft den Überschuss ohne RTT-Anstieg, bei Warteschlangenüberlauf steigt die RTT vor dem Verlust (SIGCOMM 2016) - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S: Zahl der Pakete, die wegen Überschreitung der Instanzlimits in die Warteschlange gestellt oder verworfen wurden - [tc-fq(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-fq.8.html) · iproute2 · Pacing pro Verbindung in der Linux-fq-Queue - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rtt (mittlere Umlaufzeit) bei ss -i #### rt-physical · Physische Fehler (defekte Kabel, optische Module, Stecker) · Bit errors: bad cable, optics, dirty fiber Beschädigte Kabel, verschmutzte optische Stecker und gealterte optische Module verursachen Bitfehler, und beschädigte Pakete verwerfen die Geräte stillschweigend. - Warum → Folge → Auf dem Bildschirm: Defekte Kabel, optische Module oder Stecker kippen Bits → Gerät verwirft Pakete mit falscher Prüfsumme (CRC) → Nur Spieler auf dieser Route: immer wieder kurzer Freeze, dann Zeitraffer, unabhängig von der Tageszeit - Symptome: Freeze, Zeitraffer, Teleportieren / Faktoren: Paketverlust - Wer: Bestimmter Ort oder Kanal, Gleicher Haushalt / Wann: Immer - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Extern (Extern) - Aufgaben Infrastrukturteam: CRC-Fehler sammeln sich auf der Empfangsseite der betroffenen Richtung, daher beide Enden prüfen. Netzwerk: CRC- und Eingangsfehlerzähler der Geräteports prüfen, optische Signalstärke kontrollieren (Transceiver-Informationen des Switches), optische Stecker reinigen, Kabel oder optische Module tauschen. Server/OS: rx_crc_errors in ethtool -S auf dem Server prüfen (Name je nach Treiber leicht unterschiedlich), optische Signalstärke kontrollieren (ethtool -m), Kabel oder NIC auf Serverseite tauschen. - Aufgaben Extern: Liegt es am Heimnetz des Spielers, auf den Tausch von LAN-Kabel oder Router hinweisen, liegt es an der Providerleitung, beim Provider eine Leitungsprüfung anfragen. - Größenordnungen: Auch 0,1 % Verlust trifft eines von 1.000 Spielpaketen. Laufen einige Dutzend Spieler über diese Route, stockt alle paar Sekunden bei irgendwem das Spiel. Bitfehler treffen große Pakete häufiger. - Im Graphen: Nur einzelne Ausreißer (CRC-Fehler pro Port, Retransmission-Rate pro Server und Port) - Wo nachsehen: CRC-Zähler an beiden Enden des Links prüfen. Auf dem Server rx_crc_errors in ethtool -S oder crc in ip -s -s link, am Switch FCS-Fehler (dot3StatsFCSErrors) und Eingangsfehler (ifInErrors) des Ports. Bei optischen Links die empfangene Lichtleistung mit ethtool -m und den Transceiver-Informationen des Switches prüfen - Spricht dafür: CRC-Fehler eines Ports steigen unabhängig von der Tageszeit stetig, nur Server und Verbindungen über diesen Port haben eine hohe Retransmission-Rate. Empfangene Lichtleistung niedriger als bei gleichartigen anderen Links - Spricht dagegen: CRC unverändert, nur verworfene ausgehende Pakete steigen: Warteschlangenüberlauf („Überlauf flacher Puffer durch Sende-Bursts“, „Warteschlangenüberlauf am Engpass“). Steigen auf der einen Seite späte Kollisionen und auf der anderen CRC-Fehler: „Duplex-Mismatch“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · rx_crc_errors ist die Zahl der Pakete, die die empfangende Schnittstelle als CRC-Fehler gezählt hat, Prüfung mit ip -s -s link und ethtool -S - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · -S zeigt Statistiken pro NIC und Treiber, -m das EEPROM und die optischen Diagnosedaten von Transceivern (SFP+, QSFP) - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · FCS-Fehler eines Switch-Ports (dot3StatsFCSErrors), diese Fehler werden in die Eingangsfehler (ifInErrors) eingerechnet #### rt-duplex · Duplex-Mismatch · Duplex mismatch 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 → Folge → Auf dem Bildschirm: Nur auf einer Seite sind Geschwindigkeit und Duplex fest eingestellt → Eine Seite arbeitet im Vollduplex, die andere im Halbduplex, es kommt zu Kollisionen und späten Kollisionen → Normalerweise unauffällig, bei steigendem Traffic für alle Spieler über dieses Gerät: Freeze, dann Zeitraffer - Symptome: Freeze, Zeitraffer / Faktoren: Paketverlust - Wer: Ganzer Server, Bestimmter Ort oder Kanal / Wann: Bei großem Andrang, Abendliche Stoßzeit - 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: - [Linux Base Driver for Intel(R) Ethernet Network Connection](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000.html) · Linux kernel · Der Standard 1000BASE-T schreibt Autonegotiation vor - [IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives](https://www.ieee802.org/3/ae/objectives.pdf) · IEEE · 10-Gigabit-Ethernet unterstützt nur Vollduplex - [IEEE P802.3ba Objectives](https://www.ieee802.org/3/ba/PAR/P802.3ba_Objectives_0709.pdf) · IEEE · Auch 40- und 100-Gigabit-Ethernet unterstützen nur Vollduplex - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · 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 - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Geschwindigkeit, Duplex und Autonegotiation über speed, duplex und autoneg bei ethtool -s einstellen, nur mit dem Schnittstellennamen zeigt ethtool die aktuelle Einstellung - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · dot3StatsDuplexStatus (zeigt den aktuellen Duplex als halfDuplex oder fullDuplex), dot3StatsLateCollisions (Zahl später Kollisionen) #### rt-host-drop · Verworfene Pakete auf dem empfangenden Server-Host · Receiver host drops (ring, softirq, CPU) Die Pakete erreichen den Server, werden aber verworfen, weil der Ringpuffer der NIC (ein Puffer, der ankommende Pakete kurz zwischenspeichert) überläuft oder der CPU-Kern, auf dem der Kernel den Empfang verarbeitet, voll ausgelastet ist. - Warum → Folge → Auf dem Bildschirm: Ansturm von Spielern, Interrupts auf einem einzigen Kern, CPU-Steal in der VM oder überlasteter virtueller Switch → Verworfen im Ringpuffer (rx_missed_errors o. Ä., Name je nach Treiber) oder in der Empfangswarteschlange des Kernels (softnet dropped) → Bei großem Andrang auf dem ganzen Server gleichzeitig Input-Lag und kurze Freezes - Symptome: Input-Lag, Freeze, Zeitraffer, Teleportieren / Faktoren: Paketverlust, Stillstand - Wer: Ganzer Server / Wann: Bei großem Andrang - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Drop-Zähler wie rx_missed_errors in ethtool -S und dropped in /proc/net/softnet_stat ins Monitoring aufnehmen, Ringpuffer vergrößern (ethtool -G), RSS und Interrupts auf mehrere Kerne verteilen, Game-Thread und Empfangsverarbeitung auf getrennte Kerne legen, CPU-Reserven schaffen, bei VMs CPU-Steal und Last des virtuellen Switches prüfen. - Größenordnungen: Pakete, die der Server beim Empfang verwirft, sendet der Client erneut. Deshalb tauchen sie in den Retransmission-Metriken des Servers kaum auf und zeigen sich zuerst in Drop-Zählern wie rx_missed_errors in ethtool -S (Name je nach Treiber) und in dropped in /proc/net/softnet_stat. - Im Graphen: Plateau am Limit (softirq-Auslastung pro Kern, Drop-Zähler der NIC) - Wo nachsehen: Drop-Zähler in ethtool -S (rx_missed_errors o. Ä., bei mlx5 rx_out_of_buffer und rx_discards_phy), missed in ip -s -s link sowie 2. Spalte (dropped) und 3. Spalte (time_squeeze) von /proc/net/softnet_stat prüfen, mit mpstat -P ALL %soft (Verarbeitung von Soft-Interrupts) pro Kern ansehen. Bei VMs auch %steal - Spricht dafür: Zu Zeiten großen Andrangs steigen Drop-Zähler oder softnet dropped, %soft des Kerns für die Empfangsverarbeitung verharrt nahe 100 %. Auf allen Verbindungen dieses Servers verzögern sich Eingaben gleichzeitig - Spricht dagegen: Drop-Zähler des Servers unverändert, Retransmissions häufen sich bei Verbindungen bestimmter Regionen oder Provider: Verlust auf der Route. Gehen vom Server gesendete Pakete unterwegs verloren, steigt TcpRetransSegs in nstat auf dem Server, diese Zähler bleiben unverändert - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · rx_missed_errors ist die Zahl der Pakete, die der Host mangels Puffer nicht annehmen konnte (in /proc/net/dev unter drop mitgezählt), Prüfung mit ip -s -s link - [drivers/net/ethernet/intel/igb/igb_ethtool.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_ethtool.c?h=v6.12) · Linux kernel · Die Zählernamen in ethtool -S legt der Treiber fest (z. B. rx_missed_errors und rx_no_buffer_count bei igb) - [Ethtool counters](https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/counters.html) · Linux kernel · rx_out_of_buffer (kein Puffer in der Empfangs-Queue) und rx_discards_phy (verworfen wegen zu wenig Portpuffer) im mlx5-Treiber - [net/core/net-procfs.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/net-procfs.c?h=v6.12) · Linux kernel · /proc/net/softnet_stat hat eine Zeile pro CPU in Hexadezimal, die 2. Spalte ist dropped, die 3. Spalte time_squeeze - [Documentation for /proc/sys/net/](https://docs.kernel.org/admin-guide/sysctl/net.html) · Linux kernel · netdev_max_backlog: Obergrenze der Empfangswarteschlange für Pakete, die schneller ankommen, als der Kernel sie verarbeitet - [Scaling in the Linux Networking Stack](https://docs.kernel.org/networking/scaling.html) · Linux kernel · RSS: Die NIC verteilt den Empfang auf mehrere Empfangs-Queues, die auf mehreren CPUs verarbeitet werden - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Größe des Ringpuffers mit -G (--set-ring) ändern - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal in /proc/stat: Zeit, in der in virtualisierten Umgebungen ein anderes Betriebssystem die CPU genutzt hat - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · mpstat -P ALL zeigt die Auslastung pro Kern, %soft ist die Zeit für Soft-Interrupts, %steal die Wartezeit, während der Hypervisor andere virtuelle CPUs bediente - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · In nstat angezeigtes TcpRetransSegs (RetransSegs im Abschnitt Tcp) #### rt-stateful-fw · Verworfene Pakete in Firewall und Connection Tracking · Stateful firewall / conntrack drops Firewalls und das Linux-Connection-Tracking (conntrack, eine Funktion, die durchlaufende Verbindungen in einer Tabelle vermerkt) verwerfen Pakete, wenn die Tabelle voll ist oder der Verbindungszustand nicht zu passen scheint. - Warum → Folge → Auf dem Bildschirm: Connection-Tracking-Tabelle voll (table full), oder Hin- und Rückweg verlaufen verschieden und nur eine Richtung passiert die Firewall (asymmetrische Route) → Firewall wertet Pakete als „unbekannte Verbindung“ oder „Sequenznummer außerhalb des Windows“ und verwirft sie → Ist die Tabelle voll, scheitern neue Verbindungen. Weicht die Route ab, trifft es nur die Spieler auf dieser Route: wiederholte Retransmissions, am Ende Verbindungsabbruch - Symptome: Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Ganzer Server, Bestimmte Region oder Provider / Wann: Bei großem Andrang, Direkt nach Login oder Wartung, Gelegentlich, zufällig - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: für den Fall einer vollen Tabelle den Login-Andrang über ein Login-Warteschlangensystem steuern, Verbindungen wiederverwenden, damit nicht ständig kurze Verbindungen entstehen (auch bei Aufrufen zwischen Servern), Verbindungen ohne Heartbeat selbst aufräumen. Client: bei gescheitertem Login oder Verbindungsabbruch mit wachsenden Abständen und zufälliger Streuung neu versuchen (damit bei voller Tabelle nicht alle gleichzeitig zurückkommen). - Aufgaben Infrastrukturteam: Netzwerk: Connection-Tracking-Tabelle der Firewall vergrößern, Spielports vom Connection Tracking ausnehmen, Routing so anpassen, dass Hin- und Rückweg dieselbe Firewall passieren, Einstellung der TCP-Window-Prüfung der Firewall kontrollieren. Server/OS: Linux-Tabelle vergrößern (nf_conntrack_max), Spielports vom Connection Tracking ausnehmen (NOTRACK), Einstellung der TCP-Window-Prüfung kontrollieren (nf_conntrack_tcp_be_liberal), bei AWS auch conntrack_allowance_exceeded prüfen. - Größenordnungen: Das Standardlimit von Linux-conntrack (nf_conntrack_max) liegt je nach Arbeitsspeicher bei einigen Zehntausend bis einigen Hunderttausend Einträgen. Erreicht die aktuelle Zahl (nf_conntrack_count) das Limit, steht im Log „nf_conntrack: table full, dropping packet“. - Im Graphen: Plateau am Limit (Zahl der conntrack-Einträge (nf_conntrack_count), gescheiterte neue Verbindungen) - Wo nachsehen: Auf Linux-Servern nf_conntrack_count und nf_conntrack_max, „nf_conntrack: table full, dropping packet“ in dmesg sowie drop und invalid in /proc/net/stat/nf_conntrack (eine Zeile pro Kern, hexadezimal) prüfen. An der Firewall Auslastung der Session-Tabelle und Drop-Logs prüfen, bei AWS conntrack_allowance_exceeded in ethtool -S - Spricht dafür: Zahl der Einträge verläuft flach am Limit, gleichzeitig steigen table-full-Logs und drop oder conntrack_allowance_exceeded. Bei asymmetrischer Route ist am Limit noch Luft, aber invalid und Drop-Logs der Firewall steigen bei Verbindungen über eine bestimmte Route - Spricht dagegen: Zahl der Einträge weit unter dem Limit, invalid und Drop-Logs unverändert: andere Ursache. Tabelle hat Luft, aber CPU oder PPS der Firewall sind am Anschlag: „Überschrittenes Verarbeitungslimit von Zwischengeräten“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Standardwert von nf_conntrack_max ist die Zahl der Hash-Buckets (Arbeitsspeicher ÷ 16384, 1024–262144), aktuelle Zahl in nf_conntrack_count, nf_conntrack_tcp_be_liberal stuft nur RSTs außerhalb des Windows als INVALID ein - [net/netfilter/nf_conntrack_core.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_core.c?h=v6.12) · Linux kernel · Bei voller Tabelle wird „nf_conntrack: table full, dropping packet“ geloggt und das Paket verworfen (drop-Statistik steigt), bei Paketen, die nicht zum Verbindungszustand passen, steigt die invalid-Statistik - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · Mit CT --notrack in der raw-Tabelle vom Connection Tracking ausnehmen - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Wird das Limit verfolgter Verbindungen pro Instanz überschritten, werden Pakete verworfen, Prüfung über conntrack_allowance_exceeded, Empfehlung, asymmetrische Routen zu vermeiden - [net/netfilter/nf_conntrack_standalone.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_standalone.c?h=v6.12) · Linux kernel · /proc/net/stat/nf_conntrack hat eine Zeile pro Kern in Hexadezimal mit Spalten wie entries, invalid, insert_failed, drop und early_drop #### rt-appliance-pps · Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz) · Inline appliance PPS / CPU overload Firewalls, Intrusion-Prevention-Systeme (IPS) und DDoS-Schutzgeräte prüfen jedes durchlaufende Paket einzeln. Sobald ihre Prüfkapazität überschritten ist, verwerfen sie die Pakete, die sie nicht mehr verarbeiten können. - Warum → Folge → Auf dem Bildschirm: Zur Stoßzeit oder bei Events kommen pro Sekunde mehrere hunderttausend und mehr kleine Spielpakete zusammen, oder die Prüfregeln sind aufwendig → CPU- oder PPS-Limit des Geräts erreicht, das Gerät verwirft Pakete. Bei False Positives werden auch legitime Pakete blockiert → Freeze oder Teleportieren auf allen Servern hinter dem Gerät gleichzeitig, verschärft sich nur bei großem Andrang - Symptome: Freeze, Zeitraffer, Teleportieren, Verbindungsabbruch / Faktoren: Paketverlust, Latenz - Wer: Ganzer Server, Bestimmte Region oder Provider / Wann: Abendliche Stoßzeit, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Traffic-Muster des Spiels (Ports, Paketgrößen, PPS) mit dem Infrastrukturteam teilen, kleine Nachrichten eines Ticks sammeln und gebündelt senden, um die Paketzahl zu senken. - Aufgaben Infrastrukturteam: CPU, PPS und Drop-Zähler der Geräte zusammen mit den Spielmetriken betrachten, Gerätekapazität auf Basis kleiner Pakete planen, Spielports von aufwendigen Prüfungen ausnehmen, DDoS-Schutzregeln an die Traffic-Muster des Spiels anpassen. - Größenordnungen: Die „10 Gbps“ im Datenblatt beziehen sich oft auf große Pakete mit 1.500 Byte. Spielpakete mit etwa 100 Byte ergeben bei derselben Bandbreite mehr als 10-mal so viele Pakete. Auch wenn die Leitung ruhig aussieht, ist daher zuerst das PPS-Limit erreicht. - Im Graphen: Plateau am Limit (PPS und CPU-Auslastung des Geräts, Drops am Gerät) - Wo nachsehen: CPU, PPS und Drop-Zähler des Geräts prüfen, Paketzahlen an den Switch-Ports vor und hinter dem Gerät im selben Intervall vergleichen. Zusammen mit der Zahl gleichzeitiger Spieler und der Retransmission-Rate des Servers in einer Ansicht überlagern - Spricht dafür: Zu Stoßzeiten oder bei Events kommen PPS oder CPU des Geräts über einen bestimmten Wert nicht hinaus, aus dem Gerät kommen weniger Pakete heraus als hinein, und gleichzeitig steigt die Retransmission-Rate aller Server dahinter - Spricht dagegen: Paketzahl vor und hinter dem Gerät gleich, keine Drops am Gerät: andere Ursache. Steigen auf dem 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) - Quellen: - [RFC 2544: Benchmarking Methodology for Network Interconnect Devices](https://www.rfc-editor.org/rfc/rfc2544) · IETF · Die Geräteleistung muss mit mehreren Frame-Größen einschließlich Minimal- und Maximalgröße getestet werden (die Verarbeitungsleistung hängt von der Paketgröße ab) #### rt-mtu · MTU-Blackhole (nur große Pakete gehen wiederholt verloren) · PMTU black hole Ist die zulässige Paketgröße auf einem Abschnitt der Strecke kleiner geworden und wird die Meldung „Paket zu groß“ (ICMP) blockiert, verschwinden große Pakete immer wieder, egal wie oft sie erneut gesendet werden. - Warum → Folge → Auf dem Bildschirm: Auf VPN- oder Tunnelstrecken sinkt die maximale Größe, und eine Firewall blockiert die Meldung über die Überschreitung → Der Sender kennt den Grund nicht und sendet dasselbe große Paket immer wieder, das RTO verdoppelt sich jedes Mal → Normalerweise unauffällig, aber sobald große Datenmengen fließen (Inventar, volle Orte, Laden beim Betreten), hängen auch alle nachfolgenden kleinen Pakete fest: Freeze, am Ende Verbindungsabbruch oder Endlos-Laden - Symptome: Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Bestimmte Region oder Provider, Nur ich / Wann: Bei bestimmten Aktionen, Direkt nach Login oder Wartung - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Soll die Größe serverseitig gesenkt werden, die maximale Segmentgröße des Sockets (TCP_MAXSEG) setzen. Nachrichten im Spielcode klein zu stückeln reicht nicht (TCP packt die zu sendenden Daten wieder zu Segmenten in MSS-Größe zusammen). - Aufgaben Infrastrukturteam: Netzwerk: MSS-Clamping an den Grenzgeräten, ICMP für Größenüberschreitung (Typ 3 Code 4, fragmentation needed) in Firewalls und Netzwerk-ACLs der Cloud erlauben. Server/OS: Path-MTU einstellen, prüfen, dass auch Server-Firewall und Cloud-Security-Groups ICMP für Größenüberschreitung nicht blockieren, als letztes Sicherheitsnetz tcp_mtu_probing=1 unter Linux. - Größenordnungen: Meist 1.500 Byte, nach einem Tunnel um die 1.400. Wird dasselbe Paket 5- bis 6-mal erneut gesendet, dauert der Stillstand über 10 s. - Im Graphen: Nur einzelne Ausreißer (RTO und Backoff pro Verbindung, Verbindungsabbrüche nach Region und Provider) - Wo nachsehen: Retransmissions der betroffenen Verbindung per Paketmitschnitt auf dem Server oder mit bcc tcpretrans -s (zeigt Sequenznummern) prüfen, mit ss -ti mss, pmtu und backoff dieser Verbindung ansehen. Vom Server aus einen kleinen Ping und einen 1.500-Byte-Ping mit gesetztem DF (ping -M do -s 1472) an die Adresse des Spielers senden und vergleichen - Spricht dafür: Ein bis zur MSS gefülltes Paket wird mit derselben Sequenznummer und jeweils doppeltem Abstand immer wieder gesendet, kleinere Pakete kommen durch. Kein ICMP für Größenüberschreitung (Wireshark-Filter icmp.type == 3 and icmp.code == 4), der kleine Ping wird beantwortet, nur der große DF-Ping verschwindet ohne Antwort - Spricht dagegen: Auch kleine Pakete verschwinden: größenunabhängiger Verlust („Warteschlangenüberlauf am Engpass“, „Routenwechsel oder defekter ECMP-Pfad“). Kommt ICMP für Größenüberschreitung an und sinkt pmtu in ss -ti, funktioniert die Path MTU Discovery korrekt - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Mit tcp_mtu_probing=1 wird erst nach einigen Sekunden aufeinanderfolgender Retransmission-Timeouts (entspricht tcp_retries1=3) ein Blackhole angenommen und die MSS auf 1.024 Byte gesenkt. Bis dahin steht alles still. Das ist daher nur das letzte Sicherheitsnetz, Vorrang hat die vorbeugende MSS-Anpassung. - Quellen: - [RFC 1191: Path MTU discovery](https://www.rfc-editor.org/rfc/rfc1191) · IETF · Path MTU Discovery: Zu große Pakete werden per ICMP „fragmentation needed and DF set“ (Typ 3 Code 4) gemeldet - [RFC 2923: TCP Problems with Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc2923) · IETF · Problem des PMTU-Blackholes, bei dem wegen blockiertem ICMP nur große Pakete immer wieder verschwinden - [RFC 4821: Packetization Layer Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc4821) · IETF · Verfahren, bei dem die Transportschicht die Paketgröße ohne ICMP ermittelt (Grundlage von tcp_mtu_probing unter Linux) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_mtu_probing: 0 aus, 1 nur bei erkanntem Blackhole, 2 immer (Start-MSS ist tcp_base_mss). tcp_retries1 standardmäßig 3 - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · Folgen tcp_retries1 RTO-Retransmissions aufeinander, gilt das als erkanntes Blackhole, MTU-Probing wird aktiviert und die MSS gesenkt - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_BASE_MSS = 1024 Byte - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Bei jedem Ablauf des Retransmission-Timers wird das RTO verdoppelt - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · TCPMSS --clamp-mss-to-pmtu: umgeht das Hängenbleiben großer Pakete an Abschnitten, die ICMP blockieren, durch Anpassung der MSS im SYN - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_MAXSEG: maximale Segmentgröße ausgehender Pakete, vor dem Verbindungsaufbau gesetzt ändert sie auch die der Gegenseite gemeldete MSS - [Network maximum transmission unit (MTU) for your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html) · AWS · Internet-Gateway und VPN haben MTU 1.500, PMTUD braucht ICMP Typ 3 Code 4, das nicht ankommt, wenn Security Groups oder Netzwerk-ACLs es blockieren - [MTU considerations | Cloud VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/mtu-considerations) · Google Cloud · MTU des Cloud-VPN-Gateways 1.460 Byte, Payload-MTU eines IPv4-Tunnels 1.406 Byte (nach dem Tunnel um die 1.400) - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Zeigt eine Zeile pro Retransmission, -s gibt zusätzlich die Sequenznummer des erneut gesendeten Pakets aus - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · mss, pmtu (Path-MTU) und backoff (wie oft sich das RTO verdoppelt hat) bei ss -i - [ping(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ping.8.html) · iputils · -M do setzt DF und sendet keine Pakete, die größer als die dem Kernel bekannte Path-MTU sind, -s ist die Datengröße (ICMP-Header mit 8 Byte kommt hinzu) - [Display Filter Reference: Internet Control Message Protocol](https://www.wireshark.org/docs/dfref/i/icmp.html) · Wireshark · Anzeigefilter icmp.type und icmp.code #### rt-mapping · Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung · NAT / load balancer mapping expired mid-connection Löscht ein Zwischengerät das Mapping einer Idle-Verbindung (den Eintrag, wohin diese Verbindung weitergeleitet wird), kommt das nächste gesendete Paket nicht mehr an. Entweder folgen Retransmissions, bis die Verbindung abbricht, oder das Gerät schickt eine Verbindungsablehnung (RST) zurück, und die Verbindung bricht sofort ab. - Warum → Folge → Auf dem Bildschirm: Verbindung, über die eine Weile keine Pakete laufen (AFK, Lobby) → NAT im Router, CGNAT des Providers, Firewall, Load-Balancer oder Cloud-Security-Group löscht das Idle-Mapping → Bei der nächsten Bewegung folgen Retransmissions, dann Verbindungsabbruch, oder sofort Verbindungsabbruch - Symptome: Verbindungsabbruch, Freeze / Faktoren: Paketverlust - Wer: Nur ich, Bestimmte Region oder Provider / Wann: Nach Inaktivität - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (Mappings im Router des Spielers und im CGNAT des Providers werden nur durch ausgehende Pakete zuverlässig erneuert, und deren Timeouts können wir nicht ändern, daher sendet der Client), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (TCP-Keepalive-Intervall über Socket-Optionen wie TCP_KEEPIDLE verkürzen, mit TCP_USER_TIMEOUT schnell erkennen), Session per Session-Token fortsetzen. - Aufgaben Infrastrukturteam: Netzwerk: Idle-Timeouts der Firewalls und Load-Balancer auf der Strecke sammeln und mit dem Entwicklungsteam teilen, eigene Firewalls und Load-Balancer bei Bedarf hochsetzen. Server/OS: Tracking-Dauer der Cloud-Security-Groups prüfen und mit dem Entwicklungsteam teilen. - Größenordnungen: Wie lange ein TCP-Mapping erhalten bleibt, ist je nach Gerät sehr unterschiedlich, von einigen Minuten bis zu mehreren Stunden. Verfolgt eine Cloud-Security-Group Verbindungen, löschen AWS-Instanztypen mit Nitro v6 den Tracking-Eintrag standardmäßig nach 350 s (andere Typen nach 5 Tagen, siehe „Ablauf des Connection Trackings in Cloud-Security-Groups“). Der Standardwert von TCP-Keepalive unter Linux lautet „nach 2 Stunden Leerlauf prüfen“ und liegt damit über den Timeouts der meisten Geräte. - Im Graphen: Verbindungen brechen gleichzeitig ab (Verbindungsabbrüche, Idle-Zeit vor dem Abbruch) - Wo nachsehen: Die letzten Minuten abgebrochener Verbindungen per Paketmitschnitt auf dem Server prüfen, bei bestehenden Verbindungen die Idle-Zeit über lastsnd und lastrcv in ss -ti ansehen (ms seit dem letzten Senden bzw. Empfangen). Dazu TcpExtTCPAbortOnTimeout in nstat (Verbindungen, die nach Ablauf des Timers aufgegeben wurden) - Spricht dafür: Bei jeder abgebrochenen Verbindung lag die vorangehende Idle-Zeit über einem ähnlichen Wert (dem Idle-Timeout eines Geräts auf der Strecke, z. B. 350 s bei Security Groups von AWS-Nitro-v6-Instanzen), ab dem ersten Paket nach dem Leerlauf folgen nur Retransmissions ohne ACK bis zur Aufgabe, oder es kommt sofort ein RST zurück - Spricht dagegen: Abbrüche auch mitten im Spiel, unabhängig von der Idle-Zeit: andere Ursache („Routenwechsel oder defekter ECMP-Pfad“, „Verworfene Pakete in Firewall und Connection Tracking“). Laufen auf der Verbindung Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout, scheidet diese Ursache aus - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 5382: NAT Behavioral Requirements for TCP](https://www.rfc-editor.org/rfc/rfc5382) · IETF · Empfehlung: Das Idle-Timeout von TCP-NATs soll mindestens 2 Stunden 4 Minuten betragen (in der Annahme, dass Geräte Idle-Sessions auch früher löschen können) - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · NAT-Mappings müssen durch ausgehende Pakete erneuert werden (REQ-6), Erneuerung durch eingehende Pakete ist optional (für UDP) - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Standard-Timeout für das Tracking von Idle-TCP-Verbindungen: 350 s bei Nitro-v6-Instanztypen, 432.000 s (5 Tage) bei anderen Typen. Empfehlung für Keepalive in Abständen unter 5 Minuten - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_keepalive_time standardmäßig 2 Stunden - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_KEEPIDLE (Idle-Zeit vor dem Start von Keepalive), TCP_USER_TIMEOUT (wie lange auf unbestätigte Daten gewartet wird, bevor die Verbindung geschlossen wird) - [RFC 5482: TCP User Timeout Option](https://www.rfc-editor.org/rfc/rfc5482) · IETF · TCP User Timeout: nach welcher Zeit ohne Bestätigung gesendeter Daten die Verbindung geschlossen wird - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · lastsnd und lastrcv bei ss -i: Zeit seit dem letzten Senden bzw. Empfangen (ms) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPAbortOnTimeout: Zahl der Verbindungen, die nach Ablauf eines TCP-Timers ohne RST aufgegeben wurden #### rt-path · Routenwechsel oder defekter ECMP-Pfad · Route change / bad ECMP member Pakete verschwinden in den Sekunden, in denen sich die Internet-Route ändert, oder auf Verbindungen, die unter mehreren ECMP-Pfaden einem defekten Pfad zugeordnet sind. - Warum → Folge → Auf dem Bildschirm: BGP berechnet Routen neu, oder unter mehreren Pfaden (ECMP, LAG) hat einer ein defektes Gerät oder eine defekte Leitung → Vorübergehender Verlust während der Umschaltung, oder anhaltender Verlust nur auf den Verbindungen über diesen Pfad → Plötzlich einige Sekunden Freeze, dann Zeitraffer, oder „nach einem Reconnect wird es besser“ (Zuweisung zu einem anderen Pfad) - Symptome: Freeze, Zeitraffer, Teleportieren / Faktoren: Paketverlust - Wer: Bestimmte Region oder Provider / Wann: Gelegentlich, zufällig - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Extern (Extern) - Aufgaben Entwicklungsteam: Retransmission-Statistiken pro Verbindung (TCP_INFO) aufzeichnen, damit sich IP, Port und Zeitpunkt der Betroffenen herausziehen lassen, Verbindungen nach einigen Sekunden Stillstand nicht sofort trennen. - Aufgaben Infrastrukturteam: Retransmission-Rate nach Region und Provider überwachen, prüfen, ob sich die Route durch einen Reconnect ändert, Leitungen mehrerer Provider vorhalten, defekte Links unter den ECMP- und LAG-Pfaden der eigenen Geräte suchen, Routen über denselben TCP-Port wie das Spiel messen (mtr --tcp --port. Die Route hängt von Adresse und Port ab, ein normaler Ping nimmt daher mitunter einen anderen Pfad und sieht unauffällig aus). - Aufgaben Extern: Defekten Pfad beim Provider melden, mit Routenmessungen über denselben TCP-Port und einem Vergleich vor und nach dem Reconnect. - Im Graphen: Stufe ab einem bestimmten Zeitpunkt (RTT (Ping), Retransmission-Rate nach Region und Provider) - Wo nachsehen: Mit bcc tcpretrans -c Retransmissions pro Verbindung sammeln und Adressen und Ports der betroffenen Spieler herausziehen, mtr über denselben TCP-Port wie das Spiel (mtr -T -P PORT) vom Server zum Spieler und vom Spieler zum Server aufzeichnen und vergleichen. Auch Ergebnisse vor und nach einem Reconnect vergleichen - Spricht dafür: Ab einem bestimmten Zeitpunkt ändert sich die RTT einer Region oder eines Providers stufenartig, und einige Sekunden lang häufen sich Verluste, oder innerhalb desselben Providers haben nur einige Verbindungen (Kombinationen aus Adresse und Port) anhaltend Retransmissions, die nach einem Reconnect verschwinden. Mitunter ist der normale Ping unauffällig, und nur TCP-mtr zeigt Verlust - Spricht dagegen: Alle Verbindungen dieses Providers verschlechtern sich gemeinsam in der abendlichen Stoßzeit: „Warteschlangenüberlauf am Engpass“. Nur ein Spieler betroffen, Verlust schon beim Ping zum Router: „Verlust auf der Funkstrecke“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: cloudflare-2020 - Quellen: - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Bei Mehrwege-Routing sind die Ergebnisse von Diagnosetools wie ping und traceroute wenig verlässlich, Beschreibung des Verfahrens, den Pfad per Hash über den Flow festzulegen - [RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm](https://www.rfc-editor.org/rfc/rfc2992) · IETF · ECMP wählt den nächsten Pfad per Hash über die Headerfelder, die den Flow identifizieren (gleicher Flow, gleicher Pfad) - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_INFO: Abfrage des Zustands pro Socket (struct tcp_info) - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · -T (--tcp) sendet TCP SYN (Standard ist ICMP), -P (--port) legt den Zielport fest - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Zeigt pro Retransmission eine Zeile mit Adresse und Port der Gegenseite, -c zählt Retransmissions pro Flow #### rt-spurious-delay · Unnötige Retransmission durch Latenzsprünge · Spurious RTO from delay spikes Das Paket ist gar nicht verschwunden, es kommt nur kurz sehr spät an. Dauert diese Verzögerung länger als das RTO, wertet der Sender das als Verlust und sendet erneut. - Warum → Folge → Auf dem Bildschirm: Bufferbloat, WLAN-Energiesparen, Zustandswechsel im Mobilfunk oder pausierte virtuelle Maschine: kurzzeitig mehrere hundert ms Latenz → Das RTO läuft zuerst ab, es folgt eine Retransmission, kurz darauf kommt auch das Original an (der Empfänger erhält es doppelt) → Freeze und Zeitraffer kommen vom Latenzsprung selbst. Die unnötige Retransmission verlängert den Freeze kaum, treibt aber die Retransmission-Metriken nach oben und wird für Verlust gehalten - Symptome: Freeze, Zeitraffer, Input-Lag / Faktoren: Latenz, Jitter - Wer: Nur ich, Ganzer Server / Wann: Gelegentlich, zufällig, Nach Inaktivität - Hauptzuständig: Extern (Extern) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Clients ab Android 10 fordern im Spiel den WLAN-Modus mit niedriger Latenz an (WLAN-Lock WIFI_MODE_FULL_LOW_LATENCY, gilt nur bei eingeschaltetem Bildschirm und Spiel im Vordergrund), um Latenzsprünge durch Energiesparen zu verringern. - Aufgaben Infrastrukturteam: Burstable-Instanzen meiden, RTO-Minimum nicht zu weit senken, F-RTO und Timestamps beibehalten (tcp_frto, tcp_timestamps), Retransmission-Metriken zusammen mit TCPSpuriousRTOs und TCPDSACKRecv in nstat betrachten, damit sie nicht fälschlich als Verlust gelten. - Aufgaben Extern: Um die Latenzsprünge selbst zu verringern, Spieler auf SQM am Router und das Abschalten des WLAN-Energiesparmodus hinweisen. - Größenordnungen: Linux erkennt unnötige RTOs per F-RTO und nimmt die Drosselung der Senderate teils wieder zurück. Zu prüfen sind TCPSpuriousRTOs (als unnötig eingestufte RTOs) und TCPDSACKRecv (wie oft der Empfänger „schon erhalten“ gemeldet hat) in nstat. - Im Graphen: Vereinzelte Spitzen ohne Muster (RTT (Ping), unnötige RTOs) - Wo nachsehen: nstat im Minutentakt ausführen und den Zuwachs von TcpExtTCPTimeouts (abgelaufene RTOs), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv und TcpExtTCPLostRetransmit gemeinsam betrachten. Liegt ein Paketmitschnitt vor, den Wireshark-Filter tcp.analysis.spurious_retransmission nutzen - Spricht dafür: Steigen die RTOs, steigen auch TcpExtTCPSpuriousRTOs oder TcpExtTCPDSACKRecv, gleichzeitig schießt die RTT auf mehrere hundert ms hoch. Im Mitschnitt auf Empfängerseite sind Original und Retransmission beide angekommen - Spricht dagegen: TcpExtTCPSpuriousRTOs und DSACK unverändert, aber TcpExtTCPLostRetransmit steigt (auch die Retransmission geht verloren): echter Verlust. RTT ohne Spitzen, aber dauerhaft viele DSACKs: „Unnötiger Fast Retransmit durch vertauschte Reihenfolge“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP](https://www.rfc-editor.org/rfc/rfc5682) · IETF · F-RTO: erkennt anhand der ACKs nach einem RTO, ob das RTO unnötig war - [RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks](https://www.rfc-editor.org/rfc/rfc3481) · IETF · Latenzsprünge im Mobilfunknetz (Handover, Link-Wiederherstellung usw.) verursachen unnötige TCP-Timeouts und Retransmissions sowie eine Verkleinerung des Congestion Window - [RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP](https://www.rfc-editor.org/rfc/rfc2883) · IETF · DSACK: Der Empfänger meldet doppelt empfangene Daten, so erkennt der Sender unnötige Retransmissions - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPSpuriousRTOs (von F-RTO erkannte unnötige RTOs), TcpExtTCPDSACKRecv (Zahl empfangener DSACKs), TcpExtTCPLostRetransmit (wie oft SACK meldet, dass auch ein erneut gesendetes Paket verloren ging) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_frto standardmäßig aktiv (vorteilhaft in Funknetzen mit schwankender RTT), tcp_timestamps standardmäßig 1 - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Begründung, dass ein großes RTO-Minimum nötig ist, um unnötige Retransmissions zu vermeiden (Empfehlung: mindestens 1 s) - [WifiManager](https://developer.android.com/reference/android/net/wifi/WifiManager#WIFI_MODE_FULL_LOW_LATENCY) · Android (Google) · WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): WLAN-Lock mit niedriger Latenz, der nur greift, wenn das Gerät mit einem AP verbunden, der Bildschirm eingeschaltet und die App im Vordergrund ist - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · In nstat angezeigte Zählernamen TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv und TCPLostRetransmit - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · TCPTimeouts steigt, wenn der Retransmission-Timer (RTO) abläuft - [nstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/nstat.8.html) · iproute2 · nstat zeigt standardmäßig den Zuwachs seit dem letzten Aufruf - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Anzeigefilter tcp.analysis.spurious_retransmission #### rt-reorder · Unnötiger Fast Retransmit durch vertauschte Reihenfolge · Reordering triggers spurious fast retransmit Kommt die Paketreihenfolge über mehrere Pfade oder gebündelte Links durcheinander, meldet der Empfänger per doppelter ACKs „Paket fehlt“, und der Sender schickt intakte Pakete erneut. - Warum → Folge → Auf dem Bildschirm: Geräte, die Pfade pro Paket aufteilen, LAG (Link-Bündelung) mit Verteilung pro Paket oder der Moment eines Routenwechsels bringen die Reihenfolge durcheinander → Spätere Pakete kommen zuerst an, 3 doppelte ACKs sammeln sich → Fast Retransmit → Vereinzelte Spielpakete sind kaum betroffen. Große Updates an vollen Orten und Patch-Downloads werden langsamer, gelegentlich Ruckeln - Symptome: Ruckeln, Input-Lag / Faktoren: Jitter - Wer: Bestimmte Region oder Provider, Ganzer Server / Wann: Immer, Bei großem Andrang - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Netzwerk: Verteilung pro Paket auf Verteilung pro Verbindung umstellen (ECMP und LAG per Hash über Adresse und Port). Server/OS: RACK nutzen (zeitbasierte Verlusterkennung, robust gegen vertauschte Reihenfolge. Erkennt RACK per DSACK unnötige Retransmissions, vergrößert es automatisch die Toleranz für vertauschte Reihenfolge), den von Linux pro Verbindung automatisch geschätzten Grad der Vertauschung prüfen (Wert reordering in ss -ti, Startwert tcp_reordering=3). - Im Graphen: Von Anfang an dauerhaft hoch (Erkannte Vertauschungen der Reihenfolge, empfangene DSACKs) - Wo nachsehen: TcpExtTCPSACKReorder und TcpExtTCPTSReorder (erkannte Vertauschungen der Reihenfolge) sowie TcpExtTCPDSACKRecv in nstat prüfen, pro Verbindung reordering (angezeigt, wenn ungleich 3) und reord_seen in ss -ti. Im Paketmitschnitt den Wireshark-Filter tcp.analysis.out_of_order nutzen - Spricht dafür: Reordering-Zähler und DSACKs steigen unabhängig von der Tageszeit stetig, bei Verbindungen über einen bestimmten Pfad oder ein bestimmtes Gerät ist reordering größer als 3. Im Mitschnitt auf Empfängerseite kommen spätere Pakete zuerst, und die früheren folgen kurz darauf - Spricht dagegen: Reordering-Zähler unverändert, TcpExtTCPLostRetransmit steigt: echter Verlust. DSACKs steigen nur in Momenten mit RTT-Spitzen: „Unnötige Retransmission durch Latenzsprünge“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Wird der Pfad pro Paket aufgeteilt, ändert sich die Reihenfolge, und kommen 3 oder mehr spätere Pakete zuerst an, führt TCP einen unnötigen Fast Retransmit aus - [RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm](https://www.rfc-editor.org/rfc/rfc2992) · IETF · ECMP, das den Pfad per Hash über die Headerfelder wählt, die den Flow identifizieren (Verteilung pro Flow) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast Retransmit beim dritten doppelten ACK - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK erkennt Verluste zeitbasiert und ist daher robust gegen vertauschte Reihenfolge, bei empfangenem DSACK vergrößert es das Toleranzfenster für vertauschte Reihenfolge (reo_wnd) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_reordering mit Startwert 3 (pro Verbindung automatisch bis tcp_max_reordering angepasst), RACK-Einstellung in tcp_recovery - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · ss -ti zeigt reordering:Wert, wenn der reordering-Wert der Verbindung vom Standardwert 3 abweicht, und reord_seen:Anzahl, wenn die Verbindung schon vertauschte Reihenfolge erlebt hat - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPSACKReorder und TcpExtTCPTSReorder (erkannte Vertauschungen), TcpExtTCPDSACKRecv (empfangene DSACKs), TcpExtTCPLostRetransmit (auch das erneut gesendete Paket ging verloren) - [include/uapi/linux/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/tcp.h?h=v6.12) · Linux kernel · tcpi_reord_seen in tcp_info: Zahl der Vertauschungen, die die Verbindung erlebt hat - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Anzeigefilter tcp.analysis.out_of_order #### rt-ack-path · Verspätete oder verlorene ACKs (ausgelasteter Upload) · ACK path congestion on asymmetric links Die Daten sind angekommen, aber das ACK („erhalten“) verspätet sich in der vollen Upload-Warteschlange oder geht verloren. Dann wertet der Sender das als Verlust und sendet erneut. - Warum → Folge → Auf dem Bildschirm: Upload zu Hause durch Video-Uploads oder Cloud-Backups voll ausgelastet → ACKs verspäten sich in der Warteschlange des Routers um mehrere hundert ms oder werden beim Überlauf verworfen → Die Spielpakete vom Server kommen meist pünktlich an. Die eigenen Eingaben stecken in derselben Upload-Warteschlange und kommen spät an: Input-Lag und Rubberbanding, gelegentlich unnötige Retransmissions - Symptome: Input-Lag, Rubberbanding / Faktoren: Latenz, Paketverlust - Wer: Gleicher Haushalt / Wann: Gelegentlich, zufällig, Abendliche Stoßzeit - Hauptzuständig: Extern (Extern) / Beteiligt: Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Bei sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen und den Hinweis „Laufende Uploads prüfen“ einblenden. - Aufgaben Extern: Spieler darauf hinweisen, mit SQM am Router die Upload-Warteschlange kurz zu halten, kleine Pakete (ACKs) zu priorisieren und die Upload-Rate (Video-Uploads, Cloud-Backups) zu begrenzen. - Größenordnungen: Ein späteres ACK bestätigt die vorherigen mit, daher schadet es meist nicht, wenn einige verloren gehen. Das Problem sind die Verzögerungen in der Warteschlange. - Im Graphen: Nur einzelne Ausreißer (RTT (Ping) pro Verbindung) - Wo nachsehen: Auf dem PC des Spielers den Ping zum Spielserver mit und ohne laufenden Upload (Video-Upload, Cloud-Backup) vergleichen. Auf dem Server rtt der Verbindung dieses Spielers mit ss -ti prüfen - Spricht dafür: Nur während des Uploads steigt der Ping auf mehrere hundert ms, Input-Lag und Rubberbanding treten auf, nach dem Stoppen des Uploads normalisiert sich alles schnell. Serverseitig steigt zur selben Zeit auch rtt dieser Verbindung - Spricht dagegen: Verlust und Latenz unabhängig vom Upload: „Verlust auf der Funkstrecke“ oder eine Ursache auf der Route. Nur die Richtung Server → Spieler ist langsam, unabhängig vom Upload: „Warteschlangenüberlauf am Engpass“ - Prüfmittel: Prüfung in der Umgebung des Spielers - Quellen: - [RFC 3449: TCP Performance Implications of Network Path Asymmetry](https://www.rfc-editor.org/rfc/rfc3449) · IETF · Verspäten sich ACKs auf asymmetrischen Leitungen mit schmalem Upload oder gehen verloren, sinkt die TCP-Leistung, ACKs bestätigen kumulativ, daher springt bei Verlust einiger ACKs ein späteres ein, Gegenmaßnahmen wie ACK-Priorisierung im Scheduling - [Smart Queue Management](https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/) · Bufferbloat.net · Warteschlangen im Router durch Warteschlangenverwaltung und Shaping kurz halten - [tc-cake(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-cake.8.html) · iproute2 · CAKE trennt Flows und minimiert die Latenz für Flows mit vereinzelten Paketen (sparse flows) - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rtt (mittlere Umlaufzeit) und rttvar (Abweichung) bei ss -i #### rt-rto-setting · RTO-Einstellung passt nicht zur Umgebung · RTO min too low or too high Ist das RTO-Minimum zu weit gesenkt, kommt es schon bei leichter Verspätung zu unnötigen Retransmissions. Der Standardwert (200 ms) ist für Spiele zu lang, jeder einzelne Verlust führt zu einem langen Stillstand. - Warum → Folge → Auf dem Bildschirm: RTO-Minimum für den Rechenzentrumsbetrieb stark gesenkt, oder Standardwert unverändert auf Internetstrecken → Zu niedrig: Flut von Retransmissions schon bei kurzen Verzögerungen. Zu hoch: lange Wartezeit bei jedem Verlust → Mit Standardwert pro Verlust einige hundert ms Freeze, dann Zeitraffer. Zu weit gesenkt: weniger Freeze, aber unnötige Retransmissions nehmen sprunghaft zu und verschwenden Leitungskapazität - Symptome: Freeze, Zeitraffer, Input-Lag / Faktoren: Latenz - Wer: Ganzer Server / Wann: Immer - Hauptzuständig: Server-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Ab Linux 6.15 prüfen, ob sich die RTO-Obergrenze für Spielverbindungen mit TCP_RTO_MAX_MS senken lässt (dadurch wird auch die Zeit bis zur Aufgabe kürzer, daher zugleich per TCP_USER_TIMEOUT festlegen, wann eine Verbindung als abgebrochen gilt), das RTO-Minimum nur für interne Verbindungen zwischen Servern per Socket-Option TCP_RTO_MIN_US (ab 6.15) senken, prüfen, ob sich per Socket-Option TCP_THIN_LINEAR_TIMEOUTS nur für Spielverbindungen das Verdoppeln bei aufeinanderfolgenden RTOs abschalten lässt. - Aufgaben Infrastrukturteam: rto_min pro Route nur für interne Verbindungen zwischen Servern senken, auf Internetstrecken den Standardwert beibehalten und mit RACK-TLP und Thin-Stream-Einstellungen (tcp_thin_linear_timeouts) ergänzen. - Größenordnungen: Linux-RTO = Umlaufzeit + max(200 ms, RTT-Abweichung × 4). Bei jedem Fehlschlag doppelt so lang, maximal 120 s. Ab Linux 6.15 lässt sich diese Obergrenze mit TCP_RTO_MAX_MS bis auf 1 s senken. - Im Graphen: Von Anfang an dauerhaft hoch (RTO pro Verbindung, unnötige RTOs) - Wo nachsehen: Eingestelltes RTO-Minimum des Servers (rto_min in ip route show, ab Linux 6.11 sysctl net.ipv4.tcp_rto_min_us) sowie rto und rtt in ss -ti prüfen, Zuwachs von TcpExtTCPSpuriousRTOs in nstat ansehen - Spricht dafür: Auf Servern mit gesenktem Minimum liegt rto bei Internetverbindungen dicht an rtt, und TcpExtTCPSpuriousRTOs steigt stark. Mit Standardwert ist rto bei Spielverbindungen mindestens 200 ms größer als rtt, und jeder Verlust bedeutet einen Stillstand dieser Länge - Spricht dagegen: rto entspricht der Standardberechnung (rtt + ca. 200 ms), wenige unnötige RTOs, aber auffallend lange Stillstände: Verluste in Folge oder Wiederherstellungsverfahren („Langsame Wiederherstellung bei Thin Streams“, „Zwischengeräte entfernen TCP-Optionen“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · RTO = SRTT + max(G, 4·RTTVAR), Empfehlung mindestens 1 s, bei jedem Fehlschlag doppelt, ein Maximum muss, falls vorhanden, mindestens 60 s betragen - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Linux: TCP_RTO_MIN 200 ms, TCP_RTO_MAX 120 s - [net/ipv4/tcp_input.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · Linux-RTO ist SRTT + rttvar, und rttvar sinkt nicht unter das RTO-Minimum (standardmäßig 200 ms) - [tcp: add the ability to control max RTO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54a378f43425085d0684679d99735696b69165bc) · Linux kernel · Socket-Option TCP_RTO_MAX_MS hinzugefügt (1–120 s), ab Linux 6.15 - [tcp: add sysctl_tcp_rto_min_us](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f086edef71be7174a16c1ed67ac65a085cda28b1) · Linux kernel · Serverweites Standard-RTO-Minimum tcp_rto_min_us hinzugefügt, ab Linux 6.11 - [tcp: support TCP_RTO_MIN_US for set/getsockopt use](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f38805c5d26fe4af97837c10d58074a7496638bf) · Linux kernel · Socket-Option TCP_RTO_MIN_US für ein RTO-Minimum pro Socket hinzugefügt, ab Linux 6.15 - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rto_min_us standardmäßig 200000 (Routenoption rto_min und Socket-Option TCP_RTO_MIN_US haben Vorrang), tcp_rto_max_ms 1000–120000 (standardmäßig 120000), tcp_thin_linear_timeouts - [ip-route(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ip-route.8.html) · iproute2 · Option rto_min pro Route: RTO-Minimum für die Kommunikation mit diesem Ziel - [Thin-streams and TCP](https://docs.kernel.org/networking/tcp-thin.html) · Linux kernel · Mit TCP_THIN_LINEAR_TIMEOUTS lässt sich das exponentielle Backoff nur für Thin-Stream-Verbindungen abschalten - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_USER_TIMEOUT: wie lange auf unbestätigte Daten gewartet wird, bis die Verbindung geschlossen wird - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (ms) und rtt bei ss -i - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPSpuriousRTOs: von F-RTO erkannte unnötige RTOs #### rt-thin · Langsame Wiederherstellung bei Thin Streams · Thin streams fall back to RTO Sendet eine Verbindung wie bei Spielen nur vereinzelt kleine Pakete, läuft das RTO ab, bevor „3 nachfolgende Pakete“ beisammen sind. Beim selben Verlust steht sie deutlich länger still als eine große Übertragung. - Warum → Folge → Auf dem Bildschirm: Paketabstand um die 100 ms, daher nur wenige noch unbestätigte Pakete (in flight) → Bis 3 doppelte ACKs beisammen sind, vergehen über 300 ms, daher greift zuerst das RTO (Ping + 200 ms), bei Verlusten in Folge jeweils doppelt so lang → Pro Verlust etwa 0,3 s Freeze, geht auch die Retransmission verloren, fast 1 s Freeze, danach Zeitraffer - Symptome: Freeze, Zeitraffer / Faktoren: Paketverlust, Stillstand - Wer: Nur ich, Ganzer Server / Wann: Gelegentlich, zufällig - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: TCP_NODELAY aktivieren (bei aktivem Nagle fehlen die nachfolgenden Pakete, die RACK zur Erkennung braucht), Echtzeitpakete mit eigener Retransmission über UDP senden. Client: TCP_NODELAY aktivieren, Echtzeitpakete wie der Server per UDP senden. - Aufgaben Infrastrukturteam: RACK-TLP nutzen (Standard in aktuellen Linux-Kerneln), per tcp_thin_linear_timeouts das Verdoppeln bei aufeinanderfolgenden RTOs abschalten. - Größenordnungen: Bei 100 ms Paketabstand und 60 ms Ping dauert es bis zum Fast Retransmit etwa 360 ms (bis 3 nachfolgende Pakete angekommen sind und deren Bestätigung zurück ist), das RTO beträgt etwa 260 ms. Mit RACK wird nach etwa 160 ms erneut gesendet, sobald die Bestätigung des nächsten Pakets zurückkommt. Liegt der Paketabstand über 200 ms, ist auch RACK nicht schneller als das RTO. - Im Graphen: Lücke, dann alles auf einmal (Empfangsvolumen pro Verbindung, abgelaufene RTOs) - Wo nachsehen: Zuwachs von TcpExtTCPTimeouts (abgelaufene RTOs), TcpExtTCPFastRetrans (Fast Retransmit), TcpExtTCPLossProbes und TcpExtTCPLossProbeRecovery (TLP) in nstat vergleichen, Spielverbindungen mit ss -ti auf rto und backoff prüfen. Auch die Werte von net.ipv4.tcp_recovery, tcp_early_retrans und tcp_sack auf dem Server kontrollieren - Spricht dafür: Unter den Retransmissions gibt es mehr abgelaufene RTOs als Fast Retransmits, bei Spielverbindungen ist backoff häufig größer als 0 (die Verbindung steckt gerade im RTO). Während des Stillstands ist das Empfangsvolumen 0, nach der Wiederherstellung kommt alles auf einmal - Spricht dagegen: Große Übertragungen desselben Servers stehen genauso lange still: Verlustproblem unabhängig vom Verbindungsprofil. Häufung bei Verbindungen ohne SACK und Timestamps: „Zwischengeräte entfernen TCP-Optionen“ - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Linux hatte früher für Thin Streams auch eine Option, die schon nach einem doppelten ACK erneut sendet (tcp_thin_dupack). Sie wurde 2017 entfernt, heute übernimmt RACK diese Aufgabe. Ist Nagle aktiv (TCP_NODELAY aus), werden während des Wartens auf die Bestätigung des verlorenen Pakets auch keine neuen Pakete gesendet. Dann fehlen RACK die nachfolgenden Pakete zur Erkennung, und es wird bis zum RTO gewartet. - Quellen: - [Thin-streams and TCP](https://docs.kernel.org/networking/tcp-thin.html) · Linux kernel · Thin Streams mit vereinzelten Sendungen wie bei Spielen profitieren kaum von Fast Retransmit und sind auf lange Timeouts angewiesen, Kriterium: weniger als 4 noch unbestätigte Pakete (in flight) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast Retransmit beim dritten doppelten ACK - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK erkennt Verluste daran, dass später gesendete Pakete zugestellt wurden, TLP wartet 2·SRTT (bei nur einem unbestätigten Paket zuzüglich einer Reserve für Delayed ACK) - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_RTO_MIN 200 ms, Einstufung als Thin Stream (weniger als 4 Pakete in flight) und 6 lineare Wiederholungen - [tcp: remove thin_dupack feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a7f6009441144783e5925551c72e3f2e1b0839b) · Linux kernel · Entfernung von thin_dupack im Januar 2017 (Linux 4.11), mit der Begründung, dass RACK diese Aufgabe übernimmt - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_thin_linear_timeouts: bei Thin Streams wird das RTO bis zu 6-mal nicht verdoppelt (standardmäßig aus) - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_NODELAY schaltet den Nagle-Algorithmus ab - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · In nstat angezeigte Zählernamen TCPTimeouts, TCPFastRetrans, TCPLossProbes und TCPLossProbeRecovery - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · TCPTimeouts steigt, wenn der Retransmission-Timer (RTO) abläuft - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPFastRetrans (Retransmissions außerhalb des Loss-Zustands), TcpExtTCPLossProbes (TLP gesendet) und TcpExtTCPLossProbeRecovery (Verlust per TLP behoben) - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (ms) und backoff (wie oft sich das RTO verdoppelt hat) bei ss -i #### rt-sack-stripped · Zwischengeräte entfernen TCP-Optionen · Middlebox strips TCP options Entfernen oder verändern manche Firewalls und WAN-Beschleuniger TCP-Optionen, wird bei mehreren Verlusten nur ein Paket pro Round Trip wiederhergestellt, oder das Window (die Menge, die auf einmal gesendet werden darf) schrumpft, und alles wird langsamer. - Warum → Folge → Auf dem Bildschirm: „TCP-Normalisierung“ in der Firewall oder alte WAN-Beschleuniger entfernen die Optionen SACK, Timestamps und Window Scaling → Bei mehreren verlorenen Paketen wird pro Round Trip nur eines wiederhergestellt, das Window ist auf 64 KB begrenzt → Jeder Verlust führt zu einem deutlich längeren Freeze (ohne SACK funktioniert auch RACK-TLP nicht), danach Zeitraffer. Auch große Übertragungen wie Patches sind langsam - Symptome: Freeze, Zeitraffer / Faktoren: Stillstand, Latenz - Wer: Bestimmte Region oder Provider, Ganzer Server / Wann: Immer - Hauptzuständig: Netzwerk-Infrastruktur (Infrastrukturteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam) - Aufgaben Infrastrukturteam: Netzwerk: TCP-Normalisierung im betroffenen Gerät abschalten, auch die Sequenznummer-Randomisierung der Firewall prüfen, die Optionen im SYN per Paketmitschnitt an beiden Enden vergleichen. Server/OS: in ss -ti prüfen, ob sich Verbindungen ohne sack- und wscale-Angabe auf bestimmten Routen häufen (ts lassen Windows-PCs je nach Einstellung weg, fehlt nur ts, kann das normal sein), prüfen, ob net.ipv4.tcp_sack auf dem Server 1 ist. - Im Graphen: Von Anfang an dauerhaft hoch (Wiederherstellungen ohne SACK (TcpExtTCPRenoRecovery)) - Wo nachsehen: In ss -ti pro Verbindung prüfen, ob sack und wscale angezeigt werden, in nstat das Verhältnis von TcpExtTCPRenoRecovery (Wiederherstellung ohne SACK) zu TcpExtTCPSackRecovery sowie TcpExtTCPSACKDiscard (wegen Widersprüchen verworfene SACK-Blöcke) ansehen. Auf verdächtigen Routen den SYN an beiden Enden mitschneiden und die Optionen vergleichen (in Wireshark z. B. tcp.options.sack_perm) - Spricht dafür: Nur Verbindungen über eine bestimmte Route oder ein bestimmtes Gerät haben kein sack und wscale, hoher Anteil von TcpExtTCPRenoRecovery. Die SACK-Permitted-Option aus dem SYN des Senders fehlt im SYN, der beim Empfänger ankommt. Ist die Sequenznummer-Randomisierung die Ursache, sind die Optionen vorhanden, aber TcpExtTCPSACKDiscard steigt - Spricht dagegen: sack fehlt bei allen Verbindungen: zuerst net.ipv4.tcp_sack auf dem Server prüfen. Optionen intakt und TcpExtTCPSACKDiscard unverändert: Die langsame Wiederherstellung hat einen anderen Grund („Langsame Wiederherstellung bei Thin Streams“) - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Mehr dazu: Auch wenn die Optionen erhalten bleiben, kann SACK kaputtgehen. Ändert die Sequenznummer-Randomisierung (sequence randomization) einer Firewall nur die Sequenznummern im Header und lässt die Nummern im SACK unverändert, verwirft der Sender die widersprüchlichen SACKs. Dasselbe Ergebnis hat ein tcp_sack=0, das wegen der SACK-Sicherheitslücke von 2019 auf dem Server gesetzt und dann vergessen wurde. - Quellen: - [RFC 2018: TCP Selective Acknowledgment Options](https://www.rfc-editor.org/rfc/rfc2018) · IETF · Ohne SACK lässt sich mit kumulativen ACKs pro Round Trip nur ein verlorenes Paket erkennen - [RFC 7323: TCP Extensions for High Performance](https://www.rfc-editor.org/rfc/rfc7323) · IETF · Ohne Window-Scaling-Option beträgt das Window höchstens 2^16 = 64 KiB - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK-TLP setzt SACK voraus - [net/ipv4/tcp_output.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_output.c?h=v6.12) · Linux kernel · Linux plant TLP nur bei Verbindungen mit SACK ein - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_sack standardmäßig 1 (aktiv) - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · ss -ti zeigt je nach genutzten Optionen ts, sack und wscale:Senden,Empfangen - [tcp: limit payload size of sacked skbs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b4929f65b0d8249f19a50245cd88ed1a2f78cff) · Linux kernel · Commit zur Behebung der Schwachstelle in der SACK-Verarbeitung von 2019 (CVE-2019-11477) - [Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service vulnerabilities (NFLX-2019-001)](https://raw.githubusercontent.com/Netflix/security-bulletins/master/advisories/third-party/2019-001.md) · Netflix · Als vorläufige Gegenmaßnahme wurde damals tcp_sack=0 (SACK-Verarbeitung abschalten) empfohlen - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPRenoRecovery (Wiederherstellung ohne SACK begonnen) und TcpExtTCPSackRecovery (Wiederherstellung mit SACK begonnen), TcpExtTCPSACKDiscard (Zahl ungültiger SACK-Blöcke) - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Anzeigefilter tcp.options.sack_perm (SACK-Permitted-Option im SYN) #### rt-zero-window · Zero Window (Stillstand, der wie eine Retransmission aussieht) · Zero window, often mistaken for retransmission Liest das empfangende Programm den Socket nicht rechtzeitig und läuft der Puffer voll, stellt der Sender die Übertragung ein und schickt nur noch Zero-Window-Probes. Die Leitung ist in Ordnung. - Warum → Folge → Auf dem Bildschirm: Socket wird nicht gelesen, weil Frames auf dem Client hängen oder ein Server-Thread blockiert ist → Receive Window fällt auf 0, der Sender stellt die Übertragung ein und schickt nur Probes (in immer größeren Abständen) → Freeze, dann Zeitraffer. Im Paketmitschnitt ist „ZeroWindow“ zu sehen, Verluste gibt es keine - Symptome: Freeze, Zeitraffer / Faktoren: Stillstand - Wer: Nur ich, Ganzer Server / Wann: Bei großem Andrang, Gelegentlich, zufällig - Hauptzuständig: Client-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam) - Aufgaben Entwicklungsteam: Im Paketmitschnitt zuerst die Seite prüfen, die ZeroWindow gesendet hat (die Seite, die den Socket nicht liest), Netzwerkempfang in einem eigenen Thread fortlaufend lesen, Empfangspuffer angemessen dimensionieren. Client: Ursachen hängender Frames wie Laden oder GC beheben. Server: Ursachen dafür beheben, dass der Thread blockiert, der den Socket liest. - Aufgaben Infrastrukturteam: TcpExtTCPToZeroWindowAdv in nstat auf dem Server (wie oft der Server ein Receive Window von 0 gemeldet hat) ins Monitoring aufnehmen (steigt der Wert, liegt es am Server, dann an die Server-Entwicklung weitergeben), Paketmitschnitte vom Server bereitstellen. - Im Graphen: Lücke, dann alles auf einmal (Empfangsvolumen pro Verbindung, Zero-Window-Ereignisse) - Wo nachsehen: Im Paketmitschnitt mit dem Wireshark-Filter tcp.analysis.zero_window die Seite finden, die ein Window von 0 gemeldet hat. In nstat auf dem Server TcpExtTCPToZeroWindowAdv (Server meldet Window 0) und TcpExtTCPWinProbe (Probe auf das Window 0 der Gegenseite gesendet) getrennt betrachten und Recv-Q der Server-Sockets prüfen (in ss die Bytes, die das Programm noch nicht gelesen hat) - Spricht dafür: Während des Stillstands keine Retransmissions, nur Zero Windows und Probes. Steigen TcpExtTCPToZeroWindowAdv auf dem Server oder Recv-Q der Server-Sockets, liest der Server nicht rechtzeitig, steigt TcpExtTCPWinProbe, liest der Client nicht rechtzeitig - Spricht dagegen: Kein Zero Window im Mitschnitt, dieselben Daten werden erneut gesendet: Ursache bei Verlust oder unnötiger Retransmission - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Reale Fälle: roblox-2021 - Quellen: - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Ist das Receive Window 0, sendet der Sender Zero-Window-Probes und vergrößert den Abstand zwischen den Probes exponentiell - [7.5. TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) · Wireshark · TCP ZeroWindow: Paket, mit dem der Empfänger ein Window von 0 meldet und den Sender so anhält - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Anzeigefilter tcp.analysis.zero_window und tcp.analysis.zero_window_probe - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPToZeroWindowAdv: wie oft das Receive Window von einem Wert ungleich 0 auf 0 gemeldet wurde - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · In nstat angezeigte Zählernamen TCPToZeroWindowAdv und TCPWinProbe - [net/ipv4/tcp_output.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_output.c?h=v6.12) · Linux kernel · TCPWinProbe: steigt mit jeder Probe (tcp_send_probe0), die bei einem Receive Window von 0 auf der Gegenseite gesendet wird - [net/ipv4/tcp_diag.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Recv-Q in ss ist bei Verbindungen die Zahl empfangener Bytes, die das Programm noch nicht gelesen hat #### rt-syn · Retransmission der Verbindungsanfrage (SYN) · SYN retransmission on connect Geht die Verbindungsanfrage durch einen Überlauf der Verbindungswarteschlange (Backlog) oder eine Firewall-Sperre verloren, sendet das Client-OS sie ab 1 s in wachsenden Abständen erneut. - Warum → Folge → Auf dem Bildschirm: Login-Ansturm direkt nach der Wartung lässt die Verbindungswarteschlange des Servers überlaufen, oder Firewall bzw. DDoS-Schutz verwerfen SYNs → Client-OS sendet SYN ab 1 s in festgelegten Abständen erneut (ältere Linux-Versionen: 1 s → 2 s → 4 s) → Nach dem Klick auf Verbinden Verzögerung um glatte Sekunden wie 1 s oder 3 s, bei anhaltendem Scheitern: Kein Login / Endlos-Laden - Symptome: Kein Login / Endlos-Laden / Faktoren: Paketverlust - Wer: Ganzer Server, Bestimmte Region oder Provider / Wann: Direkt nach Login oder Wartung - Hauptzuständig: Server-Entwicklung (Entwicklungsteam) / Beteiligt: Server-Infrastruktur (Infrastrukturteam), Netzwerk-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam) - Aufgaben Entwicklungsteam: Server: backlog-Argument von listen erhöhen (zusammen mit somaxconn), dafür sorgen, dass der Spielserver accept rechtzeitig aufruft, Login-Warteschlangensystem. Client: Abstände zwischen Verbindungsversuchen vergrößern (zufällig gestreut). - Aufgaben Infrastrukturteam: Server/OS: Überlauf der Verbindungswarteschlange über TcpExtListenOverflows und TcpExtListenDrops in nstat und die Warnung „Possible SYN flooding“ im Log erkennen, somaxconn erhöhen (zusammen mit dem listen-Argument), SYN-Cookies. Netzwerk: SYN-Limits von Firewall und DDoS-Schutz lockern. - Größenordnungen: Unter Linux (einschließlich Android) folgt die erste SYN-Retransmission nach 1 s. Ältere Kernel verdoppeln danach jeweils den Abstand und senden nach 1, 3, 7, 15 s … erneut, ab 6.5 wird nach 1, 2, 3, 4 und 5 s fünfmal erneut gesendet und danach verdoppelt (7, 11, 19 s …) (tcp_syn_linear_timeouts=4). Android-Smartphones behalten auch nach OS-Updates oft den Kernel aus der Markteinführung, daher kann es selbst bei gleicher Android-Version je nach Gerät Unterschiede geben. In beiden Fällen wird nach etwa 2 Minuten aufgegeben, wenn alles scheitert. Unter Windows beginnt es je nach Version und Einstellung bei 1 s oder 3 s, und bei 2–4 Wiederholungen wird nach 20–30 s aufgegeben (den Wert des PCs zeigt Max SYN Retransmissions in netsh int tcp show global). - Im Graphen: Ansturm direkt nach Login oder Wartung (Verbindungsversuche, Überläufe der Verbindungswarteschlange) - Wo nachsehen: In nstat auf dem Server TcpExtListenOverflows und TcpExtListenDrops sowie die Warnung „Possible SYN flooding on port“ in dmesg prüfen, mit ss -lnt ansehen, ob Recv-Q (auf accept wartende Verbindungen) des lauschenden Sockets Send-Q (backlog-Limit) erreicht. Per Mitschnitt auf dem Server prüfen, ob SYNs ankommen und SYN-ACKs zurückgehen - Spricht dafür: Beim Login-Ansturm direkt nach der Wartung steigt TcpExtListenOverflows, und Recv-Q klebt an Send-Q. Im Mitschnitt kommen SYNs desselben Clients im Sekundenabstand erneut, der Server antwortet nicht - Spricht dagegen: SYNs erreichen den Server nicht, und die Serverzähler bleiben unverändert: Firewall oder DDoS-Schutz davor hat sie verworfen, also SYN-Limits und Drop-Logs dieses Geräts prüfen. Sendet der Server SYN-ACK und der Verbindungsaufbau dauert trotzdem lange: Verlust auf dem Rückweg - Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode) - Quellen: - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Erstes RTO TCP_TIMEOUT_INIT = 1 s (Anfangswert aus RFC 6298) - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Anfangs-RTO 1 s, bei jeder Retransmission doppelt - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_syn_retries standardmäßig 6, tcp_syn_linear_timeouts standardmäßig 4 (SYN-RTO 1, 1, 1, 1, 1, 2, 4 …), letzte Retransmission nach 67 s, Aufgabe nach 131 s, somaxconn standardmäßig 4096, tcp_syncookies standardmäßig 1 - [tcp: make the first N SYN RTO backoffs linear](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccce324dabfe2143519daf50ed8b1ef1d0c542f7) · Linux kernel · Commit, der die ersten SYN-Retransmissions auf feste Abstände umstellt, ab Linux 6.5 (der Standardwert 4 folgt dem Verhalten von macOS und iOS) - [Android common kernels](https://source.android.com/docs/core/architecture/kernel/android-common) · Android (Google) · Die Common Kernels 5.10 bis 6.18 werden parallel unterstützt, und Kernel für frühere Plattformen (z. B. android14-6.1) können für Markteinführung oder Upgrade neuer Android-Geräte verwendet werden - [TcpMaxConnectRetransmissions](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938209(v=technet.10)) · Microsoft · Früherer Windows-Standard: 2 SYN-Retransmissions, erste Wartezeit 3 s, jeweils verdoppelt, nach der letzten wird noch einmal doppelt so lange gewartet, dann aufgegeben (3+6+12=21 s) - [TCP/IP connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) · Microsoft · Die Zahl der SYN-Retransmissions unterscheidet sich je nach OS, Prüfung über Max SYN Retransmissions in netsh int tcp show global - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Das backlog-Argument von listen wird auf somaxconn gekappt (ab Linux 5.4 standardmäßig 4096, vorher 128) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · Ist die accept-Warteschlange voll, werden SYNs verworfen, und TcpExtListenOverflows und TcpExtListenDrops steigen gemeinsam, TcpExtTCPSynRetrans - [net/ipv4/tcp_input.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · Logmeldung „Possible SYN flooding on port …“ - [net/ipv4/tcp_diag.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Bei lauschenden Sockets ist Recv-Q in ss die Zahl der Verbindungen, die auf accept warten, Send-Q das backlog-Limit ## Quellen nach Kapitel ### #l-client-game - [Slow rendering](https://developer.android.com/topic/performance/vitals/render) · Android (Google) · Für 60 FPS muss ein Frame in 16 ms gezeichnet sein, sonst wird ein Frame übersprungen, was als Ruckeln sichtbar wird - [Interpolation and extrapolation (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/interpolation.html) · Unity · Interpolation, die zwischen vereinzelt eintreffenden Snapshots verbindet, Extrapolation, die bei verspäteten Daten mit gleicher Richtung und Geschwindigkeit weiterführt, und deren Obergrenze - [Introduction to prediction (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/intro-to-prediction.html) · Unity · Vorhersage, bei der sich der Client mit den eigenen Eingaben bewegt, ohne auf das Serverergebnis zu warten, bei Abweichung vom Server wird korrigiert - [Peeking into VALORANT's Netcode](https://technology.riotgames.com/news/peeking-valorants-netcode) · Riot Games · Puffert man unregelmäßig eintreffende Daten, wird die Darstellung flüssig, die Latenz steigt aber entsprechend, und liegt eine Schätzung falsch, springt oder rutscht der Charakter - [Garbage collection modes](https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html) · Unity · GC-Spitze im Experiment: Ohne inkrementelle GC steht der Main-Thread still, während der ganze Heap geprüft wird, und überschreitet das Frame-Budget von 16 ms - [Scripting.GarbageCollector.CollectIncremental](https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.CollectIncremental.html) · Unity · Zeitscheibe von 3 ms der inkrementellen GC im Experiment: Standardwert von incrementalTimeSliceNanoseconds ist 3 ms - [Shader loading](https://docs.unity3d.com/Manual/shader-loading.html) · Unity · Laden eines neuen Gebiets im Experiment: Wird eine Shader-Variante zum ersten Mal genutzt, kann alles stehen bleiben, während der Treiber sie für die GPU erzeugt - [Frame Pacing library](https://developer.android.com/games/sdk/frame-pacing) · Android (Google) · V-Sync-Grenze im Experiment: Ein 60-Hz-Bildschirm zeigt das vorherige Bild noch einmal, wenn kein neuer Frame vorliegt - [Set fixed timestep to optimize physics simulation frequency](https://docs.unity3d.com/Manual/physics-optimization-cpu-frequency.html) · Unity · Aufholen mit festem Zeitschritt im Experiment: Dauert ein Frame länger als das Schrittintervall, laufen mehrere Schritte in einem Frame, und die Last steigt - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Obergrenze beim Aufholen im Experiment (dort höchstens 5 Schritte pro Frame): Unity begrenzt die Spielzeit eines Frames auf höchstens 1/3 s, um eine Aufholspirale zu verhindern, die Spieluhr fällt um die überzählige Zeit zurück ### #l-client-os - [Multitasking](https://learn.microsoft.com/en-us/windows/win32/procthread/multitasking) · Microsoft · Präemptives Multitasking: Jeder Thread bekommt eine Zeitscheibe (etwa 20 ms, je nach OS und CPU), ist sie verbraucht, kommt der nächste Thread dran - [Scheduling Priorities](https://learn.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities) · Microsoft · Unter den lauffähigen Threads erhalten die mit der höchsten Priorität reihum (Round Robin) Zeitscheiben - [Priority Boosts](https://learn.microsoft.com/en-us/windows/win32/procthread/priority-boosts) · Microsoft · Die Priorität des Prozesses im Vordergrundfenster wird mindestens auf die Priorität von Hintergrundprozessen angehoben - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Jeder Socket hat einen Empfangspuffer (SO_RCVBUF), Standard- und Maximalgröße legen Systemeinstellungen fest - [Wi-Fi low-latency mode](https://source.android.com/docs/core/connect/wifi-low-latency) · Android (Google) · Im WLAN-Modus mit niedriger Latenz ab Android 10 schaltet das Framework das WLAN-Energiesparen (Doze) ausdrücklich ab (wenn die App im Vordergrund und der Bildschirm eingeschaltet ist) - [Cached apps freezer](https://source.android.com/docs/core/perf/cached-apps-freezer) · Android (Google) · Ab Android 14 werden Apps im Cache-Zustand nach 10 s eingefroren und bekommen keine CPU-Zeit mehr - [Extending your app’s background execution time](https://developer.apple.com/documentation/uikit/extending-your-app-s-background-execution-time) · Apple · iOS pausiert Apps einige Sekunden nach dem Wechsel in den Hintergrund - [_WDF_TIMER_CONFIG (wdftimer.h)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdftimer/ns-wdftimer-_wdf_timer_config) · Microsoft · Timer 15,6 ms im Experiment: Standardintervall des Windows-System-Clock-Ticks 15,6 ms - [timeBeginPeriod function (timeapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod) · Microsoft · Timer 1 ms im Experiment: Programme können mit timeBeginPeriod eine höhere Timer-Auflösung anfordern - [Customize the Windows performance power slider](https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/customize-power-slider) · Microsoft · Energiesparmodus im Experiment: Die Windows-Energiemodi ändern Strom- und CPU-Einstellungen so, dass die Akkulaufzeit steigt und die Leistung sinkt - [Thermal API](https://developer.android.com/games/optimize/adpf/thermal) · Android (Google) · Überhitztes Smartphone im Experiment: Geräte halten hohe Leistung nur begrenzte Zeit und werden danach wegen der Hitze gedrosselt ### #l-memory - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Grundlage der Tabelle mit Größenordnungen: L1-Cache 0,5 ns, L2 7 ns, Hauptspeicher 100 ns, Round Trip im selben Rechenzentrum 0,5 ms, Disk-Seek 10 ms (Stand 2009, die Cache-Werte der Tabelle sind leicht abweichende Schätzwerte) - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · 99,99-%-Latenz (Four-Nines-Latency) von Server-NVMe-SSDs 130 µs: Beleg dafür, dass SSD-Lesen und Zurücklesen aus dem Swap in der Tabelle bei etwa 100 µs liegen - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rto_min_us standardmäßig 200000 µs: Linux wartet mindestens 200 ms bis zur TCP-Retransmission (Zeile TCP-Retransmission in der Tabelle) - [What is NUMA?](https://docs.kernel.org/mm/numa.html) · Linux kernel · Speicher auf der Seite einer anderen CPU (entfernter Speicher) ist langsamer im Zugriff und hat weniger Bandbreite als lokaler Speicher (Zeile NUMA in der Tabelle) - [JEP 439: Generational ZGC](https://openjdk.org/jeps/439) · OpenJDK · G1-Pausen dauern einige ms bis einige Sekunden, ZGC-Pausen höchstens 1 ms (im Text: GC über den ganzen Heap mehrere hundert ms bis einige Sekunden, in der Tabelle: GC bei großem Heap 1 s) - [Available Collectors](https://docs.oracle.com/en/java/javase/25/gctuning/available-collectors.html) · Oracle · ZGC gibt etwas Durchsatz ab und hält die maximale Pause unter 1 ms, die Pause hängt nicht von der Heap-Größe ab - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · Generationelle GC: Minor Collections nur über die Young Generation sind kurz, Major Collections über den ganzen Heap dauern deutlich länger (Modus „Generationell“ im GC-Experiment) - [The Z Garbage Collector](https://docs.oracle.com/en/java/javase/25/gctuning/z-garbage-collector1.html) · Oracle · ZGC erledigt teure Arbeit nebenläufig und pausiert nicht länger als 1 ms, reicht die Rückgewinnung aber nicht, kann die Anwendung stehen bleiben und auf die GC warten (Modus „Concurrent“ im GC-Experiment) - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Die Markierungsphase der GC nutzt 25 % der CPU, das Programm wird in dieser Zeit langsamer, und bei vielen Allokationen helfen Goroutinen der GC (Assist) und verzögern sich dadurch (Modus „Concurrent“ im GC-Experiment) - [Go 1.8 Release Notes](https://go.dev/doc/go1.8) · Go · Go-GC-Pausen liegen meist unter 100 µs - [Debug a memory leak in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak) · .NET · Auch mit GC entsteht ein Leck, wenn nicht mehr benötigte Objekte weiter referenziert werden - [Concepts overview](https://docs.kernel.org/admin-guide/mm/concepts.html) · Linux kernel · Bei Speichermangel werden Page Cache und auslagerbare Seiten zurückgewonnen, reicht das nicht, beendet der OOM-Killer Prozesse zwangsweise (Leck-Experiment) ### #l-disk - [Exos X18 Data Sheet](https://www.seagate.com/www-content/datasheets/pdfs/exos-x18-mango-DS2045-1N-2007US-en_US.pdf) · Seagate · 4K-Random-Read einer HDD mit 7.200 U/min: 170 IOPS, mittlere Rotationslatenz 4,16 ms (im Text: HDD gut 150 Zugriffe, HDD im Disk-Experiment) - [D3-S4520 SSD](https://www.solidigm.com/products/data-center/d3/s4520.html) · Solidigm · SATA-SSD: 4-KB-Random-Read/-Write bis zu 92K/48K IOPS (im Text: SSD einige Zehntausend Zugriffe) - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · NVMe-SSD: Random Read/Write 1.000K/200K IOPS (im Text: einige Hunderttausend Zugriffe) - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · gp3 standardmäßig 3.000 IOPS, gp2 kann mit I/O-Credits bis 3.000 IOPS bursten und fällt ohne Credits auf die Basisleistung zurück - [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) · AWS · Kleine Instanzen erreichen die maximale EBS-Leistung nur 30 Minuten pro 24 Stunden und fallen dann auf die Basisleistung zurück (z. B. t4g.2xlarge: Basis 4.000, maximal 15.700 IOPS, Annahme für „Cloud (Burst)“ im Disk-Experiment) - [Managed disk bursting](https://learn.microsoft.com/en-us/azure/virtual-machines/disk-bursting) · Microsoft Azure · Kleine Datenträger und VMs können mit Credits bis zu 30 Minuten bursten - [Concepts overview](https://docs.kernel.org/admin-guide/mm/concepts.html) · Linux kernel · In Dateien geschriebene Daten landen zuerst im Page Cache, werden als dirty markiert und später auf den Datenträger geschrieben - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · Erreichen die ausstehenden Schreibvorgänge dirty_ratio, muss der schreibende Prozess das Schreiben auf den Datenträger selbst übernehmen (Schreiblimit des OS im Disk-Experiment) - [fsync(2) — Linux manual page](https://man7.org/linux/man-pages/man2/fsync.2.html) · Linux man-pages · fsync blockiert, bis das Gerät den Abschluss des Schreibvorgangs meldet ### #l-db - [How MySQL Uses Indexes](https://dev.mysql.com/doc/refman/8.4/en/mysql-indexes.html) · MySQL · Ohne Index wird die ganze Tabelle ab der ersten Zeile gelesen (Full Table Scan) - [InnoDB Locking](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html) · MySQL · Anfragen, die dieselbe Zeile ändern wollen, warten, bis die Transaktion mit der Zeilensperre endet (Hot Row) - [Number Of Database Connections](https://wiki.postgresql.org/wiki/Number_Of_Database_Connections) · PostgreSQL · Sind die DB-Ressourcen ausgeschöpft, sinkt der Durchsatz trotz zusätzlicher Verbindungen (Beleg dafür, dass im DB-Experiment ein größerer Pool alles verlangsamt, wenn CPU-Kerne fehlen) - [WAL Configuration (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-configuration.html) · PostgreSQL · Ein Checkpoint schreibt standardmäßig alle 5 Minuten oder alle 1 GB WAL die Dirty Pages gesammelt weg, eine teure Operation, die Schreibvorgänge werden verteilt, um I/O-Spitzen zu vermeiden - [Semisynchronous Replication](https://dev.mysql.com/doc/refman/8.4/en/replication-semisync.html) · MySQL · Fällt bei asynchroner Replikation die Primär-DB aus, fehlen committete Transaktionen eventuell auf der Standby-DB (Rollback nach dem Failover) - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Streaming-Replikation ist standardmäßig asynchron, zwischen Commit und Übernahme ins Replikat gibt es eine Verzögerung (gerade Geschriebenes ist im Replikat noch nicht sichtbar) - [Asynchronous Commit (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-async-commit.html) · PostgreSQL · Kompromiss: Werden Schreibvorgänge gesammelt und verzögert auf den Datenträger geschrieben, wird es schneller, bei einem Ausfall gehen aber die letzten Änderungen verloren (dieselbe Struktur wie bei Spielservern, die alle paar Minuten speichern) ### #judge - [Service Level Objectives (Site Reliability Engineering, ch. 4)](https://sre.google/sre-book/service-level-objectives/) · Google · Perzentile (50., 95., 99.) zeigen Form und Tail der Latenzverteilung besser als der Durchschnitt - [The Tail at Scale](https://research.google/pubs/the-tail-at-scale/) · Google · Je größer das System, desto stärker bestimmen gelegentliche lange Verzögerungen (Tail-Latency) das Erlebnis des ganzen Dienstes - [RFC 3550: RTP, A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550) · IETF · Definition und Berechnung des Interarrival-Jitters (Jitter der Ankunftsabstände) - [RFC 1812: Requirements for IP Version 4 Routers](https://www.rfc-editor.org/rfc/rfc1812) · IETF · Router müssen die Rate von ICMP-Fehlermeldungen wie Time Exceeded begrenzen können und dürfen auch Echo Replies begrenzen (Vorsicht bei der Interpretation von mtr und ping) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · icmp_ratelimit und icmp_ratemask: Linux begrenzt ICMP-Antworten wie Time Exceeded und Destination Unreachable standardmäßig - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · Felder rtt (mittlere Umlaufzeit)/rttvar in ss -ti - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · pidstat -t: CPU-Auslastung pro Thread - [bcc tools: runqlat examples](https://raw.githubusercontent.com/iovisor/bcc/master/tools/runqlat_example.txt) · IO Visor · Messung der Verteilung der Run-Queue-Latenz (Zeit, die Threads auf die CPU warten) - [RIPE Atlas documentation](https://atlas.ripe.net/docs/) · RIPE NCC · Öffentliches Tool für synthetisches Monitoring, das ping und traceroute von Messpunkten auf der ganzen Welt ausführt - [GeoLite2 Free Geolocation Data](https://dev.maxmind.com/geoip/geolite2-free-geolocation-data) · MaxMind · Öffentliche Datenbank, die IP-Adressen Land und ASN zuordnet - [View CloudWatch metrics for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · Standard-Monitoring im 5-Minuten-Takt, detailliertes Monitoring im 1-Minuten-Takt (ein langes Aggregationsintervall verdeckt kurze Spitzen) ### #l-nic - [NAPI](https://docs.kernel.org/networking/napi.html) · Linux kernel · Meldet das Gerät neue Pakete per Interrupt, holt der Kernel sie per NAPI ab und verarbeitet sie, das Bündeln (Zusammenfassen) von Interrupts übernimmt meist das Gerät - [Scaling in the Linux Networking Stack](https://docs.kernel.org/networking/scaling.html) · Linux kernel · Aufbau mit RSS, das mehrere Empfangs-Queues auf mehrere Kerne verteilt, ein Interrupt pro Queue, Auswahl der Queue per Hash - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · Pakete, die das Gerät mangels Puffer verworfen hat (rx_missed_errors), und treiberspezifische Statistiken in ethtool -S - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Ringpuffer (-G), Interrupt-Coalescing (-C), Empfangs-Hash (-N) und Statistiken (-S) einstellen und prüfen - [How to receive a million packets per second](https://blog.cloudflare.com/how-to-receive-a-million-packets/) · Cloudflare · Messung: Mit einer Queue und einem Kern ist bei etwa 350.000–430.000 Paketen pro Sekunde Schluss, für 1 Mio. pps braucht es mehr Queues und Kerne (die Simulation nimmt großzügiger 700.000 pps pro Kern an) - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Überschreitet eine Cloud-Instanz ihre Limits für Bandbreite, PPS oder Connection Tracking, werden Pakete außerhalb der Instanz in eine Warteschlange gestellt und dann verworfen, Zähler für Limitüberschreitungen ### #l-server-os - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Verbindungswarteschlange (Backlog) und Obergrenze somaxconn (ab 5.4 standardmäßig 4096, vorher 128) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · Ist die accept-Warteschlange voll, verwirft Linux Verbindungsanfragen (SYN) und erhöht TcpExtListenOverflows - [listen function (winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen) · Microsoft · Windows meldet dem Client bei voller Warteschlange WSAECONNREFUSED - [getrlimit(2) — Linux manual page](https://man7.org/linux/man-pages/man2/getrlimit.2.html) · Linux man-pages · RLIMIT_NOFILE: Obergrenze der fds, die ein Prozess öffnen kann, bei Überschreitung EMFILE - [systemd-system.conf(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd-system.conf.5.html) · systemd · Standard-fd-Limit für Dienste 1024:524288 (Konfigurationsfehler mit fd-Limit 1024 in der Simulation) - [The /proc Filesystem](https://docs.kernel.org/filesystems/proc.html) · Linux kernel · Der OOM-Killer wählt den zu beendenden Prozess über einen Punktwert (badness) nach Anteil am Speicherverbrauch, anpassbar über oom_score_adj - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · Wird memory.max erreicht und lässt sich nichts zurückgewinnen, läuft der OOM-Killer innerhalb dieser cgroup, cpu.max setzt das CPU-Limit - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal: CPU-Zeit, die in virtualisierten Umgebungen an andere Betriebssysteme verloren geht - [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) · AWS · Mit exponentiellem Backoff allein ballen sich die Wiederholungen, erst Zufall (Jitter) verringert die Konkurrenz (Wiederholungsverfahren in der Simulation) ### #l-socket - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · TCP ist ein zuverlässiger Bytestream, der die Reihenfolge einhält, Definition von Nagle und Delayed ACK - [RFC 768: User Datagram Protocol](https://www.rfc-editor.org/rfc/rfc768) · IETF · UDP garantiert weder Zustellung noch Schutz vor Duplikaten - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · UDP-Anwendungen, die Zuverlässigkeit und Reihenfolge brauchen, müssen sie selbst implementieren - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP-Socket-Optionen wie TCP_NODELAY, TCP_USER_TIMEOUT und Keepalive - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Socket-Optionen SO_SNDBUF, SO_RCVBUF, SO_KEEPALIVE und SO_LINGER - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast Retransmit nach 3 doppelten ACKs, nach einer Retransmission per Timer beträgt das Congestion Window 1 Segment (Lehrbuchregeln der Simulation) - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK erkennt Verluste anhand der Sendezeit und kommt ohne Zählen doppelter ACKs aus - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Empfehlung: RTO mindestens 1 s, bei jedem Ablauf doppelt so lang (Backoff) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Linux: tcp_rto_min_us standardmäßig 200 ms, Verlusterkennung per RACK (tcp_recovery) - [include/net/tcp.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Linux-Delayed-ACK von 40 ms in der Simulation: TCP_DELACK_MIN (HZ/25 = 40 ms), höchstens TCP_DELACK_MAX (HZ/5 = 200 ms) - [Design issues - Sending small data segments over TCP with Winsock](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/windows/win32/data-segment-tcp-winsock) · Microsoft · Windows-Delayed-ACK von 200 ms in der Simulation: Beim Datenempfang startet ein Delayed-ACK-Timer von 200 ms, im Zusammenspiel mit Nagle warten kleine Pakete auf das ACK - [RFC 896: Congestion Control in IP/TCP Internetworks](https://www.rfc-editor.org/rfc/rfc896) · IETF · Ursprünglicher Zweck der Nagle-Regel: das Problem entfernter Terminals, bei denen für jedes Byte Tastatureingabe ein 41-Byte-Paket gesendet wurde - [send(2) — Linux manual page](https://man7.org/linux/man-pages/man2/send.2.html) · Linux man-pages · Ist der Sendepuffer voll, kehrt ein blockierendes send() nicht zurück ### #journey - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Laufzeit in Glasfaser 5 µs/km (1.000 km einfache Strecke 5 ms), bis 150 ms in einer Richtung für die meisten Anwendungen kaum spürbar, stark interaktive Aufgaben leiden aber schon unter 100 ms - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Latenz der Internetstrecke je Serverstandort im Experiment: von Seoul aus Region Busan 8 ms, Tokio 30 ms, Singapur 68 ms, US-Westküste 124–136 ms, Europa 234–244 ms (Median der Round Trips) - [The Internet at the Speed of Light (HotNets 2014)](https://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final111.pdf) · ACM · Umwegfaktor 1,5 im Experiment: Reale Router-Pfade sind im Median etwa 1,5-mal so lang wie eine direkte Glasfaserstrecke - [Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s)](https://www.itu.int/pub/R-REP-M.2134-2008) · ITU · Anforderung an die Latenz der LTE-Advanced-Funkstrecke in einer Richtung: unter 10 ms (ohne Last, kleine Pakete, der LTE-Wert im Experiment nimmt zusätzlich Last und Wartezeit beim Scheduling an) - [Report ITU-R M.2410: Minimum requirements related to technical performance for IMT-2020 radio interface(s)](https://www.itu.int/pub/R-REP-M.2410-2017) · ITU · Anforderung an die Latenz der 5G-Funkstrecke (IMT-2020) in einer Richtung: 4 ms (eMBB, ohne Last) - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Router-Warteschlange im Experiment: Bei Heimroutern kann die Wartezeit bei gleichzeitigem Upload und Download auf mehrere hundert ms steigen (maximal etwa 400 ms) - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Über DDoS-Schutz im Experiment: Nur eingehender Traffic läuft über das Schutznetz, die Antworten des Servers gehen direkt ins Internet (DSR) ### #l-home - [RFC 7567: IETF Recommendations Regarding Active Queue Management](https://www.rfc-editor.org/rfc/rfc7567) · IETF · Aufgestaute Warteschlangen in Geräten sind eine Hauptursache für Latenz im Internet, Empfehlung, Warteschlangenverwaltung (AQM) standardmäßig einzusetzen - [RFC 8289: Controlled Delay Active Queue Management](https://www.rfc-editor.org/rfc/rfc8289) · IETF · CoDel: Ziel-Wartezeit 5 ms, Beobachtungsintervall 100 ms (SQM-Warteschlange im Experiment um die 5 ms) - [RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm](https://www.rfc-editor.org/rfc/rfc8290) · IETF · FQ-CoDel: trennt Warteschlangen pro Flow nach Adresse und Port und schickt kleine Flows, die keine Warteschlange aufbauen, zuerst hinaus - [What Can I Do About Bufferbloat?](https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/) · Bufferbloat.net · Router mit SQM-Unterstützung wie cake oder fq_codel nutzen und die SQM-Rate anhand der Latenz unter Last einstellen - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Messung an 34 Heimroutern: Wartezeit bei gleichzeitigem Upload und Download bis etwa 400 ms, Median der Haltedauer von UDP-Mappings 90 s - [Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017)](https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf) · USENIX · Auch in der WLAN-Funkwarteschlange entstehen unter Last mehrere hundert ms Latenz, langsame Geräte verbrauchen auch die Sendezeit anderer Geräte - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · Anforderung an den Timer von UDP-Mappings in NATs (mindestens 2 Minuten, empfohlen standardmäßig mindestens 5 Minuten) und Erneuerung durch ausgehende Pakete - [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325) · IETF · WLAN nutzt CSMA/CA: Ist der Kanal belegt, wird gewartet und nach einem zufälligen Backoff gesendet - [Resolve Wi-Fi and Bluetooth issues caused by wireless interference](https://support.apple.com/en-us/102319) · Apple · Störung durch Mikrowelle im Experiment: Mikrowellen, Bluetooth usw. stören 2,4-GHz-WLAN, ein Wechsel auf 5 GHz hilft - [RFC 9438: CUBIC for Fast and Long-Distance Networks](https://www.rfc-editor.org/rfc/rfc9438) · IETF · Anpassung der Upload-Rate im Experiment: CUBIC verkleinert das Sendefenster bei Verlust auf das 0,7-Fache (ca. 30 % weniger) und vergrößert es dann wieder ### #l-isp - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Laufzeit in Glasfaser 5 µs/km: Licht legt in Glasfaser etwa 200.000 km pro Sekunde zurück, 1.000 km hin und zurück dauern mindestens 10 ms - [The Internet at the Speed of Light (HotNets 2014)](https://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final111.pdf) · ACM · Reale Router-Pfade sind im Median etwa 1,5-mal so lang wie eine direkte Glasfaserstrecke, der minimale Ping ist 3,2-mal so hoch wie die Laufzeit mit Lichtgeschwindigkeit (etwa doppelt so hoch wie über eine direkte Glasfaserstrecke) - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Gemessene Medianwerte für Round Trips ab Seoul: Tokio 30 ms, US-Westküste 124–136 ms, Europa 234–244 ms (Korea–Europa etwa das 2,8-Fache der direkten Glasfaserstrecke) - [AAE-1 & SMW5 cable cuts impact millions of users across multiple countries](https://blog.cloudflare.com/aae-1-smw5-cable-cuts/) · Cloudflare · Traffic zwischen Europa und Asien läuft meist über Ägypten, Reparaturen an Unterseekabeln dauern Tage bis Wochen - [Quantifying the Causes of Path Inflation (SIGCOMM 2003)](https://conferences.sigcomm.org/sigcomm/2003/papers/p113-spring.pdf) · ACM · Peering-Richtlinien zwischen Providern und Interdomain-Routing verlängern Routen erheblich - [Inferring Persistent Interdomain Congestion (SIGCOMM 2018)](https://www.caida.org/catalog/papers/2018_inferring_persistent_interdomain_congestion/inferring_persistent_interdomain_congestion.pdf) · ACM · Manche Übergänge zwischen Providern zeigen wiederkehrende Überlast, bei der zu jeder täglichen Stoßzeit Latenz und Paketverlust steigen - [RFC 4271: A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271) · IETF · BGP tauscht Routing-Informationen im Internet aus, empfohlener Standardwert für die Hold Time: 90 s - [BGP updates in 2024](https://blog.apnic.net/2025/01/07/bgp-updates-in-2024/) · APNIC · Die Zeit, bis sich das Routing nach einem Routenwechsel wieder stabilisiert, beträgt im Tagesmittel 25–35 s bei IPv4 und 40–50 s bei IPv6 - [Delayed Internet Routing Convergence (SIGCOMM 2000)](https://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf) · ACM · Nach einem Routenausfall dauert die Konvergenz bis zu einigen Minuten, in dieser Zeit steigen Paketverlust und Latenz (Messung aus dem Jahr 2000) ### #l-dc-net - [High-Resolution Measurement of Data Center Microbursts (IMC 2017)](https://conferences.sigcomm.org/imc/2017/papers/imc17-final60.pdf) · ACM · Die Ende-zu-Ende-Latenz in Rechenzentrumsnetzen liegt unter 1 ms, über 70 % der Bursts enden innerhalb einiger Dutzend µs und sind in der durchschnittlichen Auslastung nicht zu sehen - [Data Center TCP (DCTCP) (SIGCOMM 2010)](https://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p63.pdf) · ACM · Bei Standard-Switches teilen sich mehrere Ports flache Puffer. Laufen kurzzeitig mehrere Flows auf einem Port zusammen, läuft der Puffer über, und es kommt zu Verlust - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Maximale Zahl von Einträgen in der Connection-Tracking-Tabelle und Standard-Haltedauern (UDP 30 s, Stream 120 s, etablierte TCP-Verbindungen 5 Tage) - [Edit attributes for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html) · AWS · Idle-Timeout des ALB standardmäßig 60 s, danach schließt der Load-Balancer die Verbindung - [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) · AWS · Load-Balancer-Standardwerte im Experiment: NLB TCP 350 s, UDP 120 s (nicht änderbar), nach Leerlauf wird das Tracking stillschweigend beendet - [Configure load balancer TCP reset and idle timeout](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout) · Microsoft Azure · Idle-Timeout des Azure Load Balancer standardmäßig 4 Minuten - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Standardwerte des Connection Trackings in Security Groups, Hinweis, dass TCP-Idle-Timeouts von Load-Balancern und Firewalls häufig bei 60–90 Minuten liegen - [Flow-Based Sessions](https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-based-session-for-srx-series-devices.html) · Juniper Networks · Firmen-Firewall im Experiment: Standard-Session-Timeout der SRX-Firewall TCP 1.800 s (30 Minuten), UDP 60 s - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · TCP-Timeout von 1 Stunde beim Heimrouter im Experiment: Median der TCP-Mappings etwa 60 Minuten. UDP-Mappings variierten je nach Gerät zwischen 30 und 691 s, Median 90 s bei einer Richtung und etwa 180 s bei beiden Richtungen - [A Multi-perspective Analysis of Carrier-Grade NAT Deployment (IMC 2016)](https://www.icir.org/vern/papers/cgn-imc16.pdf) · ACM · UDP-Timeouts im Experiment (CGNAT 30 s, Heimrouter 1 Minute): Median der UDP-Mappings bei CGN im Festnetz 35 s, im Mobilfunknetz 65 s, 74 % der gemessenen NATs höchstens 1 Minute, NATs in Heimroutern (CPE) meist 65 s - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP-Keepalive im Experiment: standardmäßig nach 2 Stunden (7.200 s) Leerlauf 9 Prüfungen im Abstand von 75 s, ohne Antwort wird die Verbindung getrennt - [Cached apps freezer](https://source.android.com/docs/core/perf/cached-apps-freezer) · Android (Google) · Mobil im Hintergrund im Experiment: Ab Android 14 werden App-Prozesse im Cache-Zustand nach 10 s eingefroren - [RFC 5880: Bidirectional Forwarding Detection (BFD)](https://www.rfc-editor.org/rfc/rfc5880) · IETF · BFD erkennt Pfadausfälle schneller als die Hellos der Routing-Protokolle im Sekundenbereich - [RFC 2923: TCP Problems with Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc2923) · IETF · Path-MTU-Blackhole, bei dem wegen blockiertem ICMP nur große Pakete verschwinden ### #basics - [Teletraffic Engineering Handbook (ITU-D Study Group 2 Question 16/2)](https://www.itu.int/dms_pub/itu-d/opb/stg/D-STG-SG02.16.2.1-2002-PDF-E.pdf) · ITU · M/M/1, mittlere Wartezeit W = A·s/(1−A): bei 50 %, 80 % und 90 % Auslastung das 1-, 4- und 9-Fache der Bearbeitungszeit. Bei gleicher Auslastung ist die Wartezeit umso kürzer, je mehr Worker (Server) es gibt und je gleichmäßiger die Ankünfte sind - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · EC2-CPUUtilization ist ein Wert für die ganze Instanz und wird standardmäßig über 5 Minuten, mit detailliertem Monitoring über 1 Minute aggregiert - [Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean, LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Zugriff auf den Hauptspeicher 100 ns, Round Trip im selben Rechenzentrum 500.000 ns (0,5 ms) - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Signallaufzeit in Glasfaser 5 µs/km (Grundlage für die Berechnung der Grenze durch die Lichtgeschwindigkeit) - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Standardwerte von Half-Life: 20 Updates pro Sekunde, Interpolation 100 ms. Bei 10 Updates pro Sekunde übersteht eine Interpolation von 200 ms ein fehlendes Update - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rto_min_us standardmäßig 200000 (200 ms) - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Einfache Reaktionszeit im Mittel etwa 231 ms (213 ms nach Korrektur der Gerätelatenz) - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Schon Latenzen unter 100 ms beeinflussen die Leistung bei Spielaufgaben, bei Aufgaben wie dem Ziehen mit der Maus fallen bereits etwa 10 ms auf - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Erfahrene Spieler bemerken im Blindtest schon Unterschiede von etwa 10 ms - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Latenztoleranz nach Genre: Ego-Perspektive etwa 100 ms, Third-Person-Perspektive (RPG, MMO) etwa 500 ms, RTS etwa 1.000 ms - [JEP 333: ZGC: A Scalable Low-Latency Garbage Collector](https://openjdk.org/jeps/333) · OpenJDK · G1 bei 128 GB Heap: Pausen im Mittel 157 ms, maximal 544 ms, ZGC unabhängig von Heap-Größe und Menge lebender Daten etwa 1–2 ms - [CommonNetworkParametersExtensions (Unity Transport 2.5)](https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/Unity.Networking.Transport.CommonNetworkParametersExtensions.html) · Unity · disconnectTimeoutMS: Wird so lange nichts empfangen, wird die Verbindung getrennt (standardmäßig 30.000 ms) ### #lab - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Interpolation zeigt die Vergangenheit, ist dafür aber flüssig. Extrapolation kennt keine Richtungswechsel und springt, wenn sie falsch liegt. Vorhersagefehler werden mit dem Serverergebnis korrigiert - [UDP vs. TCP](https://gafferongames.com/post/udp_vs_tcp/) · Gaffer On Games · Geht bei TCP ein Paket verloren, werden neue Daten auch nach ihrem Eintreffen erst nach der Retransmission weitergegeben (meist mindestens 2×RTT) - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Werden unbestätigte Eingaben in jedem Paket redundant mitgeschickt, muss nicht auf Retransmissions gewartet werden (im schlimmsten Fall Eingaben von 2 s) - [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/) · Gaffer On Games · Wird sofort nach dem Empfang gezeichnet, ruckelt es durch Jitter, ein Interpolationspuffer erhöht die Latenz etwas, glättet dafür aber die Darstellung - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Fehlen Bewegungsdaten des Clients wegen Verbindungsproblemen oder sind sie falsch, korrigiert der Server die Position (Rubberbanding) - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Ein Befehlsbudget, das sich pro Tick auffüllt, begrenzt gebündelt eintreffende Befehle. Ist es zu streng, ruckelt es auch bei normalen Spielern - [Introducing Time Dilation (TiDi)](https://www.eveonline.com/news/view/introducing-time-dilation-tidi) · CCP Games · Design, bei dem die Spieluhr bei Serverüberlast verlangsamt wird (Time Dilation), sodass alles langsamer abläuft - [CommonNetworkParametersExtensions (Unity Transport 2.5)](https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/Unity.Networking.Transport.CommonNetworkParametersExtensions.html) · Unity · Inaktivitäts-Timeout, das die Verbindung trennt, wenn eine bestimmte Zeit lang nichts empfangen wird ### #symptoms - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Fehlen Updates, bleibt das Objekt an der letzten Position stehen (Ruckeln) oder wird extrapoliert und springt dann (Teleportieren). Die Extrapolationszeit muss begrenzt werden - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Fehlen Bewegungsdaten des Clients oder weichen sie von der Serverberechnung ab, schickt der Server eine Korrektur und setzt die Position zurück (Rubberbanding) - [UDP vs. TCP](https://gafferongames.com/post/udp_vs_tcp/) · Gaffer On Games · TCP stapelt nachfolgende Daten, bis das verlorene Paket erneut empfangen ist, und gibt sie dann weiter (Zeitraffer) - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Kommen aufgestaute Eingaben auf einmal, werden mehrere Frames gebündelt berechnet, um aufzuholen - [Introducing Time Dilation (TiDi)](https://www.eveonline.com/news/view/introducing-time-dilation-tidi) · CCP Games · Time Dilation (TiDi), die die Spieluhr bei Serverüberlast verlangsamt, und das Phänomen, dass sich Aufgaben bei Überlast um Sekunden verzögern - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Die Pufferzeit hängt von der Tickrate des Servers und den Render-Frames des Clients ab - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Der Server kann vorhergesagt ausgeführte Abilities rückgängig machen (Verschluckte Aktion / Rollback) - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Actors, die der Server als nicht relevant einstuft, werden nicht repliziert oder auf dem Client gelöscht (Unsichtbar / Geisterobjekte) - [CommonNetworkParametersExtensions (Unity Transport 2.5)](https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/Unity.Networking.Transport.CommonNetworkParametersExtensions.html) · Unity · Nach Ablauf des Inaktivitäts-Timeouts wird die Verbindung getrennt (Verbindungsabbruch) ### #sync - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Prinzipien von autoritativem Server, clientseitiger Vorhersage und Serverabgleich, Interpolation und Lag-Compensation, Kompromisse wie „hinter der Ecke getroffen“ - [What Every Programmer Needs To Know About Game Networking](https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/) · Gaffer On Games · Entwicklung des Netcodes vom P2P-Lockstep über Client/Server zur clientseitigen Vorhersage - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Kompromiss zwischen Reaktionsschnelligkeit und Genauigkeit bei Local Predicted und Server Initiated - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Serverautorität, Vorhersage, Pufferung, Trefferabfrage per Zurückspulen und Obergrenze fürs Zurückspulen - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Verfahren, Events zeitgeplant nach Serverzeit abzuspielen - [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) · Game Developer · Lockstep: Befehle werden zwei Züge später eingeplant, die Zuglänge richtet sich nach dem langsamsten Rechner, konstante 500 ms Latenz sind in Ordnung, schwankende Latenz stört - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Lockstep geht erst weiter, wenn alle Eingaben da sind, ein Playout-Puffer fängt Jitter ab - [GGPO Rollback Networking SDK](https://www.ggpo.net/) · GGPO · Rollback: Das Spiel sagt Eingaben der Gegenseite voraus und läuft weiter, liegt es falsch, spult es zurück und rechnet neu - [8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2'](https://www.gdcvault.com/play/1025471/8-Frames-in-16ms-Rollback) · GDC · Rollback beseitigt das lokale Input-Delay von Lockstep, bis zu 8 Frames werden neu berechnet - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Dieselbe Latenz wirkt je nach Präzision und Zeitlimit einer Aktion sowie nach Perspektive (Ego-Perspektive, Third-Person-Perspektive, Gottperspektive) unterschiedlich - [Networking Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine) · Epic Games · Vorteile und Last für den Host eines Listen-Servers - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Einfache Reaktionszeit des Menschen etwa 0,23 s ### #partial - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Weicht ein Spieler ab, wird nur bei ihm korrigiert, die übrigen neun sehen alles flüssig. Für die Trefferabfrage per Zurückspulen gibt es eine Obergrenze - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Pakete kommen gebündelt an, etwa 2 in einem Frame und 0 im nächsten, ein Jitter-Puffer verteilt sie gleichmäßig - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Befehlsbudget, das gebündelt eintreffende Befehle auf Ticks verteilt, Nebenwirkungen zu strenger Limits - [Source SDK 2013: player_lagcompensation.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player_lagcompensation.cpp) · Valve · Obergrenze fürs Zurückspulen in der Source-Engine: sv_maxunlag standardmäßig 1 s - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · „Hinter der Ecke getroffen“ bei Lag-Compensation, Input-Delay, das die Eingaben aller angleicht - [send(2) — Linux manual page](https://man7.org/linux/man-pages/man2/send.2.html) · Linux man-pages · Ist der Sendepuffer voll, wartet send() im blockierenden Modus und kehrt im nicht blockierenden Modus sofort mit EAGAIN zurück - [Networking Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine) · Epic Games · Der Host eines Listen-Servers ist gegenüber anderen Spielern im Vorteil - [Authority (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/authority.html) · Unity · Verteilte Autorität: Jeder Client berechnet einen Teil der Objekte - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Der Server sendet jeder Verbindung nur relevante Actors, werden sie irrelevant, löscht er sie auf dem Client - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · Nachrichten für noch nicht gespawnte Objekte werden zurückgehalten und nach Ablauf einer Frist verworfen (SpawnTimeout) - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Bei fragmentierten UDP-Paketen geht das ganze Paket verloren, wenn auch nur ein Fragment fehlt - [Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE](https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse) · Microsoft · Teilen sich zwei Sockets denselben Port, ist nicht vorhersehbar, welcher die Pakete empfängt - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Teilen sich mehrere Kunden eine IP-Adresse, lassen sich Nutzer nicht allein anhand der IP unterscheiden - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Standardverhalten: Die App pausiert im Hintergrund - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Ist die Bandbreite ausgeschöpft, werden nach Priorität nur einige Actors repliziert ### #retrans - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · RTO = SRTT + max(G, 4·RTTVAR), anfangs 1 s, Empfehlung mindestens 1 s, bei jedem Ablauf doppelt, ein Maximum muss, falls vorhanden, mindestens 60 s betragen, erneut gesendete Pakete werden nicht als RTT-Stichprobe genutzt (Karn) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast Retransmit beim dritten doppelten ACK, nach einem RTO Neustart mit einem Congestion Window von 1 Segment (Loss Window) - [RFC 6675: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP](https://www.rfc-editor.org/rfc/rfc6675) · IETF · Verlustwiederherstellung, die fehlende Pakete anhand von SACK-Informationen erkennt (Signale aus doppelten ACKs und SACK für Fast Retransmit) - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · Reordering-Toleranz von RACK (min_RTT/4) und deren Anpassung per DSACK, TLP wartet 2·SRTT (bei nur einem unbestätigten Paket zuzüglich einer Reserve für Delayed ACK), das RTO wird nach dem Senden der TLP neu gesetzt, SACK ist Pflicht - [RFC 2018: TCP Selective Acknowledgment Options](https://www.rfc-editor.org/rfc/rfc2018) · IETF · SACK: Der Empfänger meldet fehlende Abschnitte - [RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP](https://www.rfc-editor.org/rfc/rfc2883) · IETF · DSACK: meldet doppelt Empfangenes und macht so unnötige Retransmissions sichtbar - [RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP](https://www.rfc-editor.org/rfc/rfc5682) · IETF · F-RTO: Erkennung unnötiger RTOs - [RFC 3522: The Eifel Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc3522) · IETF · Erkennt im Nachhinein anhand von Timestamps, ob die Wiederherstellung unnötig war (Rücknahme der Congestion-Window-Verkleinerung in der Simulation) - [RFC 7323: TCP Extensions for High Performance](https://www.rfc-editor.org/rfc/rfc7323) · IETF · Optionen Timestamps und Window Scaling, ohne Scaling beträgt das Window höchstens 64 KiB - [RFC 6937: Proportional Rate Reduction for TCP](https://www.rfc-editor.org/rfc/rfc6937) · IETF · PRR: verringert die Sendemenge während der Wiederherstellung passend zur neu zugestellten Menge (Sendelimit während der Wiederherstellung in der Simulation) - [RFC 9438: CUBIC for Fast and Long-Distance Networks](https://www.rfc-editor.org/rfc/rfc9438) · IETF · CUBIC verkleinert das Congestion Window bei Verlust auf das 0,7-Fache (Verkleinerung um 30 % in der Simulation) - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Zero-Window-Probe: Auch bei einem Window von 0 werden Probes gesendet, in exponentiell wachsenden Abständen - [RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https://www.rfc-editor.org/rfc/rfc9000) · IETF · Bei QUIC blockiert ein Verlust nur die Streams, deren Daten im betroffenen Paket stecken, andere Streams laufen weiter (Trennung der Flows) - [RFC 2475: An Architecture for Differentiated Services](https://www.rfc-editor.org/rfc/rfc2475) · IETF · Definition: Shaping verzögert Pakete, Policing verwirft den Überschuss - [RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP](https://www.rfc-editor.org/rfc/rfc3168) · IETF · ECN: meldet Überlast, ohne Pakete zu verwerfen - [Smart Queue Management](https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/) · Bufferbloat.net · SQM im Router: verringert Warteschlangenüberläufe und Bufferbloat durch Scheduling pro Flow, AQM und Shaping - [RFC 1191: Path MTU discovery](https://www.rfc-editor.org/rfc/rfc1191) · IETF · Ermittlung der Path-MTU über ICMP-Meldungen zur Größenüberschreitung (Typ 3 Code 4) - [RFC 1812: Requirements for IP Version 4 Routers](https://www.rfc-editor.org/rfc/rfc1812) · IETF · Router dürfen die Rate von ICMP-Fehlermeldungen begrenzen (mtr-Ergebnisse, bei denen nur ein Hop in der Mitte Verlust zeigt) - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Bei Mehrwege-Routing sind Diagnoseergebnisse von ping und traceroute wenig verlässlich, Festlegen des Pfads per Hash über den Flow - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_recovery (standardmäßig 0x1 RACK, ab 6.17 ist RACK die einzige Verlusterkennung, ein Wert von 0 hat dann keine Wirkung), tcp_early_retrans (standardmäßig 3, 0 schaltet TLP ab), tcp_sack, tcp_dsack und tcp_timestamps (standardmäßig aktiv), tcp_thin_linear_timeouts (weniger als 4 Pakete in flight, höchstens 6-mal linear), tcp_rto_max_ms, tcp_mtu_probing und tcp_base_mss, tcp_rto_min_us, tcp_retries2 (standardmäßig 15, ca. 924,6 s), tcp_syn_linear_timeouts, tcp_notsent_lowat - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpOutSegs enthält keine Retransmissions, Bedeutung von TCPLossProbes, TCPLossProbeRecovery, TCPLostRetransmit, TCPSpuriousRTOs, TCPDSACKRecv und TCPSynRetrans - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · In nstat angezeigte Zählernamen (RetransSegs, TCPTimeouts, TCPLossProbes, TCPSpuriousRTOs, TCPDSACKRecv usw.) - [Thin-streams and TCP](https://docs.kernel.org/networking/tcp-thin.html) · Linux kernel · Thin Streams wie bei Spielen profitieren kaum von Fast Retransmit und sind auf lange Timeouts angewiesen, TCP_THIN_LINEAR_TIMEOUTS - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_RTO_MIN 200 ms, TCP_RTO_MAX 120 s, TCP_TIMEOUT_INIT 1 s, Delayed ACK 40–200 ms (TCP_DELACK_MIN und MAX), TCP_BASE_MSS 1024, Kriterium für Thin Streams (weniger als 4 Pakete in flight) - [net/ipv4/tcp_input.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · RTO = SRTT + rttvar (mindestens das RTO-Minimum), RACK gilt nur für Verbindungen mit SACK, PRR für die Verkleinerung des Congestion Window während der Wiederherstellung - [net/ipv4/tcp_output.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_output.c?h=v6.12) · Linux kernel · TLP nur bei Verbindungen mit SACK, Wartezeit 2·RTT, bei nur einem unbestätigten Paket kommt das RTO-Minimum hinzu - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · Folgen tcp_retries1 RTOs aufeinander, gilt das als erkanntes Blackhole, und MTU-Probing startet, lineare Timeouts für Thin Streams und SYN - [net/ipv4/tcp_recovery.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_recovery.c?h=v6.12) · Linux kernel · RACK-Toleranzzeit = min(min_RTT/4 × Stufe, SRTT), Retransmissions, die schneller als die minimale RTT bestätigt werden, fließen nicht in die Berechnung ein - [net/ipv4/tcp_ipv4.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_ipv4.c?h=v6.12) · Linux kernel · Initialisierung der Standardwerte: tcp_early_retrans 3, tcp_recovery RACK, tcp_syn_linear_timeouts 4, tcp_base_mss 1024 (tcp_mtu_probing wird nicht gesetzt und ist daher 0) - [net/ipv4/tcp_bbr.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_bbr.c?h=v6.12) · Linux kernel · pacing_rate von BBR = pacing_gain × Engpass-Bandbreite (gleichmäßiges Senden per Pacing) - [tcp: use RACK to detect losses](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f41b1c58a32537542f14c1150099131613a5e8a) · Linux kernel · Einführung von RACK und tcp_recovery (Linux 4.4), anfangs als Ergänzung zum bisherigen Verfahren - [tcp: disable RFC6675 loss detection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b38a51fec1c1f693f03b1aa19d0622123634d4b7) · Linux kernel · RACK wird zur Standard-Verlusterkennung (2018, Linux 4.18) - [tcp: remove obsolete and unused RFC3517/RFC6675 loss recovery code](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c120191dcec510cc17d587ece48a7ae875a90c5) · Linux kernel · Entfernung des Codes zur Verlustwiederherstellung nach RFC6675 (Linux 6.17), mit dem Hinweis, dass RACK-TLP seit 2018 Standard ist - [tcp: make the first N SYN RTO backoffs linear](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccce324dabfe2143519daf50ed8b1ef1d0c542f7) · Linux kernel · Die ersten 4 Backoffs des SYN-RTO werden nicht verdoppelt (nach dem ersten RTO von 1 s noch viermal je 1 s, danach 2, 4 s …, Linux 6.5) - [tcp: add sysctl_tcp_rto_min_us](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f086edef71be7174a16c1ed67ac65a085cda28b1) · Linux kernel · Serverweites RTO-Minimum tcp_rto_min_us (Linux 6.11) - [tcp: add the ability to control max RTO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54a378f43425085d0684679d99735696b69165bc) · Linux kernel · Socket-Option TCP_RTO_MAX_MS, 1–120 s (Linux 6.15) - [tcp: support TCP_RTO_MIN_US for set/getsockopt use](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f38805c5d26fe4af97837c10d58074a7496638bf) · Linux kernel · Socket-Option TCP_RTO_MIN_US für ein RTO-Minimum pro Verbindung (Linux 6.15) - [Android common kernels](https://source.android.com/docs/core/architecture/kernel/android-common) · Android (Google) · Die unterstützten Android Common Kernels beginnen bei 5.10 (neuer als 4.18, mit dem RACK Standard wurde) - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_NODELAY (schaltet Nagle ab), TCP_USER_TIMEOUT (legt nur den Zeitpunkt der Aufgabe fest, die Zeitpunkte der Retransmissions bleiben unverändert), TCP_KEEPIDLE, TCP_INFO - [ip-route(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ip-route.8.html) · iproute2 · Option rto_min pro Route - [tc-fq(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-fq.8.html) · iproute2 · Pacing pro Verbindung in der fq-Queue und SO_MAX_PACING_RATE - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · TCPMSS --clamp-mss-to-pmtu: umgeht Abschnitte mit blockiertem ICMP durch Anpassung der MSS im SYN - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (ms), backoff (Zahl exponentieller Backoffs), rtt/rttvar und cwnd bei ss -i - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · Ausgaben retrans:aktuell/kumuliert, lost, reordering, bytes_sent und bytes_retrans bei ss -ti - [nstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/nstat.8.html) · iproute2 · nstat zeigt standardmäßig den Zuwachs seit dem letzten Aufruf - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Eine Zeile pro Retransmission mit Adresse, Port und Zustand, -c zählt pro Flow, -l bezieht TLP-Versuche ein - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · Detaillierte Fehler mit ip -s -s link prüfen, Bedeutung von rx_missed_errors und rx_crc_errors, treiberspezifische Statistiken in ethtool -S - [drivers/net/ethernet/intel/igb/igb_ethtool.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_ethtool.c?h=v6.12) · Linux kernel · Beispiele treiberspezifischer Zählernamen: rx_missed_errors, rx_no_buffer_count, rx_crc_errors - [Ethtool counters](https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/counters.html) · Linux kernel · rx_out_of_buffer und rx_discards_phy bei mlx5 - [net/core/net-procfs.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/net-procfs.c?h=v6.12) · Linux kernel · /proc/net/softnet_stat hat eine Zeile pro CPU in Hexadezimal, 2. Spalte dropped, 3. Spalte time_squeeze - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Bedeutung von bw_in, bw_out, pps, conntrack und linklocal_allowance_exceeded, für die Anzeige in CloudWatch muss der CloudWatch-Agent installiert sein - [High-Resolution Measurement of Data Center Microbursts](https://research.facebook.com/publications/high-resolution-measurement-of-data-center-microbursts/) · Meta · Die meisten Bursts enden innerhalb einiger Dutzend µs, die Auslastung im Minutenmittel verrät daher nicht die Ursache der Drops (IMC 2017) - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · TCP SYN mit -T (--tcp), Zielport mit -P (--port) - [pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) · Microsoft · Windows-Befehl zur Routendiagnose, der mehrfach sendet und Verlust und Latenz pro Hop berechnet - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Anzeigefilter tcp.analysis.retransmission, fast_retransmission, spurious_retransmission, duplicate_ack, lost_segment und zero_window - [7.5. TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) · Wireshark · Kriterien für Retransmission, Fast Retransmit, unnötige Retransmission und ZeroWindow - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · TCPv4 Segments Retransmitted/sec·Segments Sent/sec, Network Interface Packets Received Discarded - [TCP/IP connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) · Microsoft · Globale TCP-Einstellungen (Max SYN Retransmissions) mit netsh int tcp show global prüfen, Verlust unterwegs per gleichzeitigem Mitschnitt an beiden Enden nachweisen - [Packet Monitor (Pktmon)](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) · Microsoft · Integriertes Tool, das an mehreren Stellen des Windows-Netzwerkstacks zeigt, wo und warum Pakete verworfen werden - [Pktmon command formatting](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax) · Microsoft · Ab Windows 10 und Windows Server 2019 (ab 1809) als pktmon.exe integriert - [TCP improvements in the Windows network stack (IETF 98 TCPM)](https://datatracker.ietf.org/meeting/98/materials/slides-98-tcpm-tcp-improvements-in-windows-01) · Microsoft · Mit dem Windows 10 Anniversary Update (1607) und Server 2016 sind TLP und RACK standardmäßig aktiv (bei Verbindungen mit RTT über 10 ms), ist nur ein Paket übrig, berücksichtigt TLP 200 ms Delayed ACK - [Algorithmic improvements boost TCP performance on the Internet](https://techcommunity.microsoft.com/blog/networkingblog/algorithmic-improvements-boost-tcp-performance-on-the-internet/2347061) · Microsoft · TLP ab Windows Server 2016 Standard, das neue RACK, das auch verlorene Retransmissions repariert, ab Server 2022, PRR ab Windows 10 1903 Standard - [TcpMaxConnectRetransmissions](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938209(v=technet.10)) · Microsoft · Frühere SYN-Retransmissions unter Windows: 2-mal, ab 3 s jeweils verdoppelt ### #owners - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · NAT-Mappings müssen durch ausgehende Pakete erneuert werden (REQ-6), Erneuerung durch eingehende Pakete ist optional (für UDP). Deshalb sendet der Client die Heartbeats - [RFC 5382: NAT Behavioral Requirements for TCP](https://www.rfc-editor.org/rfc/rfc5382) · IETF · NATs dürfen Idle-TCP-Sessions löschen, das empfohlene Idle-Timeout beträgt mindestens 2 Stunden 4 Minuten (die Einstellung kann je nach Gerät abweichen) - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · TCP-Idle-Timeout des Connection Trackings in Security Groups (350 s bei Nitro-v6-Instanztypen, sonst 5 Tage, einstellbar zwischen 60 s und 5 Tagen), Empfehlung für Keepalive unter 5 Minuten, TCP über NLB 350 s - [Control subnet traffic with network access control lists](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) · AWS · Netzwerk-ACLs sind zustandslos (kein Connection Tracking), daher muss auch Antwort-Traffic per Regel eigens erlaubt werden - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Zähler für Überschreitungen der Instanzlimits für Connection Tracking und PPS (conntrack_allowance_exceeded, pps_allowance_exceeded) - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Das backlog-Argument von listen bestimmt die tatsächliche Warteschlangengröße und wird auf somaxconn gekappt, wenn es größer ist (ab 5.4 standardmäßig 4096) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · somaxconn (Obergrenze des listen-Backlogs), tcp_max_syn_backlog, tcp_syncookies (standardmäßig 1, Absicherung bei überlaufender SYN-Warteschlange), tcp_keepalive_time (standardmäßig 2 Stunden) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · Ist die accept-Warteschlange voll, werden SYNs verworfen, und TcpExtListenOverflows und TcpExtListenDrops steigen - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · conntrack-Auslastung aus nf_conntrack_count und nf_conntrack_max berechnen - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · nr_throttled in cpu.stat: wie oft der Container durch sein CPU-Limit gedrosselt wurde - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal in /proc/stat: Zeit, in der in virtualisierten Umgebungen ein anderes Betriebssystem die CPU genutzt hat - [RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm](https://www.rfc-editor.org/rfc/rfc2992) · IETF · ECMP wählt den Pfad per Hash über die Headerfelder, die den Flow identifizieren (gleicher Flow, gleicher Pfad, verschiedene Flows nehmen eventuell verschiedene Pfade) - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Routenmessung mit demselben Protokoll und Port wie das Spiel (-T, -u, -P) ### #l-server-proc - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Tick-Budget: Bei 128 Ticks muss ein Frame in 7,8125 ms fertig sein, die Frame-Zeit wird pro Subsystem gemessen und das Budget aufgeteilt - [Introducing Time Dilation (TiDi)](https://www.eveonline.com/news/view/introducing-time-dilation-tidi) · CCP Games · Die Physiksimulation von EVE Online wird einmal pro Sekunde aktualisiert, bei Überlast wird die Spieluhr verlangsamt und die zeitgebundene Last proportional verringert - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Untergrenze der Time Dilation 10 %, die O(n²)-Übertragung, bei der jede Aktion von n Spielern an n Spieler gemeldet wird, begrenzt große Schlachten - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Modell des Tick-Experiments: Hinkt der Fortschritt mit festem Intervall hinterher, werden die Aufholschritte gebündelt ausgeführt (Zeitraffer), Zeit über dem Limit wird verworfen, und die Spielzeit verlangsamt sich (Zeitlupe) - [Comparing Interest Management Algorithms for Massively Multiplayer Games](https://www.sable.mcgill.ca/~clump/papers/boulanger-06-comparing.pdf) · ACM · Paper von NetGames 2006 (Autorenfassung). Der Abstandsvergleich aller Paare skaliert nicht mit wachsender Spielerzahl, mit einem Raster werden nur die umliegenden Zellen geprüft - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · Wird die Welt in ein Raster geteilt und werden die Empfänger über Listen pro Zelle ausgewählt, spart das auch bei vielen Spielern und Actors CPU-Zeit auf dem Server - [Amdahl's Law in the Multicore Era](https://research.cs.wisc.edu/multifacet/papers/ieeecomputer08_amdahl_multicore.pdf) · IEEE · Durchsatzgrenze im Lock-Experiment: Ist der Anteil, den nur einer zur Zeit ausführen kann, 1−f, kann die Beschleunigung 1/(1−f) nicht übersteigen - [Runtime locking correctness validator](https://docs.kernel.org/locking/lockdep-design.html) · Linux kernel · Deadlock im Lock-Experiment: Werden zwei Locks in entgegengesetzter Reihenfolge genommen, entsteht durch zirkuläres Warten ein Deadlock - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Watchdog im Lock-Experiment: den Deadlock per Liveness-Probe erkennen und neu starten, standardmäßig wird alle 10 s geprüft und nach 3 Fehlschlägen in Folge neu gestartet (etwa 30 s) - [ASP.NET Core Best Practices](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices) · Microsoft · Synchrone Aufrufe: Datenzugriffe und I/O asynchron aufrufen, blockierende Aufrufe führen zu erschöpftem Thread-Pool und verzögerten Antworten ### #l-infra - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Kaskadierender Ausfall: wie ein langsames Backend Threads und Ressourcen davor bindet und sich der Ausfall durch Wiederholungen, gescheiterte Health-Checks und Neustarts mit leerem Cache ausbreitet, dazu Gegenmaßnahmen - [Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) · Microsoft Azure · Zustände Closed, Open und Half-Open des Circuit-Breakers und Schwelle nach Fehleranzahl, bei langen Timeouts bleiben Threads gebunden, bis der Circuit-Breaker öffnet - [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead) · Microsoft Azure · Ressourcen nach Funktion und Aufrufziel isolieren, damit sich ein Ausfall an einer Stelle nicht ausbreitet - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Ressourcen per Timeout freigeben, Wiederholungen in der Zahl begrenzen und mit Jitter versehen - [The Unique Architecture behind Amazon Games’ Seamless MMO New World](https://aws.amazon.com/blogs/gametech/the-unique-architecture-behind-amazon-games-seamless-mmo-new-world/) · AWS · Beispiel für eine MMO-Serverarchitektur: Eingangsserver, Simulationsserver pro Rasterzelle (Hubs), gemeinsamer Serverpool für Sessions, DB zum Speichern des Zustands - [Working with DB instance read replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) · AWS · Replikationsverzögerung im Architektur-Experiment: Lese-Replikate werden asynchron aktualisiert und können veraltete Daten liefern - [Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/) · Google · Deployment und Neustart: im Lame-Duck-Zustand neue Anfragen umleiten, dann beenden, direkt nach dem Neustart aufwärmen - [Amazon EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) · AWS · Bei Scale-out und Scale-in Instanzen in einen Wartezustand versetzen und Vorbereitungs- und Aufräumarbeiten abschließen (standardmäßig bis zu 1 Stunde) - [systemd.service(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.service.5.html) · systemd · Watchdog im Architektur-Experiment: Dienste, deren Lebenszeichen ausbleibt, werden beendet und automatisch neu gestartet ## Graphmuster - **Spitzen in festen Abständen** (`periodic`): Der Wert ist sonst niedrig und schießt in gleichen Abständen hoch, etwa alle paar Sekunden, alle paar Minuten oder zur vollen Stunde. - **Vereinzelte Spitzen ohne Muster** (`random`): Schießt ohne festen Abstand unregelmäßig hoch und normalisiert sich bald wieder. - **Stufe ab einem bestimmten Zeitpunkt** (`step`): Steigt ab einem bestimmten Zeitpunkt, etwa einem Patch, einer Konfigurationsänderung oder einem Routenwechsel, um eine Stufe und bleibt dort. - **Langsamer Anstieg** (`ramp`): Steigt über Stunden oder Tage allmählich an und wächst mit der Laufzeit. - **Steigt langsam, fällt abrupt** (`sawtooth`): Steigt langsam und fällt beim Neustart oder Aufräumen abrupt ab, immer wieder. - **Nur zu bestimmten Tageszeiten hoch** (`peak`): Steigt wie ein Hügel nur zu denselben Tageszeiten, etwa zur abendlichen Stoßzeit. - **Steigt mit Spielerzahl und Last** (`load`): Nehmen gleichzeitige Verbindungen oder die Zahl der Spieler an einem Ort zu, steigt der Wert mit, und zwar steiler als diese. - **Plateau am Limit** (`ceiling`): Durchsatz oder Verbindungszahl erreichen einen bestimmten Wert und steigen nicht weiter. Ab dann nehmen Wartezeiten und Fehler zu. - **Von Anfang an dauerhaft hoch** (`high`): Bleibt ohne Ausschläge dauerhaft auf hohem Niveau. Typisch für strukturelle Ursachen wie Entfernung, Route oder Design. - **Nur einzelne Ausreißer** (`outlier`): Das meiste ist normal, nur bestimmte Spieler, Regionen, Provider oder Geräte liegen deutlich höher. - **Lücke, dann alles auf einmal** (`gap`): Die empfangene Menge fällt eine Zeit lang auf 0 und kommt dann auf einen Schlag. - **Verbindungen brechen gleichzeitig ab** (`drop`): Die Zahl der Verbindungen bricht ein, oder die Zahl der Abbrüche schießt schlagartig hoch. - **Ansturm direkt nach Login oder Wartung** (`surge`): Schießt direkt nach dem Serverstart oder dem Beginn eines Events stark hoch und flacht dann allmählich ab. ## Playbooks für typische Situationen ### Lag nach einem Patch Wenn sich seit einem bestimmten Patch oder Deployment die Lag-Meldungen häufen. Gedacht für Fälle, in denen sich Meldungen wie „Seit dem letzten Update stimmt etwas nicht“ sammeln oder ein Graph ab einem bestimmten Zeitpunkt stufenartig ansteigt und oben bleibt. 1. **Startzeitpunkt festlegen und alle Änderungen davor und danach sammeln**: Ermitteln Sie den Zeitpunkt, an dem sich die ersten Meldungen häuften, und den Zeitpunkt, an dem der Graph stufenartig anstieg. Notieren Sie lückenlos alle Änderungen, die davor und danach ausgerollt wurden. Dazu gehören Client-Patches, Server-Deployments, Konfigurationsänderungen, Schemaänderungen (DDL) und Neustarts der DB, Arbeiten an Netzwerk und Firewall sowie ausgetauschte Infrastruktur (Instanztyp, Kernel, Treiber). Wer bei jedem Deployment mit der Annotationsfunktion des Monitoring-Tools eine vertikale Linie in alle Graphen setzt, ist mit diesem Schritt schnell fertig. Wurden ein Spiel-Patch und Infrastrukturarbeiten im selben Wartungsfenster ausgerollt, führen Sie beide als Kandidaten weiter. Zuerst hinzuziehen: beide Teams, die Änderungen ausgerollt haben (Entwicklungsteam und Infrastrukturteam). (Ursachen: in-deploy, so-os-update, db-ddl-lock, db-plan-flip, db-cold-cache) 2. **Betroffenenkreis aufschlüsseln: Build, Gerät, Server, Region**: Prüfen Sie, entlang welcher Dimension sich das Problem häuft. Sind nur Spieler mit dem neuen Build betroffen, liegt der erste Verdacht beim Client; bei bestimmten Betriebssystemen, Grafikkarten oder Geräten bei Client-Performance oder Treibern; bei bestimmten Servern, Kanälen oder Zonen beim Server; bei bestimmten Ländern oder Providern bei der Netzwerkroute. Sind alle gleichzeitig betroffen, stehen zuerst gemeinsam genutzte Ressourcen (DB, Load-Balancer, Gateway) oder das gerade ausgerollte Server-Deployment unter Verdacht. Enthält die Client-Telemetrie die Build-Nummer, stellen Sie Ping, FPS, Frametime-Spitzen und die Zahl der Verbindungsabbrüche von altem und neuem Build nebeneinander. Bleibt der Ping gleich und sinken nur die FPS, liegt es eher an der Client-Performance als am Netzwerk. Zuerst hinzuziehen: bei Häufung nach Build oder Gerät das Entwicklungsteam (Client); bei Häufung nach Server oder Kanal das Entwicklungsteam (Server), wenn die Host-Metriken normal sind, sonst das Infrastrukturteam (Server/OS); bei Häufung nach Land oder Provider das Infrastrukturteam (Netzwerk). (Ursachen: cg-hitch, cg-sync-load, co-vram, cg-crash) 3. **Neue und alte Version im selben Zeitraum vergleichen**: Ein reiner Vorher-nachher-Vergleich vermischt Schwankungen durch Wochentag, Tageszeit und Events und trübt das Urteil. Spielen Sie die neue Version nach Möglichkeit zuerst auf einige Server auf (Canary) und vergleichen Sie diese im selben Zeitraum mit Servern der alten Version (Kontrollgruppe): Tick-Zeit p50 und p99, Zahl der Tick-Überschreitungen, CPU, Arbeitsspeicher, Fehlerrate. Ist die Version bereits überall ausgerollt, vergleichen Sie mit demselben Wochentag und derselben Uhrzeit der Vorwoche. Der Durchschnitt über alle Server verdeckt Probleme einzelner Server oder Zonen, schlüsseln Sie deshalb nach Server und Zone auf. Zuerst hinzuziehen: Entwicklungsteam (Server). (Ursachen: sp-tick-overrun, mem-alloc, mem-leak, sp-broadcast) 4. **Traffic-Profil vorher und nachher vergleichen**: Auch ohne Kenntnis des Servercodes lässt sich anhand der auf Netzwerkseite sichtbaren Werte prüfen, ob der Patch das Traffic-Muster verändert hat. Vergleichen Sie vorher und nachher: Pakete pro Sekunde (pps) und Bytes pro Spieler, durchschnittliche und maximale Paketgröße, Zahl der Verbindungen und die Größe der Sende-Bursts, die pro Tick auf einmal hinausgehen. Überschreiten UDP-Pakete neuerdings die Path-MTU (meist 1.500 Byte), kommt es zur IP-Fragmentierung. Geht nur ein Fragment verloren, ist das ganze Paket verloren, und manche NATs und Firewalls verwerfen Fragmente grundsätzlich. Bei Spielern, deren Route über einen Abschnitt mit kleiner MTU führt (Tunnel, VPN), verschwinden nur die großen Pakete. Ist die pps-Rate gestiegen, prüfen Sie, ob das PPS-Limit der Cloud-Instanz oder die Verarbeitungsgrenze von Firewall oder DDoS-Schutz erreicht ist. Zuerst hinzuziehen: bei verändertem Traffic-Profil das Entwicklungsteam (Server), mit Belegen; bei unverändertem Profil, aber mehr Paketverlust und Retransmissions das Infrastrukturteam (Netzwerk). (Ursachen: sp-patch-traffic, sk-fragment, rt-mtu, nic-cloud-pps, rt-appliance-pps, rt-burst) 5. **Art und Anzahl der DB-Queries vorher und nachher vergleichen**: Ist die DB-Latenz gestiegen, prüfen Sie zuerst, ob auch die Zahl der Queries (QPS) gestiegen ist. In PostgreSQL fasst pg_stat_statements, in MySQL die Digest-Zusammenfassung des Performance Schema Queries, die sich nur in den Werten unterscheiden, zu einem Eintrag zusammen und erfasst Ausführungszahl und Gesamtzeit. Ein Vergleich der Top-Queries vor und nach dem Patch zeigt deshalb neue Queries, Queries mit vervielfachter Ausführungszahl (N+1) und Queries, die ohne Index die ganze Tabelle lesen (in MySQL die Spalte SUM_NO_INDEX_USED). Zuerst hinzuziehen: bei veränderter QPS oder Query-Form das Entwicklungsteam (Server); bei gleichen Queries mit nur gestiegener Latenz das Infrastrukturteam (DB: Ausführungsplan, IOPS, Sperren). (Ursachen: db-no-index, db-login-storm, db-plan-flip, db-cache-stampede) 6. **Schicht anhand von Host- und Serverprozess-Metriken eingrenzen**: Unterscheiden Sie ohne Code, allein anhand der Werte aus dem OS, ob das Problem im Serverprozess oder auf dem Host liegt. Staut sich die Empfangswarteschlange des Server-Sockets (Recv-Q), liest der Serverprozess nicht rechtzeitig (Tick-Stillstand, GC, Locks). Steht ein einzelner Thread auf 100 %, ist das ein Single-Thread-Engpass. Sind die Pausenzeiten im GC-Log gestiegen, hat sich das Muster der Speichernutzung verändert. Prüfen Sie auch, ob mit erhöhtem Log-Level ausgerollt wurde und deshalb mehr Logs geschrieben werden. Sind dagegen CPU-Steal, Throttling oder NIC-Drops gestiegen, prüfen Sie, welche Infrastruktur zur selben Zeit geändert wurde (Instanztyp, Kernel, Container-Limits). Zuerst hinzuziehen: bei Signalen aus dem Prozess das Entwicklungsteam (Server), bei Host-Signalen das Infrastrukturteam (Server/OS). (Ursachen: mem-gc, sp-hotzone, dk-sync-log, so-cpu-quota, so-steal, so-os-update) 7. **Per Rollback bestätigen und dokumentieren**: Nehmen Sie die wahrscheinlichste Änderung nur auf einem Teil der Server oder für einen Teil der Spieler zurück (Rollback, Feature-Flag abschalten) oder setzen Sie die Konfiguration auf den vorherigen Wert zurück, und prüfen Sie, ob das Symptom mit verschwindet. Bessert sich nur die zurückgesetzte Seite, ist die Ursache bestätigt. Auch ein Rollback kann durch Neustart und kalten Cache kurzzeitig bremsen. Wenn es nicht eilt, nehmen Sie ihn daher zu einer ruhigen Tageszeit vor. Halten Sie das Ergebnis zusammen mit der Ursachen-ID im Störungsbericht fest, und nehmen Sie Grenzwerte für Paketgröße, Query-Zahl und Tick-Zeit in die Prüfliste vor dem Deployment des nächsten Patches auf. Zuerst hinzuziehen: das Team, das die Änderung ausgerollt hat. (Ursachen: in-deploy, db-cold-cache) ### Erweiterung um neue Länder und Regionen Wenn der Dienst in einem neuen Land startet oder eine neue Region bzw. ein neues Rechenzentrum hinzukommt. Gedacht für die Prüfung vor dem Start und für die Einordnung von Meldungen wie „Im Inland läuft alles, nur die Spieler im neuen Land haben Lag“. 1. **Routenqualität pro lokalem Provider vor dem Start messen**: Messen Sie für jeden großen Provider (ASN) im Zielland RTT-Verteilung, Jitter und Paketverlust bis zu den möglichen Standorten der Spielserver. Ein einzelner Durchschnittswert verdeckt die Unterschiede zwischen Providern. Betrachten Sie deshalb Median und 95. Perzentil pro Provider, getrennt nach abendlicher Stoßzeit und frühen Morgenstunden. Im öffentlichen Messnetz RIPE Atlas können Sie Probes weltweit nach Land und ASN auswählen und von dort ping und traceroute senden. Sie können auch eine temporäre VM in der Kandidatenregion starten und von dort messen. Weil Geräte unterwegs ICMP-Antworten begrenzen können, messen Sie nach Möglichkeit auch mit demselben Protokoll und Port wie das Spiel. Führt nur die Route eines bestimmten Providers über auffällig weit entfernte Städte, liegt ein Peering- oder Routing-Problem vor. Provider wählen Routen mit geringeren Kosten, auch wenn die Latenz dabei höher ist, deshalb nehmen selbst nahe Ziele mitunter weite Umwege. Zuerst hinzuziehen: Infrastrukturteam (Netzwerk); liegt das Routing-Problem beim Provider, Externe (Provider, IX). (Ursachen: isp-distance, isp-routing, isp-peak, isp-cable) 2. **Messwerte mit den Toleranzgrenzen des Spieldesigns vergleichen**: Vergleichen Sie die gemessenen RTT- und Jitter-Werte mit den Zeitfenstern des Spiels (Reaktionszeiten etwa für Ausweichen und Parieren), dem Limit der Lag-Compensation, der Länge des Interpolationspuffers und der Größe des Eingabepuffers. Beträgt das Parier-Zeitfenster zum Beispiel 0,2 s, kommen Spieler eines Providers, bei dem die Umlaufzeit zusammen mit dem Interpolationspuffer darüber liegt, selbst bei rechtzeitiger Reaktion zu spät. Weitet man die Lag-Compensation aus, um das auszugleichen, häufen sich auf der getroffenen Seite Meldungen wie „hinter der Wand getroffen“. Überschreiten viele Provider diese Grenzen, prüft das Infrastrukturteam, Regionen und Edge-PoPs näher an die Spieler zu bringen, und das Entwicklungsteam überprüft die Werte für Zeitfenster, Interpolation und Lag-Compensation. Als Referenztabelle dient das Kapitel „Gleicher Ping, anderes Spielgefühl: Synchronisationsmodelle“ dieses Whitepapers. Zuerst hinzuziehen: Entwicklungsteam (Server und Client: Designgrenzen), Infrastrukturteam (Netzwerk: Standorte von Regionen und PoPs). (Ursachen: sy-short-window, sy-no-lagcomp, sy-lagcomp-overreach, cg-no-buffer) 3. **MTU und UDP-Durchlässigkeit prüfen**: Prüfen Sie, ob das größte Paket des Spiels im lokalen Netz unversehrt durchkommt. Senden Sie Pings mit gesetztem Don't-Fragment-Bit (DF) in verschiedenen Größen, um die Path-MTU zu messen, und prüfen Sie, ob es Abschnitte mit weniger als 1.500 Byte gibt, etwa PPPoE, Tunnel oder Mobilfunknetze. Der Standard für Datagramm-Übertragung wie UDP (RFC 8899) empfiehlt für IPv4 eine Basisgröße von 1.200 Byte, die durch die meisten Pfade passt. Ist das größte Paket des Spiels größer, legen Sie mit dem Entwicklungsteam fest, ob es verkleinert oder aufgeteilt wird. Prüfen Sie außerdem, ob UDP oder die Spielports in öffentlichen WLANs, Firmennetzen oder bei einzelnen Providern gesperrt oder gedrosselt sind und ob es für diesen Fall einen Ausweichweg gibt (TCP, Port 443). Zuerst hinzuziehen: Infrastrukturteam (Netzwerk) und Entwicklungsteam (Server: Paketgröße). (Ursachen: dc-mtu, rt-mtu, sk-fragment, isp-udp-block, hn-captive, isp-shaping) 4. **Idle-Timeouts von NAT und CGNAT messen und Heartbeat-Intervall anpassen**: Messen Sie, nach welcher Zeit lokale Heimrouter und Mobilfunknetze (CGNAT) das Mapping einer inaktiven UDP-Verbindung löschen. Für jeden Testlauf sendet ein Testgerät ein Paket an den Server und erzeugt so das Mapping. Danach sendet das Gerät nichts mehr, und der Server schickt nach einer festgelegten Zeit (30 s, 60 s, 120 s …) ein Paket an das Gerät. Die Zeit, ab der das Gerät dieses Paket nicht mehr empfängt, ist das Idle-Timeout dieses Netzes. Der Standard (RFC 4787) verlangt, dass UDP-Mappings nicht vor 2 Minuten ablaufen, und empfiehlt als Standardwert mindestens 5 Minuten. Die Werte unterscheiden sich aber stark von Gerät zu Gerät, und manche Geräte löschen früher. Zuverlässig erneuert wird ein Mapping nur durch Pakete, die vom Gerät ausgehen. Den Heartbeat sendet deshalb der Client. Prüfen Sie, ob sein Intervall höchstens halb so lang ist wie der kürzeste Wert unter dem Messwert und den Idle-Timeouts von Load-Balancer und Security Groups der Cloud. Zuerst hinzuziehen: Entwicklungsteam (Client: Heartbeat-Intervall; Server: Timeout-Werte), Infrastrukturteam (Einstellungen von Load-Balancer und Security Groups). (Ursachen: hn-nat, isp-cgnat, rt-mapping, dc-lb-idle, dc-cloud-conntrack) 5. **Externe Dienste und Sicherheitsgeräte für das Zielland prüfen**: Prüfen Sie, ob lokale Plattform-Logins, Zahlungen und Identitätsprüfungen zügig antworten, ob lokale DNS-Server die Adressen von Login- und Patch-Servern korrekt auflösen und ob das CDN Patches von einem Standort nahe dem Land ausliefert. Prüfen Sie, ob die IP-Bereiche des neuen Landes in Länder-Sperrregeln oder Rate-Limits von DDoS-Schutz und Firewall hängen bleiben. Achten Sie besonders darauf, dass CGNAT-Bereiche, in denen sich viele Anschlüsse eine IP teilen, nicht als Ganzes gesperrt werden. Zuerst hinzuziehen: Infrastrukturteam (Sicherheitsgeräte, DNS, CDN), Externe (Plattform, Zahlungsdienstleister, Provider). (Ursachen: in-external, isp-dns, dc-ddos, isp-cgnat) 6. **Nach dem Start nach Land und ASN aufschlüsseln**: Ordnen Sie den Client-IPs in Verbindungs- und Load-Balancer-Logs Land und ASN zu, und werten Sie pro Land und Provider RTT, Retransmissions sowie Zahl und Gründe der Verbindungsabbrüche aus (Heartbeat-Timeout, RST, Kick durch den Server). Kostenlose Datenbanken wie MaxMind GeoLite ASN übersetzen IPs in ASN und Organisationsnamen. Speichern Sie IPs gemäß den lokalen Datenschutzvorgaben nur gekürzt auf /24 oder auf ASN-Ebene. Häufen sich die Probleme in einem einzigen ASN, prüfen Sie zuerst die Route dieses Providers (Infrastrukturteam, Extern). Ist das ganze neue Land betroffen, prüfen Sie zuerst Entfernung und Designgrenzen (Infrastrukturteam, Entwicklungsteam). Wird es nur abends schlechter, steht zuerst überlastetes Peering unter Verdacht. Haben nur einige Spieler dauerhaft hohen Ping, prüfen Sie gemeinsam mit dem Entwicklungsteam (Server), ob sie durch GeoIP-Fehler, VPN oder eine Zuweisung nach dem Gruppenleiter einer fernen Region zugewiesen wurden. Ist das synthetische Monitoring unauffällig und nur die Spieler haben Probleme, liegt es an der Umgebung der Spieler oder am Client. (Ursachen: isp-peak, isp-routing, rt-queue-drop, pt-isp-validation, in-region-match) 7. **Auswirkungen weit entfernter Spieler auf andere Spieler prüfen**: Spielen mehr Spieler aus großer Entfernung, wirkt sich das auch auf die anderen Spieler aus. Die Eingaben eines laggenden Spielers kommen gebündelt an. Auf den Bildschirmen der anderen bewegt sich genau dieser Charakter im Zeitraffer, und die Geschwindigkeits- und Cooldown-Prüfungen des Servers schlagen an, was zu Rubberbanding oder abgelehnten Skills führt. Bei Gruppenmechaniken wird die verspätete Reaktion eines einzigen langsamen Spielers zum Fehlschlag der ganzen Gruppe, und im Lockstep warten alle auf den langsamsten Spieler. Prüfen Sie, ob nach dem Start im neuen Land Meldungen bestehender Spieler wie „Nur ein bestimmter Charakter wirkt seltsam“ zugenommen haben, und legen Sie mit dem Entwicklungsteam Eingabepuffer, Toleranzen der Validierung und getrennte Matchmaking-Regionen fest. Zuerst hinzuziehen: Entwicklungsteam (Server). (Ursachen: pt-slow-burst, pt-isp-validation, pt-raid-member, sy-lockstep) ## Reale Störungsfälle ### eve-hedgp-2014 · CCP Games 2014: EVE Online: Serverüberlast in der großen Flottenschlacht um HED-GP - Was geschah: Ein Rückblick vom Januar 2014 behandelt die große Flottenschlacht im Sonnensystem HED-GP, in der der Server massiv überlastet war. Time Dilation (eine Funktion, die bei Überlast die Spielzeit verlangsamt) erreichte ihre Untergrenze von 10 %, und das ganze Schlachtfeld lief in Zeitlupe. Trotzdem stieg die Last weiter. Der Rückstand bei der Verarbeitung, die das Stoppen und wiederholte Auslösen von Modulen abwickelt (Dogma Lateness), erreichte bis zu 193 s Spielzeit, in Echtzeit etwa 32 Minuten. In der fast gleich großen Schlacht um 6VDT im Juli 2013 waren es höchstens 42 s (in Echtzeit etwa 7 Minuten). - Ursache: CCP schickte voraus, dass die Ursache nicht sicher feststeht: Profiling-Tools erzeugen selbst zusätzliche Last und laufen in solchen Situationen deshalb nicht. Als wahrscheinliche Ursachen nannte CCP zwei Punkte. Erstens staute sich im Lauf der langen Schlacht immer mehr unverarbeitete Last an. Zweitens kamen mehr Drohnen zum Einsatz: Die Zahl der während der Schlacht eingesetzten Drohnen (ohne Mehrfachzählung) lag in 6VDT bei 21.123 und in HED-GP bei 38.852, also 84 % höher. Muss eine Aktion an alle gemeldet werden, die sie sehen, wächst der Sendeaufwand mit dem Quadrat der Spielerzahl (O(n²)), und Drohnen erzeugen pro Angriff mehr Nachrichten. Außerdem durchsucht der Code, mit dem Drohnen ihr Ziel wählen, oft alle angreifbaren Ziele auf demselben Schlachtfeld, sodass die Kosten nahezu mit n² wachsen. - Lehren daraus: Übersteigt die Last in einem Gebiet mit vielen Spielern die Verarbeitungskapazität, läuft das ganze Gebiet in Zeitlupe. Je länger der Kampf dauert, desto mehr unerledigte Arbeit staut sich, und der Input-Lag wächst. Zu prüfen sind Tick-Zeit und Rückstand des Servers (Node), der dieses Gebiet betreibt, sowie die Zahl der Spieler und Objekte. Typisch ist, dass andere Gebiete normal laufen. Hauptzuständig ist das Entwicklungsteam (Server). Anzusetzen ist beim Kreis der Empfänger, an die eine Aktion gemeldet wird, und bei den Kosten der Zielsuche der KI. Eine verlangsamte Spielzeit beseitigt die Überlast nicht. Sie sorgt aber dafür, dass alle gleichmäßig langsamer werden, und verhindert so, dass sich einzelne Aktionen endlos verzögern. - Zugehörige Ursachen: sp-broadcast, sp-tick-overrun, sp-queue, sp-hotzone - Originalquelle: [CCP Games](https://www.eveonline.com/news/view/what-a-hed-ache) ### riot-direct-2015 · Riot Games 2015: League of Legends: Datenverkehr auf Umwegen und Riot Direct - Was geschah: Ein technischer Artikel von Riot Games darüber, warum das Internet nicht für Echtzeitspiele gemacht ist. Realer Traffic, den ein League-of-Legends-Spieler gemeldet hatte, hätte direkt von San Francisco nach Portland laufen sollen, ging aber über Los Angeles, Denver und Seattle. Auf direktem Weg hätte das 14 ms gedauert, tatsächlich waren es 70 ms. Riot erklärte: Laufen Router über und verwerfen Pakete, springen andere Champions über den Bildschirm, und Projektile scheinen zu teleportieren. - Ursache: Riot nannte Routen und Router als Ursache. Backbone-Betreiber und Provider leiten Traffic über die kostengünstigste Route, auch wenn es eine mit geringerer Latenz gibt. Führt die per BGP bestimmte Route über Umwege, steigt auch die Zahl der Router unterwegs. Für einen Router zählt der Verarbeitungsaufwand pro Paket, unabhängig von dessen Größe. Spielpakete sind um die 55 Byte groß. Bei gleicher Datenmenge sind es damit 27-mal so viele Pakete wie bei 1.500-Byte-Paketen, und sie füllen die Eingangspuffer der Router entsprechend schneller. Laut Riot verwerfen viele Router bei Überlast zuerst UDP-Pakete. Als Lösung baute Riot das eigene Netz Riot Direct auf: Router an 10 großen Internetknoten in den USA, direkt verbunden (Peering) mit möglichst vielen Providern. Laut Teil 2 stieg der Anteil der Spieler mit einem Ping unter 80 ms in gut 9 Monaten von 31 % auf 50 %. Nach dem Umzug der Spielserver nach Chicago waren es über Nacht 80 %. - Lehren daraus: Haben selbst innerhalb eines Landes nur die Kunden eines bestimmten Providers auffällig hohen Ping, ist die Route verdächtig. Zu prüfen sind die RTT-Verteilung pro Provider (ASN) und die Städte, die traceroute auf dem Weg anzeigt. Hauptzuständig ist das Infrastrukturteam (Netzwerk). Abhilfe schaffen direktes Peering mit dem Provider, eine IX-Anbindung und die Wahl des Serverstandorts. Die Routing-Policy auf Providerseite muss mit dem externen Provider abgestimmt werden. Der Fall zeigt außerdem, dass schon ein Serverstandort nahe am Schwerpunkt der Spielerverteilung viel bringt. - Zugehörige Ursachen: isp-routing, isp-distance, rt-queue-drop - Originalquelle: [Riot Games](https://www.riotgames.com/en/news/fixing-internet-real-time-applications-part-i) ### riot-edge-2020 · Riot Games 2020: League of Legends: Überlastete Edge-Hosts auf den Servern in Europa und Brasilien - Was geschah: Ende Februar 2020 kam es auf den League-of-Legends-Servern EUW, EUNE und BR mehrfach zu Störungen, und die Zahl neu gestarteter Partien brach stark ein. Alle Backend-Dienste wie Matchmaking und Spielserver meldeten einen gesunden Zustand, bekamen aber kaum eingehenden Traffic. Riot verschob den Turniermodus (Clash) um eine Woche, um ihn nicht auf möglicherweise instabilen Clustern zu starten. Wie lange die einzelnen Störungen dauerten, steht nicht im Rückblick. - Ursache: Drei Dinge kamen zusammen. Erstens waren Anfragen an einen Dienst fehlerhaft aufgebaut. In bestimmten Fällen schlugen sie dauerhaft fehl und wurden ständig wiederholt, sodass die Zahl der Anfragen explodierte. Zweitens verlor das Betriebssystem intern Speicher (Speicherleck), ausgelöst durch eine bekannte Unverträglichkeit zwischen Containersystem und OS-Version. Das Upgrade war erst auf etwa 60 % von Riots gesamter Container-Umgebung abgeschlossen, auf den Clustern in Europa und Lateinamerika lief es noch. Drittens wurden die Edge-Container, die den Internet-Traffic annehmen, filtern und ans Backend weiterleiten, innerhalb eines Shards (einer Servergruppe) auf getrennte Hosts verteilt. Zwischen verschiedenen Shards gab es diese Trennung nicht, und bei jeder Störung lagen die Edge-Container von mindestens drei Shards auf einem einzigen Host. Auf diesen Host trafen die explodierenden Retries, und das Speicherleck brachte ihn zum Stillstand. - Lehren daraus: Melden alle Backend-Dienste „gesund, aber es kommt kein Traffic an“, lohnt der Blick auf die vorgelagerten Komponenten (Edge, Gateway, Load-Balancer). Zu prüfen sind eine ungleiche Verteilung der eingehenden Verbindungen pro Host und der Anteil fehlgeschlagener und wiederholter Anfragen eines bestimmten Typs. Hauptzuständig ist das Entwicklungsteam (Server: fehlerhafte Anfragen und Retry-Verhalten). Platzierungsregeln für Container, OS-Upgrades und Alarme bei Schieflast übernimmt das Infrastrukturteam (Server/OS). Riot korrigierte den Anfragecode, verhinderte sprunghaft steigende Retries und richtete Alarme bei Schieflast ein, bis die Verteilung über Shards hinweg umgesetzt war. - Zugehörige Ursachen: in-gateway, in-cascade - Originalquelle: [Riot Games](https://www.leagueoflegends.com/en-gb/news/riot-games/incident-report-recent-outages-in-europe-brazil/) ### riot-euw-2021 · Riot Games 2021: League of Legends EUW, 5-stündiger Ausfall: Eine einzige Neben-DB legt den ganzen Server lahm - Was geschah: Am 22. Januar 2021 funktionierte der League-of-Legends-Server EUW gut 5 Stunden lang nicht richtig. Die Metriken für eingeloggte Spieler und für Spieler in einer Partie rissen gleichzeitig ab. Zwischen zwei Neustarts stiegen zwar die Logins, es starteten aber kaum Partien. - Ursache: Der Primärserver einer DB für eine unwichtige Funktion hatte einen Hardwaredefekt, und für diese DB war kein automatisches Failover auf einen Standby-Server eingerichtet. Jede DB hatte zwar einen eigenen Connection-Pool, alle Pools nutzten aber denselben Thread-Pool. Aufträge an die defekte DB wurden nicht fertig und hielten ihre Threads fest, bis dem gesamten System die Threads ausgingen. In der Flut von Alarmen verdächtigte das Team zuerst einen kurz zuvor erlebten böswilligen Netzwerkangriff und Hardwarearbeiten in einer anderen Region. Der Alarm der defekten DB fiel deshalb erst nach etwa 1 Stunde auf. Alle Systeme liefen in einer einzigen JVM. Als die GC unter der Reconnect-Last nach dem Neustart den Prozess jeweils mehrere Sekunden anhielt, entstanden auch große Lücken in der Metrikerfassung. Zudem hielt die Login-Warteschlange ihr konfiguriertes Limit nicht ein, sodass die Spieler sehr ungleichmäßig nachströmten. - Lehren daraus: Auch eine einzelne Neben-DB, die als unwichtig gilt, kann über gemeinsam genutzte Ressourcen wie einen Thread-Pool das ganze System lahmlegen. Zu prüfen sind die Zahl wartender Anfragen pro DB, die Auslastung des Thread-Pools und ein im Verhältnis zu den Logins auffällig geringer Anteil gestarteter Partien. Zuständig sind das Entwicklungsteam (Server: Isolation der Thread-Pools, Timeouts) und das Infrastrukturteam (DB: automatisches Failover). Bei einer Flut von Alarmen liegt der Verdacht auf kürzlich erlebte Probleme (etwa Angriffe) nahe. Deshalb schließt man Ursachen in der Diagnosereihenfolge (Betroffenenkreis → Zeitpunkt → Schicht) eine nach der anderen aus. Nach einem Neustart ist zusätzlich zu prüfen, ob die Login-Warteschlange den Zustrom wie konfiguriert begrenzt. - Zugehörige Ursachen: sp-threadpool, db-failover, in-cascade, mem-gc - Originalquelle: [Riot Games](https://www.riotgames.com/en/news/keeping-legacy-software-alive-case-study) ### roblox-2021 · Roblox 2021: Roblox, 73-stündiger Ausfall: Contention im Service-Discovery-Cluster (Consul) - Was geschah: Die Störung begann am Nachmittag des 28. Oktober 2021 (pazifische Zeit) mit hoher CPU-Last auf einem einzelnen Consul-Server. Um 16:35 Uhr fiel die Zahl der verbundenen Spieler auf die Hälfte des Normalwerts, danach stand der gesamte Dienst still. Erst am 31. Oktober um 16:45 Uhr konnten sich wieder alle Spieler verbinden, 73 Stunden nach Beginn der Störung. Laut Roblox nutzen täglich 50 Millionen Menschen die Plattform. - Ursache: Roblox nutzt HashiCorp Consul für Service Discovery (Dienste finden darüber gegenseitig ihre Adressen), für Health-Checks und als KV-Store. Ein einziger Consul-Cluster trug dabei mehrere Workloads gleichzeitig. Es gab zwei Grundursachen. Erstens wurde die neue Streaming-Funktion von Consul, die über Monate schrittweise ausgerollt worden war, am Tag vor der Störung auch für den Traffic-Routing-Dienst aktiviert, und die Knotenzahl dieses Dienstes wurde um 50 % erhöht. Unter sehr hoher Lese- und Schreiblast verursachte diese Funktion Contention auf einer einzelnen gemeinsamen Ressource (einem Go-Channel). Auf den Dual-Socket-Servern (NUMA) mit mehr Kernen, die während der Störung eingebaut wurden, war die Contention noch stärker. Zweitens wurde in BoltDB, das Consul zum Speichern des Raft-Logs nutzt, die Verwaltung der Liste freier Seiten (Freelist) pathologisch langsam: Bei jedem Anhängen von höchstens 16 kB wurden 7,8 MB auf den Datenträger geschrieben. Der Median der KV-Schreiblatenz stieg von normalerweise unter 300 ms auf 2 s, und auf einem langsamen Leader-Server wurde auch ein Zero Window bei vollem TCP-Puffer beobachtet. Weil die Telemetrie von Consul abhing, fielen auch die Metriken weg, die für die Ursachensuche nötig gewesen wären. - Lehren daraus: Wird ein Basissystem langsam, auf das sich viele Dienste stützen (Service Discovery, Konfigurationsspeicher, Authentifizierung), stehen alle Funktionen gleichzeitig still. Zu prüfen sind Schreiblatenz, Leader-Wechsel und CPU dieses Systems sowie Konfigurationsänderungen kurz vor der Störung. Zuständig sind beide Seiten: das Entwicklungsteam (Server) und das Infrastrukturteam (Server/OS). Das Monitoring muss vom überwachten System unabhängig sein, damit die Metriken auch während einer Störung sichtbar bleiben. Beim Wiederanlauf sind die Caches leer, und wenn alle auf einmal hereinkommen, kann das System erneut zusammenbrechen. Roblox steuerte deshalb per DNS den Anteil der Spieler, die eingelassen wurden, und erhöhte ihn in Schritten von etwa 10 %. - Zugehörige Ursachen: in-cascade, sp-lock, rt-zero-window, db-cold-cache - Originalquelle: [Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021) ### ffxiv-2021 · Square Enix 2021: FINAL FANTASY XIV: Überlastung zum Start der Erweiterung und Fehler in der Login-Warteschlange - Was geschah: Ab dem Early Access der Erweiterung Endwalker im Dezember 2021 waren alle Welten extrem überfüllt. Die Login-Warteschlangen wurden lang, und beim Einloggen aus dem Charakterauswahlbildschirm oder während des Wartens in der Warteschlange trat häufig Error 2002 auf. Hinzu kamen Ausfälle einzelner Welten und Zonen (Error 3001) und Timeouts in der Warteschlange (Error 4004). Auch zum Zeitpunkt der Mitteilung vom 11. Dezember, am 8. Tag des Early Access, hielt der Andrang an. - Ursache: Error 2002 tritt in zwei Fällen auf. Im ersten Fall warten pro logischem Rechenzentrum mehr als 17.000 Spieler. Diese Obergrenze soll verhindern, dass die Warteschlange zu lang wird und der Login-Server ausfällt. Der Client wird dabei vollständig beendet. Am 7. Dezember wurden Reservegeräte aus der Entwicklung als Lobby-Server eingesetzt und die Obergrenze angehoben. Danach trat dieser Fehler seltener auf, die Warteschlange wurde aber sogar länger. Im zweiten Fall ist die Leitung eines wartenden Spielers instabil. Mit den längeren Wartezeiten nahmen kurze Verbindungsunterbrechungen durch Paketverlust auf der Internetroute oder instabiles WLAN zu. Der Lobby-Server wartet einige Dutzend Sekunden bis etwa 1 Minute auf einen Reconnect. Gelingt er in dieser Zeit, geht es an der bisherigen Position in der Warteschlange weiter. Dauert es länger, muss man sich ganz hinten anstellen. Laut Square Enix betraf der Großteil der Meldungen diesen Fall. Wegen des Halbleitermangels ließen sich auch nicht sofort weitere Welten hinzufügen. - Lehren daraus: Je länger die Warteschlange, desto häufiger wird aus einer kurzen Leitungsunterbrechung eines wartenden Spielers ein Verbindungsfehler. Bei gleicher Überlastung treffen die Fehler dann gehäuft Spieler mit WLAN oder instabiler Leitung, und es entsteht ein Problem, das „nur einige betrifft“. Zu prüfen sind Länge der Warteschlange und Wartezeit sowie unter den Abbruchgründen der Anteil der Verbindungsabbrüche während des Wartens. Hauptzuständig ist das Entwicklungsteam (Server: Obergrenze der Warteschlange und Reconnect-Karenzzeit). Am Ausbau von Lobby- und Weltservern ist das Infrastrukturteam beteiligt. Eine großzügige Reconnect-Karenzzeit verringert das Risiko, dass eine kurze Unterbrechung der Spielerleitung den Platz in der Warteschlange kostet. - Zugehörige Ursachen: in-login-queue, hn-wifi, rt-wireless - Originalquelle: [Square Enix](https://na.finalfantasyxiv.com/lodestone/news/detail/6a94b30182b6d963994fdc0b789264ac9f24986f) ### cloudflare-2020 · Cloudflare 2020: Cloudflare: Traffic-Verlust in einigen Städten durch Konfigurationsfehler im Backbone - Was geschah: Viele Spiele überlassen Web, APIs und DDoS-Schutz einem CDN-Anbieter. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Am 17. Juli 2020 sank der gesamte Traffic im Cloudflare-Netz von 21:12 bis 21:39 Uhr (UTC), also 27 Minuten lang, um etwa 50 %. Betroffen waren nur einige Standorte in Städten in den USA, Europa, Russland und Brasilien, die an den Backbone angebunden sind. Die übrigen Standorte arbeiteten normal. - Ursache: Eine Störung auf dem Backbone-Abschnitt Newark–Chicago überlastete den Abschnitt Atlanta–Washington. Um Backbone-Traffic von Atlanta abzuziehen, änderte ein Techniker die Router-Konfiguration. Deaktiviert werden sollte der gesamte Policy-Eintrag (term), deaktiviert wurde aber nur die Bedingung darin (prefix-list). Dadurch verteilte der Router in Atlanta alle BGP-Routen mit höherer Priorität (local-preference 200) über den gesamten Backbone. Die Routen der Standorte zu ihren eigenen Servern hatten die Priorität 100, also floss der gesamte Traffic der an den Backbone angebundenen Standorte nach Atlanta. Atlanta war überlastet, und die betroffenen Standorte hatten kaum noch Traffic zu verarbeiten. Nachdem der Router in Atlanta aus dem Backbone genommen wurde, normalisierte sich die Lage. Laut Cloudflare gab es keinen Zusammenhang mit einem Angriff oder einer Kompromittierung. - Lehren daraus: Treten Verbindungsabbrüche oder Kein Login / Endlos-Laden gleichzeitig nur bei Spielern in einer bestimmten Stadt oder Region auf, während alle anderen normal spielen, steht zuerst eine kurz zuvor geänderte Routing-Konfiguration unter Verdacht. Im Graphen schießen CPU und Traffic an einem einzigen Standort hoch, während sie an den betroffenen Standorten auf nahezu 0 fallen. Hauptzuständig ist das Infrastrukturteam (Netzwerk). Bei einer Störung auf Anbieterseite liegt die Zuständigkeit extern. Cloudflare beschloss, für die BGP-Sessions im Backbone eine Obergrenze für die Zahl annehmbarer Routen (maximum-prefix) einzuführen, und passte die Prioritäten so an, dass ein Standort den Traffic anderer Standorte nicht mehr an sich ziehen kann. - Zugehörige Ursachen: isp-bgp, rt-path - Originalquelle: [Cloudflare](https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/) ### fastly-2021 · Fastly 2021: Fastly: Weltweite Fehler im CDN - Was geschah: Viele Spiele liefern Patch-Dateien, Launcher und Webseiten über ein CDN aus. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Ab 09:47 Uhr (UTC) am 8. Juni 2021 lieferten 85 % des Fastly-Netzes Fehler zurück. Innerhalb von 49 Minuten arbeiteten 95 % des Netzes wieder normal, um 12:35 Uhr war die Störung behoben. - Ursache: Ein am 12. Mai begonnenes Software-Deployment enthielt einen Bug, der ausgelöst wird, wenn eine bestimmte Kundenkonfiguration auf bestimmte Bedingungen trifft. Am 8. Juni spielte ein Kunde eine gültige Konfigurationsänderung ein, und genau diese Bedingungen trafen zu. Fastly erkannte die Störung innerhalb von 1 Minute. Nachdem die auslösende Kundenkonfiguration gefunden und deaktiviert war, begann die Wiederherstellung. Das Deployment des Bugfixes begann am selben Tag um 17:25 Uhr. - Lehren daraus: Auch Code, der seit Wochen ausgerollt ist, kann bei einer seltenen Bedingung schlagartig eine weltweite Störung auslösen. Auf Spielseite erkennt man das daran, dass die HTTP-Fehlerrate bei Patch-, Launcher- und Web-Anfragen in allen Regionen gleichzeitig steigt, und an der Statusseite des CDN-Anbieters. Typisch ist, dass bestehende Spielverbindungen normal weiterlaufen, sofern sie nicht über das CDN gehen, und nur neue Verbindungen, Patch-Downloads und Web-Logins scheitern. Hauptzuständig ist der externe CDN-Anbieter. Entwicklungsteam und Infrastrukturteam halten einen Ausweichweg bereit: mehr als ein CDN oder einen direkten Abruf vom Ursprungsserver. - Zugehörige Ursachen: in-external - Originalquelle: [Fastly](https://www.fastly.com/blog/summary-of-june-8-outage) ### meta-2021 · Meta 2021: Facebook: Ein einziger Backbone-Befehl lässt sogar das DNS verschwinden - Was geschah: Eine Infrastrukturstörung, die sich eins zu eins auf eigene Netze und das DNS von Spielefirmen übertragen lässt. Am 4. Oktober 2021 waren die Dienste von Facebook (heute Meta) weltweit nicht erreichbar. Alle Backbone-Verbindungen zwischen den Rechenzentren waren getrennt, und aus dem Internet ließen sich die DNS-Server von Facebook nicht mehr finden. Wie lange die Störung dauerte, steht nicht im Rückblick. - Ursache: Bei einer routinemäßigen Wartung sollte ein Befehl die weltweite Backbone-Kapazität prüfen. Ungewollt trennte er alle Verbindungen des Backbones, und das Audit-Tool, das solche Befehle hätte stoppen sollen, ließ ihn wegen eines Bugs durch. Die DNS-Server an kleineren Standorten sind so ausgelegt, dass sie sich selbst als fehlerhaft einstufen und ihre BGP-Ankündigungen zurückziehen, wenn sie die Rechenzentren nicht erreichen. Dadurch waren sie aus dem Internet unerreichbar, obwohl sie liefen. Sowohl die normalen Zugangswege als auch der Out-of-Band-Zugang waren abgeschnitten, und die internen Tools hatten ebenfalls kein DNS mehr. Techniker mussten deshalb vor Ort in die Rechenzentren, und die Sicherheitsverfahren kosteten zusätzlich Zeit. Beim Wiederanlauf lag der Stromverbrauch jedes Rechenzentrums um einige Dutzend MW niedriger. Ein Hochfahren auf einen Schlag hätte von der Stromversorgung bis zu den Caches alles gefährden können, deshalb wurde die Last schrittweise erhöht. - Lehren daraus: Tritt Kein Login / Endlos-Laden in allen Regionen und bei allen Providern gleichzeitig auf, sind zuerst DNS und BGP-Routen zu prüfen, danach erst die Spielserver. Das geht auch von außerhalb des Unternehmens: mit externen DNS-Abfragen und öffentlich verfügbaren BGP-Routeninformationen. Hauptzuständig ist das Infrastrukturteam (Netzwerk). Vorab ist sicherzustellen, dass der Out-of-Band-Zugang für den Störungsfall und die internen Tools nicht vom selben DNS und Netz abhängen. Beim Wiederanlauf wird die Last schrittweise erhöht, damit nicht alle Reconnects auf einmal eintreffen. - Zugehörige Ursachen: isp-bgp, isp-dns - Originalquelle: [Meta](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/) ### aws-2021 · AWS 2021: AWS us-east-1: Überlast im internen Netzwerk - Was geschah: Viele Spiele betreiben Server, Login und Daten in der Public Cloud. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Am 7. Dezember 2021 um 7:30 Uhr (PST) geriet das interne Netzwerk der Region Nord-Virginia (us-east-1) in Überlast. Ab 7:33 Uhr nahmen Fehler und Latenz der EC2-API zu, und neue Instanzen ließen sich kaum starten (Instanzstarts funktionierten ab 14:40 Uhr wieder). Hinzu kamen fehlgeschlagene Konsolen-Logins, nicht durchführbare Änderungen an der Route-53-Konfiguration sowie verzögerte und teilweise verlorene CloudWatch-Metriken. Die Netzwerkgeräte hatten sich um 14:22 Uhr vollständig erholt. Bereits laufende EC2-Instanzen und bestehende DNS-Antworten waren nicht betroffen. - Ursache: Ein automatischer Vorgang, der die Kapazität eines Dienstes im Hauptnetz erhöhen sollte, löste bei sehr vielen Clients im internen Netz unerwartetes Verhalten aus, und die Verbindungsversuche schnellten in die Höhe. Die Geräte zwischen internem Netz und Hauptnetz liefen über, und die Kommunikation verzögerte sich. Die Verzögerung trieb wiederum Verbindungsversuche und Retries in die Höhe, sodass die Überlast anhielt. Die Clients hatten zwar ein Backoff-Verhalten, das bei solcher Überlast die Abstände zwischen Anfragen vergrößert. Wegen eines latenten Fehlers funktionierte es aber nicht richtig. Auch das interne Monitoring hing vom selben Netz ab, sodass das Betriebsteam ohne Echtzeitmetriken anhand von Logs reagieren musste. - Lehren daraus: Können Retries ihre Abstände nicht vergrößern, wird aus kurzer Überlast eine stundenlange Störung. Für ein Spiel heißt das: Bereits laufende Spielserver arbeiten normal weiter, aber neue Server (Autoscaling), Login, Matchmaking und Zahlungen über Cloud-APIs sowie das Monitoring können gleichzeitig blockiert sein. Zu prüfen sind die Statusseite des Cloud-Anbieters, die Fehlerrate der Cloud-APIs und fehlgeschlagene Instanzstarts. Hauptzuständig ist der externe Cloud-Anbieter. Das Entwicklungsteam versieht alle Retries mit exponentiellem Backoff in zufälligen Abständen und begrenzt die Zahl der Versuche. Das Infrastrukturteam hält Reservekapazität bereit, die auch ohne neue Server trägt, sowie eine Ausweichmöglichkeit in einer anderen Region. - Zugehörige Ursachen: in-cascade, in-autoscale, in-external - Originalquelle: [AWS](https://aws.amazon.com/message/12721/) ### cloudflare-dns-2025 · Cloudflare 2025: Cloudflare: Ausfall des öffentlichen DNS 1.1.1.1 - Was geschah: Eine Störung eines öffentlichen DNS-Resolvers, den Spieler selbst auf ihrem Gerät oder Router eintragen. Bei diesem Typ sind nur für Spieler mit dieser Einstellung alle Spiele und Dienste gleichzeitig blockiert. Am 14. Juli 2025 antwortete der Resolver 1.1.1.1 von 21:52 bis 22:54 Uhr (UTC), also 62 Minuten lang, weltweit nicht. Laut Cloudflare bedeutete das für viele Nutzer, dass praktisch kein Internetdienst mehr nutzbar war. Betroffen waren Abfragen über UDP, TCP und DNS over TLS. DNS over HTTPS, das über einen Domainnamen angesprochen wird, blieb vergleichsweise stabil. - Ursache: Am 6. Juni wurde die Service-Topologie (die Konfiguration, die festlegt, an welchen Standorten ein IP-Bereich angekündigt wird) für einen anderen, künftigen Dienst vorbereitet. Dabei wurden versehentlich auch die IP-Bereiche des Resolvers 1.1.1.1 in diese Konfiguration aufgenommen. Als diese Dienstkonfiguration am 14. Juli geändert wurde, wurden die Resolver-Bereiche nur noch an einem einzigen Standort angekündigt, und dieser war offline. Zuvor waren es alle Standorte gewesen. Die BGP-Routen wurden weltweit zurückgezogen. Die Änderung ging ohne Canary-Deployment sofort an alle Rechenzentren. Nach dem Zurücksetzen der Konfiguration um 22:20 Uhr kehrte der Traffic auf etwa 77 % zurück. Inzwischen waren aber auf etwa 23 % der Edge-Server benötigte IP-Einstellungen gelöscht worden. Sie mussten neu eingerichtet werden, deshalb war erst um 22:54 Uhr wieder alles normal. Laut Cloudflare war die Ursache ein interner Konfigurationsfehler ohne Zusammenhang mit einem Angriff oder BGP-Hijacking. - Lehren daraus: Laufen Spielserver und alle anderen Spieler normal, tritt aber bei einigen Spielern an Login- oder Patch-Servern Kein Login / Endlos-Laden auf, ist das DNS dieser Spieler verdächtig. Typisch ist, dass bestehende Sessions erhalten bleiben und nur neue Verbindungen scheitern. Lässt man die Spieler die DNS-Einstellung ändern oder die Serveradresse direkt abfragen, ist die Sache sofort geklärt. Hauptzuständig sind Externe (DNS-Betreiber, Provider). Zeigt der Client einen Fehler bei der Namensauflösung getrennt von anderen Fehlern an (Aufgabe des Entwicklungsteams, Client), kann der Kundensupport den Fall sofort einordnen. - Zugehörige Ursachen: isp-dns, isp-bgp - Originalquelle: [Cloudflare](https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/) ### aws-2025 · AWS 2025: AWS us-east-1: DNS-Störung bei DynamoDB und langwierige Wiederherstellung - Was geschah: Viele Spiele betreiben Server, Login und Daten in der Public Cloud. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Vom 19. Oktober 2025 um 23:48 Uhr bis zum 20. Oktober um 14:20 Uhr (PDT) zogen sich die Auswirkungen in der Region Nord-Virginia über drei Phasen hin. Bis 2:40 Uhr am 20. Oktober häuften sich Fehler der DynamoDB-API. Von 2:25 bis 10:36 Uhr schlugen Starts neuer EC2-Instanzen fehl (Verbindungsprobleme einiger neuer Instanzen waren um 13:50 Uhr behoben). Von 5:30 bis 14:09 Uhr nahmen Verbindungsfehler bei einigen Network Load Balancern (NLB) zu. - Ursache: Die Automatisierung, die das DNS von DynamoDB verwaltet, enthielt eine latente Race Condition. Mehrere Ausführungsprozesse (DNS Enactor) wenden in verschiedenen Availability Zones DNS-Pläne an. Einer davon war ungewöhnlich stark verzögert und überschrieb einen neuen Plan mit einem veralteten. Unmittelbar danach löschte der Aufräumvorgang eines anderen Enactors genau diesen veralteten Plan, und der DNS-Eintrag des regionalen Endpunkts (dynamodb.us-east-1.amazonaws.com) war leer. Die Automatisierung konnte das nicht beheben, die Wiederherstellung musste von Hand erfolgen. Das System, das die physischen Server von EC2 verwaltet, hängt von DynamoDB ab. In der Zwischenzeit liefen deshalb die Leases ab, die für jeden physischen Server gehalten werden. Nachdem DynamoDB wieder lief, gab es so viele physische Server, dass das erneute Abschließen der Leases in Timeouts lief, bevor es fertig war. Retries stauten sich erneut, und das System geriet in einen „Congestive Collapse“ (Zusammenbruch durch Überlast). Weil die Netzwerkkonfiguration neu gestarteter Instanzen verzögert verteilt wurde, schwankten die Health-Checks der NLB zwischen Erfolg und Fehlschlag. Selbst gesunde Knoten wurden immer wieder aus dem DNS genommen und wieder aufgenommen. - Lehren daraus: Ein fehlerhafter DNS-Eintrag an einer Stelle greift auf andere Dienste über, die von diesem Dienst abhängen. Auch nach Behebung der Ursache dauert die Wiederherstellung wegen aufgestauter Arbeit und schwankender Health-Checks noch Stunden. Für ein Spiel heißt das: Bereits laufende Server halten durch, aber neue Server lassen sich nicht starten, und das Autoscaling steht. Schwanken die Health-Checks, nimmt der Load-Balancer womöglich gesunde Server aus dem Betrieb. Zu prüfen sind die Statusseite der Cloud, die Fehlerrate der APIs verwalteter Dienste, fehlgeschlagene Instanzstarts und die Zahl gesunder Ziele am Load-Balancer. Hauptzuständig ist der externe Cloud-Anbieter. Das Infrastrukturteam begrenzt, wie viele Server wegen fehlgeschlagener Health-Checks gleichzeitig herausfallen können, und hält eine Ausweichmöglichkeit in einer anderen Region bereit. - Zugehörige Ursachen: in-external, in-cascade, in-autoscale, dc-lb-imbalance, isp-dns - Originalquelle: [AWS](https://aws.amazon.com/message/101925/) ## Glossar - **Ping** (Ping, RTT): Zeit, die ein Signal zum Server und wieder zurück braucht (Round Trip). Der im Spiel angezeigte Ping enthält teils auch Wartezeit bei der Serververarbeitung. - **Latenz** (Latency): Zeit, die ein Paket vom Absenden bis zur Ankunft braucht. Oft ist nur eine Richtung gemeint, dann ist es etwa der halbe Ping. - **Jitter** (Jitter): Schwankung der Ankunftsabstände. Selbst bei gleichem durchschnittlichem Ping ruckelt das Bild, wenn der Jitter hoch ist. - **Paket** (Packet): Datenbündel, das in einem Stück über das Netz geschickt wird. Meist höchstens 1.500 Byte groß, Spiel-Updates umfassen einige Dutzend bis einige hundert Byte. - **Paketverlust** (Packet loss): Ein gesendetes Paket kommt nicht an und geht verloren. Bei Spielen mit TCP macht sich schon 1 % alle paar Sekunden bis etwa alle zehn Sekunden als kurzes Stocken bemerkbar. UDP-Spiele mit Interpolation und mehrfach gesendeten Eingaben kaschieren teils sogar einige Prozent. - **Bandbreite** (Bandwidth): Maximale Datenmenge, die eine Leitung pro Sekunde übertragen kann (Mbps). Das ist etwas anderes als die Frage, wie schnell Daten ankommen (Latenz). - **Tick** (Tick): Einheit, in der der Server den Spielzustand einmal berechnet. Ein Server mit 20 Ticks rechnet 20-mal pro Sekunde, also alle 50 ms. - **Tickrate** (Tick rate): Wie oft pro Sekunde ein Tick läuft. Je höher, desto schneller die Reaktion, aber Serverkosten und Datenmenge steigen. Um Datenmenge zu sparen, werden Pakete oft seltener verschickt, als die Tickrate vorgibt. - **Tick-Budget** (Tick budget): Zeitlimit, in dem ein Tick fertig sein muss. Wird es überschritten, verspätet sich der nächste Tick, und das Tick-Intervall wird länger. - **FPS** (Frames per second): Wie oft pro Sekunde das Bild gezeichnet wird. Bei 60 FPS bleiben 16,7 ms pro Frame. - **Frametime** (Frame time): Zeit, die das Zeichnen eines Frames gedauert hat. Für das Spielgefühl zählen gelegentliche Ausreißer mehr als die durchschnittlichen FPS. - **Snapshot** (Snapshot): Zusammenfassung des aktuellen Spielzustands, die der Server in jedem Tick schickt: Position, Lebenspunkte, Status usw. Meist werden nur die Teile gesendet, die sich gegenüber dem Stand beim Empfänger geändert haben (Delta-Kompression). - **Interpolation** (Interpolation): Technik, die zwischen zwei empfangenen Snapshots Zwischenbilder berechnet, damit Bewegungen flüssig wirken. Der Preis: Man sieht einen leicht vergangenen Zustand. - **Interpolationspuffer** (Interpolation buffer): Zeit, um die für die Interpolation absichtlich verzögert gezeichnet wird. Diese Reserve fängt Jitter und den Verlust von ein, zwei Paketen ab. Üblich ist der 2-fache Paketabstand (bei 20 Paketen pro Sekunde 100 ms), und manche Spiele vergrößern ihn automatisch, wenn der Jitter steigt. - **Extrapolation** (Extrapolation, Dead reckoning): Technik, die ohne neue Pakete aus der letzten Geschwindigkeit schätzt, wo ein Objekt gleich sein wird, und es dort zeichnet. Liegt die Schätzung daneben, wirkt es wie Teleportieren. Viele Spiele extrapolieren deshalb nur etwa 0,25 s weit und hören dann auf (Standardwert der Source Engine: 0,25 s). - **Clientseitige Vorhersage** (Client-side prediction): Technik, die den eigenen Charakter sofort bewegt, ohne auf die Bestätigung des Servers zu warten. - **Serverabgleich** (Reconciliation): Kommt das Ergebnis vom Server, wird es mit der Vorhersage verglichen und die Position des eigenen Charakters korrigiert. Dazu werden ausgehend von der vom Server bestätigten Position die noch unbestätigten eigenen Eingaben erneut angewendet. Ist die Abweichung groß, sieht das wie Rubberbanding aus. - **Lag-Compensation** (Lag compensation): Technik, bei der der Server für die Trefferabfrage auf den Zeitpunkt zurückspult, den der Angreifer gesehen hat, und prüft, ob der Treffer saß. Damit sich die getroffene Seite nicht betrogen fühlt, ist das Zurückspulen nach oben begrenzt. In kompetitiven Shootern sind etwa 0,2–0,25 s üblich, manche Spiele spulen wie der Standardwert der Source Engine bis zu 1 s zurück. - **Autoritativer Server** (Authoritative server): Design, bei dem nur der Server endgültig entscheidet. Das verhindert Cheating, aber jedes Ergebnis braucht einen Round Trip zum Server. Vorhersage und clientseitiges Feedback überbrücken deshalb die Wartezeit. - **Lockstep** (Deterministic lockstep): Verfahren, bei dem alle nur Eingaben austauschen und im selben Zug identisch rechnen. Eingaben erhalten eine feste Verzögerung, und kommt die Eingabe eines einzigen Spielers zu spät, warten alle. - **Serverseitiger Eingabepuffer** (Server-side input buffer): Puffer, in dem der Server die Eingaben jedes Spielers kurz sammelt und pro Tick eine davon verarbeitet. So wirken auch Spieler mit hohem Jitter für andere flüssig, doch ihre Aktionen werden auf dem Server entsprechend später wirksam. - **Listen-Server** (Listen server): Modell, bei dem der PC eines Spielers mitspielt und zugleich als Server dient. Der Host hat einen Ping von 0, aber ist seine Leitung oder sein PC langsam, laggt es für alle. - **Phasing** (Phasing): Funktion, die am selben Ort je nach Questfortschritt andere NPCs und anderes Gelände zeigt. Haben zwei Charaktere unterschiedlichen Fortschritt, ist es normal, dass bei einem ein NPC fehlt. - **Rollback-Netcode** (Rollback netcode (GGPO)): Verfahren, das die Eingaben des Gegners vorhersagt und schon weiterrechnet. Weicht die tatsächliche Eingabe ab, wird auf einen früheren Frame zurückgespult und neu berechnet. Verbreitet in Fighting Games. Hat mit dem Rollback in Datenbanken nichts zu tun. - **Input-Buffering** (Input buffer, spell queue): Die nächste Eingabe wird schon kurz vor dem Ende von Cooldown oder Animation angenommen und im Moment des Endes ausgeführt. So schiebt sich zwischen zwei Aktionen einer Kombo keine Round-Trip-Zeit. - **Clientseitiges Feedback** (Client-side feedback): Animationen, Sounds und Effekte werden abgespielt, ohne auf die Bestätigung des Servers zu warten. Nur Ergebnisse, die feststehen müssen, etwa Schaden oder Belohnungen, warten auf die Antwort des Servers. Lehnt der Server ab, muss das bereits Gezeigte zurückgenommen werden. - **TCP** (Transmission Control Protocol): Protokoll, das Daten vollständig und in der richtigen Reihenfolge zustellt. Bis ein verlorenes Paket erneut empfangen ist, gibt es nachfolgende Pakete nicht an das Spiel weiter. - **UDP** (User Datagram Protocol): Protokoll, das ohne jede Garantie zustellt, was gesendet wird. Es entsteht keine Wartezeit, dafür muss sich das Spiel selbst um Verluste und Reihenfolge kümmern. - **Zuverlässiges UDP** (Reliable UDP (KCP, ENet…)): Ansatz, der auf UDP selbst nur so viel Retransmission und Reihenfolgegarantie implementiert wie nötig. - **Head-of-Line-Blocking** (Head-of-line blocking): Das vorderste Element hängt, und alle dahinter müssen warten. Das ist die Ursache für den Zeitraffer bei TCP. - **RTO** (Retransmission timeout): Retransmission-Timer: Zeit, die TCP wartet, bevor es ein Paket als verloren wertet und erneut sendet. Unter Linux mindestens Ping + 200 ms, mit jedem Fehlschlag doppelt so lang. - **Nagle-Algorithmus** (Nagle’s algorithm): TCP-Funktion, die kleine Datenmengen sammelt, bis die Bestätigung (ACK) für bereits gesendete Daten eintrifft, und sie dann gebündelt sendet, um Pakete zu sparen. In Spielen sollte sie meist abgeschaltet werden. - **TCP_NODELAY** (TCP_NODELAY): Socket-Option, die den Nagle-Algorithmus abschaltet. Kleine Nachrichten gehen sofort raus. - **Delayed ACK** (Delayed ACK): Funktion, die die Empfangsbestätigung etwas verzögert und mit anderen Daten bündelt. Unter Linux meist 40 ms (maximal 200 ms), unter Windows in älteren Versionen 200 ms und in aktuellen 40 ms. - **Socket-Puffer** (SO_SNDBUF / SO_RCVBUF): Größe des Sende- und Empfangspuffers, den das OS für jeden Socket vorhält. Zu klein, und er läuft über. Zu groß, und alte Daten stauen sich und müssen warten. - **keepalive** (SO_KEEPALIVE): TCP-Funktion, die prüft, ob eine Idle-Verbindung noch lebt. Standardmäßig aus, und selbst eingeschaltet prüft sie mit Standardwerten erst nach 2 Stunden. - **RST** (TCP reset): TCP-Signal, das eine Verbindung sofort gewaltsam beendet. Noch nicht gesendete Daten werden verworfen. - **Heartbeat** (Heartbeat): Lebenszeichen, das das Spiel selbst in regelmäßigen Abständen sendet. Dient dazu, abgebrochene Verbindungen zu erkennen und Verbindungen in Geräten unterwegs offen zu halten. - **Timeout** (Timeout): Schwelle, ab der eine ausbleibende Antwort als Fehler gilt. Zu kurz führt zu Fehlalarmen, zu lang zu später Erkennung. - **NAT** (Network Address Translation): Funktion, mit der der Router mehrere Geräte im Haushalt über eine einzige öffentliche IP ins Internet bringt und jede Verbindung in der NAT-Tabelle vermerkt. - **CGNAT** (Carrier-grade NAT): Großes NAT, bei dem sich mehrere Kunden eines Providers eine IP-Adresse teilen. - **MTU** (Maximum Transmission Unit): Maximale Größe eines Pakets, das in einem Stück gesendet werden kann. Meist 1.500 Byte, auf VPN- und PPPoE-Strecken weniger. - **Bufferbloat** (Bufferbloat): Geräte stauen übermäßig lange Warteschlangen auf, wodurch die Latenz auf mehrere hundert ms steigt. - **SQM** (Smart Queue Management (fq_codel, CAKE)): Router-Funktion, die Warteschlangen kurz hält und die Sendezeit fair auf die einzelnen Datenströme verteilt. Die Lösung gegen Bufferbloat. - **QoS** (Quality of Service): Funktion, die wichtigen Datenverkehr bevorzugt, damit er zuerst gesendet wird. - **Peering** (Peering): Punkt, an dem Provider ihre Netze miteinander verbinden. Abends leicht überlastet. - **BGP** (Border Gateway Protocol): Protokoll, mit dem sich Provider im Internet mitteilen, über welche Route Daten laufen sollen. Ändert sich die Route, ändert sich auch der Ping. - **DDoS** (Distributed Denial of Service): Angriff, bei dem aus vielen Quellen massenhaft Datenverkehr geschickt wird, um einen Dienst lahmzulegen. - **Scrubbing-Center** (DDoS scrubbing center): Standort eines DDoS-Schutzanbieters, der bei einem Angriff den Traffic zum Server zuerst annimmt, den Angriff herausfiltert und nur den legitimen Traffic weiterleitet. Liegt der Standort weit entfernt, wird die Route länger. - **Firewall** (Firewall): Gerät oder Programm, das nur erlaubte Verbindungen durchlässt. Verbindungen werden in einer Session-Tabelle verfolgt. - **Load-Balancer** (Load balancer): Gerät, das eingehende Verbindungen auf mehrere Server verteilt. - **Session-Tabelle** (Session table, conntrack): Tabelle, in der ein Gerät oder das OS die aktuellen Verbindungen verfolgt. Ihre Größe ist begrenzt. - **Microburst** (Microburst): Der Durchschnitt ist niedrig, doch für sehr kurze Momente von höchstens 1 ms ballt sich der Datenverkehr. - **NIC** (Network Interface Card): Netzwerkkarte des Servers. - **Ringpuffer** (Ring buffer): Puffer, in dem die NIC empfangene Pakete ablegt, bis die CPU sie abholt. Eine feste Anzahl von Slots wird reihum genutzt. Sind alle Slots belegt, werden neue Pakete verworfen. - **Interrupt** (Interrupt): Signal, mit dem ein Gerät der CPU meldet: „Es gibt Arbeit.“ - **RSS** (Receive Side Scaling): NIC-Funktion, die empfangene Pakete auf mehrere Empfangs-Queues verteilt, damit mehrere CPU-Kerne sie verarbeiten. - **PPS** (Packets per second): Pakete pro Sekunde. Spielserver stoßen oft eher an diese Grenze als an die der Bandbreite. - **Kernel** (Kernel): Kern des Betriebssystems. Zuständig für Netzwerk, Speicher und die Verteilung der CPU-Zeit. - **backlog** (Listen backlog): Warteschlange für neue Verbindungsanfragen, die der Server noch nicht angenommen hat. Ist sie voll, verwirft Linux neue Anfragen stillschweigend, Windows schickt eine Ablehnung. - **TIME_WAIT** (TIME_WAIT): Zustand, in dem die Seite, die eine Verbindung zuerst schließt, die Portkombination eine Weile (unter Linux 60 s) vorhält, falls noch verspätete Pakete eintreffen. - **CPU-Steal** (Steal time): Zeit, die eine virtuelle Maschine auf die CPU warten musste, weil der physische Server die CPU gerade einer anderen VM gab. Sichtbar als st-Wert in top. - **CPU-Throttling** (CFS throttling): Ein Container, der sein CPU-Kontingent (Quota) innerhalb einer festen Periode (CFS period, meist 100 ms) aufgebraucht hat, wird bis zur nächsten Periode zwangsweise angehalten. - **Dateideskriptor** (File descriptor): Nummer (fd), die jede von einem Prozess geöffnete Datei oder Verbindung erhält. Ihre Anzahl ist begrenzt. - **Thread** (Thread): Eigenständig ausgeführte Arbeitseinheit innerhalb eines Programms. Mehrere Threads können gleichzeitig laufen. - **Kontextwechsel** (Context switch): Die CPU wechselt vom laufenden Thread zu einem anderen. Das kostet Zeit. - **Lock** (Lock, Mutex): Sperre, die dafür sorgt, dass gemeinsam genutzte Daten nur von jeweils einem Thread verwendet werden. - **Deadlock** (Deadlock): Zustand, in dem Threads gegenseitig auf Locks warten, die der jeweils andere hält, und für immer stehen bleiben. - **Thread-Pool** (Thread pool): Vorab erzeugte Gruppe von Worker-Threads. Sind alle beschäftigt, müssen neue Aufgaben warten. - **Asynchrone I/O** (epoll, IOCP, io_uring): Verfahren, bei dem ein Programm während laufender Ein- und Ausgabe andere Arbeit erledigt und benachrichtigt wird, sobald sie abgeschlossen ist. - **AOI** (Area of Interest): Bereich, den ein Spieler „sehen“ kann. Nur Änderungen in diesem Bereich werden gesendet, um Datenmenge zu sparen. Damit die Prüfung, wer sich im Bereich befindet, günstig bleibt, wird die Map meist in ein Raster (Grid) unterteilt, und nur die nahen Zellen werden betrachtet. - **Broadcast** (Broadcast, fan-out): Eine Änderung wird an alle geschickt, die sie sehen können. Sehen sich alle Versammelten gegenseitig, wächst die zu sendende Menge mit dem Quadrat der Spielerzahl. - **GC** (Garbage collection): Funktion, die nicht mehr benutzten Speicher automatisch freigibt. Während der GC kann das Programm stehen bleiben. - **Heap** (Heap): Speicherbereich, den ein Programm zur Laufzeit bei Bedarf zugeteilt bekommt. - **Speicherleck** (Memory leak): Fehler, bei dem nicht mehr benötigter Speicher nicht zurückgegeben wird und der Verbrauch ständig wächst. Kommt auch mit GC vor, wenn irgendwo noch eine Referenz auf ein nicht mehr benötigtes Objekt besteht. - **Swap** (Swap, paging): Reicht der RAM nicht, wird ein Teil des Speichers auf den Datenträger ausgelagert. Wird dieser Speicher wieder gebraucht, ist der Zugriff über 1.000-mal langsamer als im RAM. - **OOM-Killer** (Out-of-memory killer): Linux-Funktion, die bei erschöpftem Speicher den Prozess mit dem höchsten Speicherverbrauch auswählt und zwangsweise beendet. Bei Containern greift sie schon, wenn das Speicherlimit erreicht ist. - **Cache-Miss** (Cache miss): Die Daten liegen nicht im CPU-nahen Cache, also muss auf den langsameren Arbeitsspeicher zugegriffen werden. - **IOPS** (I/O operations per second): Anzahl der Lese- und Schreibvorgänge, die ein Datenträger pro Sekunde bewältigt. Bei Cloud-Datenträgern richtet sich das Limit danach, wie viel man bezahlt. - **fsync** (fsync): Befehl, der wartet, bis Daten sicher auf den Datenträger geschrieben sind. Normale Schreibvorgänge landen zuerst im Speicher des OS und werden erst später auf den Datenträger geschrieben. Fällt in der Zwischenzeit der Strom des Servers aus, können sie verloren gehen. fsync ist sicher, aber langsam. - **Burst-Credits** (Burst credits): Guthaben, das Cloud-Datenträger und -Server ansparen, um kurzzeitig über ihrer Basisleistung zu arbeiten. Ist es aufgebraucht, fallen sie auf die Basisleistung zurück. - **Index** (Index): Suchverzeichnis einer DB. Ohne Index muss die ganze Tabelle gelesen werden. - **Full Table Scan** (Full table scan): Abfrage, die ohne Index alle Zeilen einer Tabelle prüft. - **Ausführungsplan** (Query plan): Festlegung, in welcher Reihenfolge und mit welchen Indizes die DB eine Query abarbeitet. Selbst bei unverändertem Code kann dieselbe Query plötzlich langsam werden, wenn die DB den Plan ändert. - **Transaktion** (Transaction): DB-Operationen, die nach dem Prinzip „alles oder nichts“ zusammengefasst sind. Handel muss immer in einer Transaktion laufen. Bis zum Ende bleiben geänderte Zeilen gesperrt, daher gilt: je kürzer, desto besser. - **Connection-Pool** (Connection pool): Vorab aufgebaute Gruppe von DB-Verbindungen. Sind alle belegt, müssen neue Anfragen warten. - **Hot Row** (Hot row): Einzelne Zeile, die viele Anfragen gleichzeitig ändern wollen. Ursache von Lock-Contention. - **Replikationsverzögerung** (Replication lag): Zeit, um die ein DB-Replikat hinter der Primär-DB zurückliegt. - **Rollback** (Rollback): Ein Speichervorgang wird abgebrochen, und der vorherige Zustand kehrt zurück. Spieler erleben das als „Das Item ist weg“. - **Cache** (Cache (Redis etc.)): Kopie häufig genutzter Daten an einem schnellen Ort. Entlastet die DB. - **Checkpoint** (Checkpoint): Die DB schreibt die im Speicher gesammelten Änderungen regelmäßig gebündelt auf den Datenträger. In diesem Moment können Speichern und Abfragen kurz langsamer werden. - **Failover** (Failover): Fällt der primäre Server oder die DB aus, wird auf die Reserve umgeschaltet. Während der Umschaltung ist kurz kein Speichern möglich, und war die Replikation im Rückstand, können die letzten Daten verloren gehen. - **MVCC** (Multi-version concurrency control): Verfahren, bei dem die DB alte Versionen eine Zeit lang aufbewahrt, damit Lesende und Schreibende sich nicht gegenseitig blockieren. Bleiben Transaktionen lange offen, häufen sich alte Versionen an, und alles wird langsamer. - **Cache-Stampede** (Cache stampede): Der Cache leert sich auf einen Schlag, und die Anfragen stürzen sich auf die Quelle (DB). - **Gateway** (Gateway): Zwischenserver, der Client-Verbindungen annimmt und an die dahinterliegenden Spielserver weiterleitet. - **Circuit-Breaker** (Circuit breaker): Mechanismus, der Aufrufe an einen dauerhaft fehlschlagenden Dienst vorübergehend kappt und sofort als Fehler behandelt, um kaskadierende Ausfälle zu verhindern. Nach einer Weile folgen ein, zwei Testaufrufe, und ist der Dienst wieder da, werden Aufrufe wieder zugelassen. - **Kaskadierender Ausfall** (Cascading failure): Ein Ausfall an einer Stelle breitet sich entlang der Aufrufkette auf andere Dienste aus. - **Autoscaling** (Autoscaling): Funktion, die die Zahl der Server je nach Last automatisch erhöht oder verringert. Das Hochskalieren braucht Zeit. - **Watchdog** (Watchdog): Timer, der überwacht, ob der Server hängt. Steht die Game-Loop länger als eine festgelegte Zeit (einige bis einige Dutzend Sekunden), schreibt er einen Zustandsabzug (Dump) und beendet den Server zwangsweise, damit er neu startet. - **Auslastung** (Utilization): Anteil der Zeit, in der ein Worker (eine Instanz, die Anfragen abarbeitet, etwa ein CPU-Kern, ein Thread oder eine DB-Verbindung) beschäftigt ist. Ab 80–90 % steigen die Wartezeiten sprunghaft. - **p99** (99th percentile): Wert, unter dem 99 von 100 Messungen liegen, während etwa 1 von 100 langsamer ist. Zeigt spürbaren Lag besser als der Durchschnitt. - **V-Sync** (Vertical sync): Funktion, die Frames im Takt der Bildwiederholung ausgibt. Beseitigt Tearing, erzeugt aber Input-Lag, und fallen die FPS unter die Bildwiederholrate, springen sie zwischen 60 und 30 hin und her, und es ruckelt. - **Variable Bildwiederholrate** (VRR, G-Sync, FreeSync): Funktion, bei der der Monitor das Bild genau dann wechselt, wenn ein Frame fertig ist. Verringert das Ruckeln und den Input-Lag, die bei V-Sync durch das Springen zwischen 60 und 30 entstehen. - **Anti-Cheat** (Anti-cheat): Sicherheitsmodul gegen Cheats. Schlagen regelmäßige Prüfungen oder Heartbeats zum Server fehl, kann es Ruckeln oder Verbindungsabbrüche verursachen. - **Overlay** (Overlay): Funktion, mit der Messenger-, Aufnahme- oder FPS-Anzeigeprogramme über das Spielbild zeichnen. Sie greifen in den Zeichenablauf des Spiels ein und können Ruckeln verursachen. - **Shader-Kompilierung** (Shader compilation): Übersetzung von Grafikeffekt-Programmen für die GPU. Ohne Vorkompilierung stockt das Bild beim ersten Anblick eines Effekts, und nach einem Update des Grafiktreibers werden die gespeicherten Ergebnisse ungültig und alles wird neu kompiliert. - **Main-Thread** (Main thread, Game thread): Zentraler Thread eines Spiels, der Spiellogik und Bildvorbereitung nacheinander abarbeitet. Dauert hier eine einzige Aufgabe lange, steht so lange das Bild. - **Timer-Auflösung** (Timer resolution): Kürzester Abstand, in dem das Betriebssystem ein schlafendes Programm wecken kann. Unter Windows sind es standardmäßig 15,6 ms. Ohne Anpassung durch das Programm wacht es daher auch bei „in 1 ms wecken“ verspätet auf. - **Thermal Throttling** (Thermal throttling): Schutzfunktion, mit der ein heiß gewordenes Gerät CPU und GPU selbst herunterregelt. Auf Smartphones passiert das oft schon nach einigen bis einigen Dutzend Minuten Spielzeit. - **VRAM** (Video memory): Eigener Speicher der Grafikkarte. Texturen und Modelle werden dort abgelegt und gezeichnet. Reicht er nicht, werden Daten über einen langsamen Weg mit dem Arbeitsspeicher des PCs ausgetauscht, und es ruckelt. - **Netgraph** (Net graph): Entwickler- und Debug-Anzeige, die Ping, Paketverlust, FPS und Ticks als Echtzeitgraph ins Spielbild legt. Ist sie in einem Lag-Video zu sehen, lässt sich die Ursache viel leichter finden. - **Retransmission-Rate** (Retransmission rate): Anteil erneut gesendeter an allen gesendeten TCP-Paketen. Einen offiziellen Grenzwert gibt es nicht, aber ein serverweiter Durchschnitt unter 0,1 % gilt als gesund, und über 1 % ist Lag für viele Spieler oft spürbar. Wichtig ist auch, um welchen Faktor der Wert gegenüber dem Normalzustand gestiegen ist. - **SACK** (Selective ACK): TCP-Funktion, mit der der Empfänger genau meldet: „Diesen Bereich habe ich, nur dieser Teil fehlt.“ So lassen sich auch mehrere Verluste in einem Durchgang reparieren. - **RACK-TLP** (Recent ACK, Tail Loss Probe): TCP-Funktion, die Verluste anhand der Zeit erkennt und, wenn eine Weile kein ACK kommt, das letzte Paket noch einmal sendet, um die Wiederherstellung zu beschleunigen. Standard in aktuellen Linux- und Android-Versionen. Unter Windows sind TLP und RACK ab Windows 10 (1607) und Server 2016 Standard, das neue RACK, das auch verlorene Retransmissions repariert, erst ab Server 2022. Funktioniert nur auf Verbindungen mit aktiviertem SACK. - **Unnötige Retransmission** (Spurious retransmission): Ein Paket war gar nicht verloren, kam aber zu spät oder in anderer Reihenfolge an, galt als verloren und wurde erneut gesendet. Verschwendet Leitungskapazität und drosselt die Senderate unnötig. - **Zero Window** (Zero window): Zustand, in dem der Empfangspuffer voll ist und der Empfänger „kurz nichts mehr senden“ meldet. Sieht aus wie Retransmission, doch die Leitung ist in Ordnung: Das empfangende Programm hat nicht rechtzeitig gelesen. - **thin stream** (Thin stream): Verbindung, die wie in Spielen nur vereinzelt kleine Pakete sendet. Signale für eine schnelle Retransmission kommen kaum zusammen, daher stockt sie bei Verlusten lange. - **Policer** (Policer): Ratenbegrenzung, die Pakete oberhalb der festgelegten Rate ohne Warteschlange sofort verwirft. Das Verfahren, das sie einreiht und langsam weitergibt, heißt Shaper. - **Pacing** (Pacing): Zu sendende Pakete werden gleichmäßig über die Zeit verteilt, sodass kein Schwall auf einmal entsteht. Verhindert, dass kleine Puffer überlaufen. - **ECN** (Explicit Congestion Notification): Funktion, die bei Überlast Pakete mit dem Vermerk „überlastet“ markiert, ohne sie zu verwerfen, damit der Sender das Tempo drosselt. Meldet Überlast ohne Paketverlust. Wirkt nur, wenn beide Enden und die Geräte im überlasteten Abschnitt sie unterstützen. - **MSS** (Maximum Segment Size): Maximale Datenmenge, die TCP in ein Paket packt. Meist 1.460 Byte. Wird sie an Tunnelstrecken angepasst, lässt sich ein MTU-Blackhole vermeiden. - **Handover** (Handover): Ein Smartphone in Bewegung wechselt die Funkzelle, mit der es verbunden ist. - **Perzentil** (Percentile (p50, p95, p99)): Wert an einer bestimmten Prozentposition, wenn man alle Werte aufsteigend sortiert. p50 ist der Median, p99 liegt etwa beim langsamsten von 100 Werten. Zeigt Ausreißer, die der Durchschnitt verschleiert. - **Tail-Latency** (Tail latency): Lange Verzögerungen, die gelegentlich auftreten, während fast alles schnell ist. Im Durchschnitt kaum sichtbar, aber genau das bleibt Spielern als Lag in Erinnerung. - **Synthetisches Monitoring** (Synthetic monitoring): Anstelle echter Spieler senden Messgeräte oder Messserver von festen Standorten aus regelmäßig ping, traceroute usw., um die Qualität einer Route zu messen. RIPE Atlas ist das bekannteste öffentliche Werkzeug. - **Aggregationsintervall** (Aggregation interval): Wie viele Sekunden oder Minuten ein einzelner Punkt im Graphen zusammenfasst. Je länger das Intervall, desto stärker verschwimmen kurze Spitzen im Durchschnitt. - **Postmortem** (Postmortem): Bericht nach einer Störung: was passiert ist, warum und was geändert wird. Ziel ist, Wiederholungen zu verhindern. Schuldzuweisungen gehören nicht dazu. - **C-state** (CPU idle state): Energiesparzustand, in den die CPU im Leerlauf wechselt. Je tiefer der Zustand, desto mehr Strom wird gespart, aber desto länger dauert das Aufwachen. - **Live-Migration** (Live migration): Die Cloud verschiebt eine laufende virtuelle Maschine auf einen anderen Host, etwa für Wartungsarbeiten am Host. Im Moment der Verschiebung kann sie kurz stehen bleiben. - **SNAT** (Source NAT): NAT, das die Absenderadresse ausgehender Pakete durch eine öffentliche Adresse ersetzt. Die Zahl der Ports pro öffentlicher Adresse ist begrenzt, und sind alle belegt, schlagen neue Verbindungen fehl. - **NAT-Gateway** (NAT gateway): Cloud-Komponente, über die Server in einem privaten Netz beim Zugriff aufs Internet eine gemeinsame öffentliche Adresse nutzen. Die Zahl gleichzeitiger Verbindungen pro Ziel ist begrenzt. - **LEO-Satelliteninternet** (LEO satellite internet): Internetzugang über Satelliten in einigen hundert bis einigen tausend km Höhe. Die Latenz ist viel kürzer als bei geostationären Satelliten, kann aber beim Wechsel des verbundenen Satelliten springen. - **GeoIP** (IP geolocation): Datenbank, die anhand der IP-Adresse Land, Stadt und Provider schätzt. Falsche oder veraltete Einträge können dazu führen, dass Spieler einem weit entfernten Server zugewiesen werden. - **TLS-Zertifikat** (TLS certificate): Elektronisches Dokument, mit dem ein Server beweist, dass er wirklich der Server ist, der er vorgibt zu sein. Es hat eine Gültigkeitsdauer, und läuft es ab, scheitert die verschlüsselte Verbindung, und niemand kann sich mehr verbinden. - **Frame Generation** (Frame generation): Technik, bei der die Grafikkarte zwischen tatsächlich gerenderte Frames vorhergesagte Frames einfügt, um die FPS zu erhöhen. Das Bild wird flüssiger, aber die Verzögerung zwischen Eingabe und Bild kann steigen.