Für Spieler ist Latenz eine gefühlte Größe: Das Spiel reagiert verzögert, Bewegungen ruckeln, Treffer registrieren nicht. Für Betreiber von Multiplayer-Infrastruktur ist Latenz dagegen eine messbare und beeinflussbare Variable. Wer Tick-Rate, Jitter und Paketverlust versteht, kann gezielt optimieren – und damit die Spielerfahrung auf seinem Server grundlegend verbessern.
Was ist die Tick-Rate?
Die Tick-Rate beschreibt, wie oft pro Sekunde der Game-Server den Spielzustand berechnet und an die Clients sendet. Eine Tick-Rate von 64 bedeutet: 64 Mal pro Sekunde wird der Zustand der Spielwelt berechnet – Positionen, Schüsse, Interaktionen. Bei 128 Ticks geschieht das doppelt so häufig.
Für casual Multiplayer-Spiele ist eine moderate Tick-Rate vollkommen ausreichend. Bei kompetitiven Shootern oder Echtzeit-Strategiespielen können Unterschiede von wenigen Millisekunden spielentscheidend sein – hier zahlt sich eine höhere Tick-Rate aus.
Tick-Rate und Hardware-Last
Eine höhere Tick-Rate bedeutet mehr CPU-Last, mehr Netzwerkbandbreite pro Spieler und mehr Verarbeitungsaufwand insgesamt. Server-Betreiber müssen deshalb einen sorgfältigen Kompromiss finden: Zu niedrig und das Spielgefühl leidet, zu hoch und der Server wird zum Bottleneck – oder die Betriebskosten steigen stark.
Als Orientierung: Viele kompetitive Spiele nutzen zwischen 60 und 128 Ticks pro Sekunde. Darüber hinaus nehmen die meisten Spieler keinen Unterschied mehr wahr – der Ertrag sinkt, die Kosten steigen weiter.
Latenz verstehen: RTT, Ping und One-Way-Delay
Die Round-Trip-Time (RTT) – landläufig als "Ping" bekannt – misst die Zeit, die ein Paket vom Client zum Server und zurück benötigt. Das ist die Kennzahl, die Spieler am häufigsten sehen. Für die tatsächliche Spielerfahrung ist der One-Way-Delay (OWD) oft relevanter: Wie lange dauert es, bis eine Aktion des Spielers den Server erreicht?
In der Praxis sind RTT und 2×OWD bei symmetrischen Verbindungen annähernd gleich. Aber auf mobilen Netzwerken oder bei asymmetrischem Routing können erhebliche Unterschiede entstehen – ein Faktor, den Game-Server-Betreiber bei der Analyse berücksichtigen sollten.
Jitter: Das unterschätzte Problem
Während Latenz die durchschnittliche Verzögerung beschreibt, misst Jitter die Varianz dieser Verzögerung. Ein Spieler mit konstantem 60ms-Ping erlebt ein vorhersehbares Spielgefühl. Ein Spieler mit einem zwischen 20ms und 150ms schwankenden Ping – also hohem Jitter – erlebt ruckelnde Bewegungen und unvorhersehbare Reaktionszeiten, selbst wenn der Durchschnitt niedrig ist.
Jitter entsteht durch:
- Überlastete Netzwerksegmente (Puffer-Bloat)
- Variierendes Routing (Pakete nehmen verschiedene Wege)
- Schwankende Serverauslastung
- QoS-Konflikte auf geteilten Netzwerkleitungen
Gegenmaßnahmen gegen Jitter
Serverseitig lässt sich Jitter durch stabile CPU-Last (keine Spitzenlast durch andere Prozesse), dedizierte Netzwerkschnittstellen und sauber konfigurierte Sendepuffer reduzieren. Clientseitig kompensieren Game-Engines Jitter durch Interpolation: Statt den Client exakt zu dem Zeitpunkt zu rendern, an dem ein Paket ankommt, wird der Spielzustand zwischen den letzten empfangenen Positionen geglättet. Das erzeugt ein ruhigeres Bild – auf Kosten einer kleinen zusätzlichen Verzögerung.
Paketverlust: Wenn Daten nie ankommen
UDP – das bevorzugte Transportprotokoll für Echtzeit-Spiele – garantiert keine Zustellung. Pakete können verloren gehen, ohne dass das Protokoll automatisch nachfordert. Das ist bewusst so: Eine Nachforderung würde Verzögerung erzeugen, die für Echtzeit-Anwendungen schädlicher wäre als der Verlust selbst.
Game-Engines kompensieren Paketverlust durch eigene Mechanismen:
- Extrapolation: Wenn ein Paket fehlt, wird die letzte bekannte Position und Bewegung des Objekts weitergerechnet. Das funktioniert gut bei gleichmäßiger Bewegung, versagt bei plötzlichen Richtungsänderungen.
- Redundante Datenpakete: Kritische Informationen werden in mehreren aufeinanderfolgenden Paketen gesendet. Geht eines verloren, enthält das nächste die fehlende Information noch einmal.
- Forward Error Correction (FEC): Ähnlich wie bei Audio-Codecs werden redundante Prüfdaten mitgesendet, aus denen verlorene Pakete rekonstruiert werden können.
Praktische Optimierungsschritte für Server-Betreiber
Unabhängig von der verwendeten Game-Engine gibt es Maßnahmen, die fast immer die Netzwerkqualität verbessern:
Regionale Verteilung
Der einfachste Weg zu niedrigerer Latenz ist geografische Nähe. Server in Frankfurt bedienen europäische Spieler mit deutlich niedrigerer RTT als ein Server in Nordamerika. Edge-Deployments – kleinere Server-Instanzen nahe an Ballungsräumen – reduzieren Latenz weiter, erfordern aber mehr Betriebsaufwand.
Netzwerk-Tuning auf OS-Ebene
Auf Linux-Systemen lassen sich mehrere Parameter optimieren:
- Sendepuffer und Empfangspuffer anpassen (
net.core.rmem_max,net.core.wmem_max) - BBR als Congestion-Control-Algorithmus verwenden
- CPU-Affinität für Netzwerk-Interrupts konfigurieren
Vor Änderungen sollten Baseline-Messungen vorliegen, um den Effekt jeder Maßnahme isoliert beurteilen zu können.
Monitoring: Welche Metriken wirklich zählen
Wer Netzwerkqualität verbessern will, muss sie zuerst messen. Relevante Metriken für Game-Server:
- P95- und P99-Latenz: Durchschnittswerte verbergen Ausreißer. Das 99. Perzentil zeigt, was der schlechteste ein Prozent der Spieler erlebt.
- Jitter-Varianz: Standardabweichung der Latenz über Zeitfenster
- Paketverlustrate: Getrennt für Uplink (Client → Server) und Downlink (Server → Client)
- Tick-Rate-Konsistenz: Schwankungen in der tatsächlichen vs. konfigurierten Tick-Rate deuten auf Server-Überlastung hin
Diese Metriken lassen sich über externe Monitoring-Systeme kontinuierlich erfassen. Serverausfälle, Latenz-Spitzen und Heartbeat-Abbrüche können so frühzeitig erkannt und Alarme konfiguriert werden – bevor Spieler sich beschweren.
Fazit
Tick-Rate, Jitter und Paketverlust sind keine abstrakten Netzwerkkennzahlen – sie sind direkt spürbar für jeden Spieler auf einem Server. Betreiber, die diese Größen verstehen, messen und gezielt optimieren, schaffen die Voraussetzung für ein stabiles, faires und reaktionsschnelles Spielerlebnis. Der erste Schritt ist immer das Monitoring: Was nicht gemessen wird, kann nicht verbessert werden.
Bildquelle: Pexels / Lalesh Aldarwish (pexels.com) – Foto-ID 442150
Quellen: Valve Source-Engine Networking-Dokumentation; Riot Games Engineering Blog zu Netzwerkoptimierung; Linux Kernel Networking Documentation; eigene Aufbereitung und Redaktion 2026.
