Input-Lag: 76 Ursachen und Zuständigkeiten

Auch genannt: Verzögerte Reaktion, träge, schwammige Steuerung

Im interaktiven Symptomkatalog mit Grafiken öffnen →

Zwischen Tastendruck und Ergebnis vergeht spürbar Zeit. Das Bild selbst kann dabei flüssig sein.

Ein Skill löst 0,2–0,5 s nach dem Tastendruck aus. Aktionen mit Bestätigung wie Aufheben, Dialoge oder Handel sind träge.

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).

Ursachen dieses Symptoms

L1 Spielprozess auf dem Client

Renderlast durch große Spielermengen: Sind wie bei Belagerungen oder Weltbossen Hunderte Spieler auf einem Bildschirm, ist schon das Zeichnen selbst nicht mehr zu bewältigen. (Client-Entwicklung (Entwicklungsteam))
Engpass bei der Paketverarbeitung im 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. (Client-Entwicklung (Entwicklungsteam))
V-Sync und Render-Warteschlange: 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. (Client-Entwicklung (Entwicklungsteam))

L2 Client-OS und Gerät

Energiesparmodus und 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. (Extern (Extern))
Bandbreitenbelegung durch andere Apps auf demselben Gerät: Laufen Cloud-Synchronisation, große Downloads oder Spiel-Patches auf demselben PC, warten die Spielpakete in der Warteschlange. (Extern (Extern))
Latenz von Display, Eingabegeräten und Frame Generation: 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. (Extern (Extern))

L3 Heimnetz

Überlasteter WLAN-Kanal: Wo wie in großen Wohnanlagen Dutzende Router funken, teilen sie sich denselben Kanal und müssen auf Sendegelegenheiten warten. (Extern (Extern))
Bufferbloat (Warteschlange im Router): 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. (Extern (Extern))
Verzögerung beim RRC-Zustandswechsel (Energiesparen im Mobilfunk): 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. (Client-Entwicklung (Entwicklungsteam))

L4 Internetleitung

Signallaufzeit (physische Entfernung): 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. (Server-Infrastruktur (Infrastrukturteam))
Satelliteninternet (LEO und geostationär): 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. (Extern (Extern))
Umweg-Routing: Wegen der Verbindungsverträge zwischen Providern laufen Daten selbst zu nahen Servern über weit entfernte Umwege. (Netzwerk-Infrastruktur (Infrastrukturteam))
Störung an Unterseekabel oder Auslandsleitung: 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. (Extern (Extern))
Drosselung und Traffic-Management durch den Provider: Ist das Datenvolumen aufgebraucht oder verwaltet der Tarif bestimmten Datenverkehr gezielt, werden Pakete verzögert oder verworfen. (Extern (Extern))
Umweg über VPN oder Ping-Booster: 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. (Extern (Extern))

L5 Netzwerkgeräte im Rechenzentrum

Umweg über DDoS-Schutz und 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Vollauslastung der Rechenzentrumsanbindung: Nutzen Patch-Verteilung, Log-Übertragung oder Backups dieselbe Leitung wie das Spiel, läuft die Leitung voll. (Netzwerk-Infrastruktur (Infrastrukturteam))

L6 Netzwerkkarte des Servers

NIC-Interrupts auf nur einem Kern: Schickt die NIC die Interrupts für eintreffende Pakete nur an einen CPU-Kern, wird dieser Kern zum Engpass. (Server-Infrastruktur (Infrastrukturteam))
Zu starkes Interrupt-Coalescing: Sammelt die NIC Pakete, um die CPU zu entlasten, und meldet sie gebündelt, verzögern sie sich um die Sammelzeit. (Server-Infrastruktur (Infrastrukturteam))
Vollauslastung der NIC-Bandbreite: Wird eine 1-Gbps- oder 10-Gbps-Karte bis an ihre Grenze ausgelastet, wächst die Sende-Queue, und am Ende werden Pakete verworfen. (Server-Entwicklung (Entwicklungsteam))
Verzögerung durch GRO/LRO-Zusammenfassung: 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. (Server-Infrastruktur (Infrastrukturteam))

L7 Server-OS (Kernel)

Latenzspitzen durch Energieverwaltung des Servers (C-States und Frequenzskalierung): 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. (Server-Infrastruktur (Infrastrukturteam))
Leistungsänderung nach OS-, Kernel-, Treiber- oder 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. (Server-Infrastruktur (Infrastrukturteam))

L8 Sockets und Protokolle

Nagle-Algorithmus + Delayed ACK: 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. (Server-Entwicklung (Entwicklungsteam))
Slow Start nach Leerlauf: 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. (Server-Infrastruktur (Infrastrukturteam))
Einbruch der Senderate durch Congestion Control: TCP wertet Paketverlust als Zeichen von Überlast und senkt die Senderate um 30–50 %. Auf Paketverlust im WLAN reagiert es genauso. (Server-Infrastruktur (Infrastrukturteam))
Blockierende I/O-Architektur: Kann ein Thread nichts anderes tun, während er auf einen Socket wartet, wird mit steigender Spielerzahl alles langsamer. (Server-Entwicklung (Entwicklungsteam))

L9 Spielprozess auf dem Server

Überschrittenes Tick-Budget: 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. (Server-Entwicklung (Entwicklungsteam))
Explodierende Broadcast-Last: 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. (Server-Entwicklung (Entwicklungsteam))
Überlastetes Gebiet auf einem einzelnen Thread (Hotspot): Ist jedes Gebiet einem einzelnen Thread zugeordnet und drängen sich viele Spieler an einem Ort, läuft nur dieser eine Kern auf 100 %. (Server-Entwicklung (Entwicklungsteam))
Lock-Contention: Warten mehrere Threads auf denselben Lock, um auf dieselben Daten zuzugreifen, läuft trotz zusätzlicher Threads immer nur einer zur Zeit. (Server-Entwicklung (Entwicklungsteam))
Rückstau in der Message-Queue: 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. (Server-Entwicklung (Entwicklungsteam))
Kosten für Serialisierung und Kompression: Auch das Umwandeln der Sendedaten in Bytes und ihre Kompression kosten CPU-Zeit. Bei vielen Spielern schießen diese Kosten in die Höhe. (Server-Entwicklung (Entwicklungsteam))
Erschöpfter Thread-Pool: Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit. (Server-Entwicklung (Entwicklungsteam))
Auf ein Ziel konzentrierter Kampf (Weltboss): 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. (Server-Entwicklung (Entwicklungsteam))
Spawn-Flut beim Betreten belebter Gebiete: Reist man per Teleport in eine volle Stadt, muss der Server Aussehen, Ausrüstung und Zustand von Hunderten neu sichtbarer Spieler auf einmal senden. (Server-Entwicklung (Entwicklungsteam))
Anhäufung von Objekten (nicht aufgeräumte Items und Beschwörungen): 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. (Server-Entwicklung (Entwicklungsteam))
Patch verändert das Traffic-Muster: 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. (Server-Entwicklung (Entwicklungsteam))

L11 Datenträger

fsync-Flut: 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. (Server-Entwicklung (Entwicklungsteam))
Aufgebrauchte Burst-Credits beim Cloud-Datenträger: 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. (Server-Infrastruktur (Infrastrukturteam))
IOPS-Limit und volle Warteschlange: Kommen mehr Anfragen, als der Datenträger pro Sekunde bewältigt, wird die Warteschlange lang und die Latenz explodiert. (Server-Infrastruktur (Infrastrukturteam))
Backup-, Komprimierungs- und Scan-Jobs: Belegen nächtliche Backups, Log-Komprimierung oder Sicherheitsscans den Datenträger, stauen sich die Lese- und Schreibzugriffe des Spielservers. (Server-Infrastruktur (Infrastrukturteam))
Seek-Latenz von HDDs: 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. (Server-Infrastruktur (Infrastrukturteam))

L12 Datenbank

Query ohne Index: Ohne Index muss die DB die ganze Tabelle lesen, um die passenden Zeilen zu finden (Full Table Scan). (Server-Entwicklung (Entwicklungsteam))
Hot-Row-Lock-Contention: Wollen alle dieselbe Zeile ändern (Gildenlager, begehrtes Item im Auktionshaus, serverweiter Zähler), bekommt immer nur einer den Lock. (Server-Entwicklung (Entwicklungsteam))
DB-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. (Server-Entwicklung (Entwicklungsteam))
Erschöpfter Connection-Pool: Die Zahl der Verbindungen zur DB ist fest. Belegen langsame Queries die Verbindungen, müssen alle anderen Anfragen warten. (Server-Entwicklung (Entwicklungsteam))
Checkpoint und Log-Flush: 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. (DB-Infrastruktur (Infrastrukturteam))
Kalter Cache (direkt nach Neustart): Nach einem Neustart der DB ist der Cache im Arbeitsspeicher leer, und eine Zeit lang wird jede Abfrage vom Datenträger gelesen. (DB-Infrastruktur (Infrastrukturteam))
Login-Ansturm und N+1-Queries: Fragt das Laden eines einzigen Charakters die DB einige Dutzend Mal einzeln ab, werden aus Zehntausenden gleichzeitigen Logins Millionen von Queries. (Server-Entwicklung (Entwicklungsteam))
Große Batch-Jobs: Laufen Ranglistenberechnung, Massenversand von Ingame-Post oder das Aufräumen alter Daten im laufenden Betrieb, belegen sie Locks und Datenträger. (Server-Entwicklung (Entwicklungsteam))
Cache-Stampede: Laufen die Cache-Einträge beliebter Daten gleichzeitig ab, stürzen sich Tausende Anfragen auf einmal auf die DB. (Server-Entwicklung (Entwicklungsteam))
Lange offene Transaktion: 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. (Server-Entwicklung (Entwicklungsteam))
Langsame Redis-Befehle: Redis arbeitet Befehle einzeln nacheinander ab. Ein einziger langsamer Befehl blockiert deshalb alle nachfolgenden Anfragen. (Server-Entwicklung (Entwicklungsteam))
Langsame Query durch geänderten Ausführungsplan: Ä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. (DB-Infrastruktur (Infrastrukturteam))
Locks durch Schemaänderung (DDL) im laufenden Betrieb: 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. (DB-Infrastruktur (Infrastrukturteam))

L13 Serverarchitektur und Betrieb

Gateway oder Proxy als Zwischenstation: Steht zwischen Client und Spielserver ein Zwischenserver, kommt bei jeder Station Verarbeitungszeit hinzu, und dieser Server wird zum Single Point of Failure. (Server-Entwicklung (Entwicklungsteam))
Kaskadierender Ausfall: Wird ein Dienst langsam, hängen die Server, die ihn aufrufen, beim Warten auf Antworten fest, und selbst unbeteiligte Funktionen bleiben stehen. (Server-Entwicklung (Entwicklungsteam))
Deployment und Neustart: 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. (Server-Entwicklung (Entwicklungsteam))
Zu viele Makros und Bots: Bots senden viel häufiger Anfragen als Menschen und zehren die Verarbeitungskapazität des Servers auf. (Server-Entwicklung (Entwicklungsteam))
Fehlerhaftes Matchmaking oder falsche Regionszuweisung: 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. (Server-Entwicklung (Entwicklungsteam))

Synchronisationsdesign

Feedback erst nach der Serverantwort (Request-Response): Nach einem Tastendruck gibt es weder Animation noch Ton, bis die Antwort des Servers eintrifft. Der Ping bestimmt direkt die Reaktionszeit. (Client-Entwicklung (Entwicklungsteam))
Protokoll mit vielen aufeinanderfolgenden Round Trips (chatty): Braucht eine einzige Aktion mehrere Round Trips zum Server nacheinander, vervielfacht sich der Ping um deren Anzahl. (Server-Entwicklung (Entwicklungsteam))
Kein Input-Buffering für Skills: 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. (Client-Entwicklung (Entwicklungsteam))
Kurze Zeitfenster, die der Ping aufzehrt: Ist die Reaktionszeit für Ausweichen, Parieren oder Blocken kurz, zehrt der Ping sie auf, und manche Angriffe lassen sich gar nicht mehr vermeiden. (Server-Entwicklung (Entwicklungsteam))
Warten auf den langsamsten Spieler im Lockstep: Berechnen alle gemeinsam denselben Zug, müssen alle warten, sobald die Eingabe eines Einzelnen zu spät kommt. (Server-Entwicklung (Entwicklungsteam))
Doppeltes Warten auf den Tick: 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. (Server-Entwicklung (Entwicklungsteam))

Probleme, die nur einige betreffen

Größe des Eingabepuffers pro Spieler: 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. (Server-Entwicklung (Entwicklungsteam))
Ein laggendes Gruppenmitglied und Boss-Mechaniken: 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. (Server-Entwicklung (Entwicklungsteam))
Aufgeblähte Daten eines bestimmten Charakters: 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. (Server-Entwicklung (Entwicklungsteam))
Sendebudget und Priorität pro Verbindung: Begrenzt der Server die Sendemenge pro Verbindung und sendet Nahes zuerst, bekommen Verbindungen mit niedrigem Limit entfernte NPCs spät oder gar nicht. (Server-Entwicklung (Entwicklungsteam))

Grundursachen von TCP-Retransmissions

Verworfene Pakete auf dem empfangenden Server-Host: 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. (Server-Infrastruktur (Infrastrukturteam))
Unnötige Retransmission durch Latenzsprünge: 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. (Extern (Extern))
Unnötiger Fast Retransmit durch vertauschte Reihenfolge: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Verspätete oder verlorene ACKs (ausgelasteter Upload): 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. (Extern (Extern))
RTO-Einstellung passt nicht zur Umgebung: 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. (Server-Infrastruktur (Infrastrukturteam))

Interaktiven Symptomkatalog mit Grafiken ansehen