Lag messen statt raten: Server, Leitung oder Spieler?

Ein Spieler schreibt „laggt“. Das kann alles bedeuten: Die Weltschleife des Servers kommt nicht hinterher, Pakete brauchen zu lange, oder der Rechner des Spielers schafft die Bilder nicht. Die drei Ursachen sehen im Spiel ähnlich aus und haben nichts miteinander zu tun.

Diese Reihenfolge trennt sie zuverlässig.

Schritt 1: Rechnet der Server schnell genug?#

Die Weltschleife hat ein festes Zeitbudget. Bei 20 Ticks pro Sekunde sind das 50 Millisekunden pro Tick; bei 60 Ticks entsprechend 16,7. Braucht ein Tick länger, verschiebt sich alles Folgende, das ist Serverlag, und keine Leitung der Welt ändert daran etwas.

Die Kennzahl heißt MSPT (Millisekunden pro Tick) und wird von Profiler-Mods, Plugins oder der Serverkonsole ausgegeben. Faustregel:

MSPT bei 20 Ticks	Bedeutung
unter 30	Luft nach oben, alles gut
30-45	eng, Spitzen werden schon spürbar
über 50	die Tickrate bricht ein

Von außen, ohne Spielwerkzeuge, siehst du dasselbe an der Auslastung:

# Ein Thread dauerhaft am Anschlag ist die Weltschleife.
top -H -p $(pgrep -f server.jar)

# Und: bekommt der Prozess überhaupt CPU-Zeit?
vmstat 1 5      # Spalte "st" = Steal Time

Steal Time schlägt jede Optimierung

Zeigt vmstat dauerhaft mehrere Prozent Steal Time, wartet dein Server auf CPU-Zeit, die ein anderer Kunde gerade verbraucht. Dagegen hilft keine Einstellung im Spiel und keine Mod, nur dedizierte Kerne. Warum das gerade bei Spielservern durchschlägt, steht in Takt schlägt Kerne.

Schritt 2: Ist die Leitung das Problem?#

Wenn MSPT in Ordnung ist, liegt es am Weg dorthin. Drei Werte, nicht einer:

Laufzeit (Ping), wie lange ein Paket unterwegs ist.
Schwankung (Jitter), wie stark die Laufzeit variiert. Für Spiele schlimmer als eine hohe, aber gleichmäßige Laufzeit: Gleichmäßig kann der Client vorhersagen, schwankend nicht.
Verlust, wie viele Pakete gar nicht ankommen.

# Alle drei auf einmal, mit Angabe, an welcher Zwischenstelle es passiert:
mtr -rwzc 200 <ip-des-spielers-oder-eines-testziels>

So liest du die Ausgabe:

Verlust nur in einer mittleren Zeile, nicht am Ende: meist harmlos. Viele Router antworten selbst nicht auf Testpakete, leiten aber sauber weiter.
Verlust in einer Zeile und in allen danach: dort ist das Problem.
Sprung in der Spalte StDev: dort schwankt es, das ist der Jitter, den Spieler als Ruckeln erleben.

# Gegenprobe mit echter Last statt Testpaketen, in beide Richtungen:
iperf3 -s                       # auf dem Server
iperf3 -c <server-ip> -u -b 20M # vom Client, UDP wie das Spiel selbst

Schritt 3: Liegt es an einzelnen Spielern?#

Wenn Server und Leitung sauber sind und trotzdem drei von zwanzig Spielern klagen, liegt es an deren Anschluss oder Rechner. Das ist keine Ausrede, sondern etwas, das du zeigen kannst: Die Spielerliste vieler Server zeigt den Ping pro Spieler. Sind es genau die mit den hohen Werten, ist der Fall klar.

Was in welcher Reihenfolge zu tun ist#

Wenn Schritt 1 der Schuldige ist, in dieser Reihenfolge, weil es so am billigsten ist:

simulation-distance senken. Kostet Sekunden, bringt oft am meisten.
Profiler laufen lassen, den größten Einzelposten suchen. Häufig eine Mod, eine Farm oder ein Weltgenerator.
Speicherbereinigung prüfen. Regelmäßige Aussetzer im gleichen Takt sind ein GC-Muster, kein Netzproblem (Startflags).
Welt aufräumen: herrenlose Objekte, riesige Maschinen, geladene Bereiche ohne Spieler.
Erst dann Hardware.

Wenn Schritt 2 der Schuldige ist:

Standort prüfen. Ein Server auf der falschen Seite des Kontinents ist keine Konfigurationsfrage.
MTU prüfen, wenn ein Tunnel oder VPN im Spiel ist, Pakete, die zu groß sind, verschwinden lautlos.
Anbieter mit dem mtr-Ergebnis konfrontieren, nicht mit „laggt“.

Dauerhaft messen statt im Ernstfall suchen#

Ein Wert, der nur im Problemfall erhoben wird, hat keinen Vergleichspunkt. Zwei Zahlen reichen für den Anfang: MSPT und Spielerzahl, alle 30 Sekunden aufgezeichnet.

# Minimalvariante: Wert in eine Datei, Grafik später
while true; do
  echo "$(date +%s) $(mspt-abfrage-deines-servers)" >> /var/log/mspt.log
  sleep 30
done

Wer es ordentlich will, hängt beides an die vorhandene Überwachung (Monitoring aufsetzen). Der Nutzen zeigt sich beim ersten Vorfall: Du siehst, ob die Last mit der Spielerzahl gestiegen ist oder plötzlich seit Dienstagabend und Dienstagabend hat jemand etwas gebaut.

Häufige Fragen#

Der Ping ist gut, es ruckelt trotzdem. Wie geht das?#

Dann rechnet der Server zu langsam. Ping misst den Weg, nicht die Rechenzeit. Genau dafür ist Schritt 1 der erste Schritt.

Hilft mehr Bandbreite?#

Fast nie. Spielserver bewegen wenig Daten; sie brauchen sie nur pünktlich. Bandbreite hilft gegen Verlust durch Überlast, nicht gegen Laufzeit.

Was ist ein guter Ping?#

Unter 30 ms merkt praktisch niemand etwas, bis 60 ms spielt es sich gut, ab 100 ms wird es in schnellen Spielen unangenehm. Wichtiger als der Absolutwert ist, dass er stabil ist.

Warum schwankt es nur abends?#

Weil dann mehr los ist, bei dir, beim Anbieter oder beim Anschluss der Spieler. Genau deshalb ist die dauerhafte Aufzeichnung mehr wert als eine Messung im Moment der Beschwerde.

Kann eine einzelne Mod die Tickrate ruinieren?#

Ja, und das ist der häufigste Fall bei großen Modpacks. Der Profiler zeigt sie in der Regel als einzelnen dominanten Eintrag.

Kurz gesagt#

Erst MSPT, dann Netz, dann Spieler. Die Reihenfolge spart die meiste Zeit.
Steal Time in vmstat ist der Killer, gegen den keine Einstellung hilft.
Jitter ist schlimmer als hoher Ping, Schwankung lässt sich nicht vorhersagen.
mtr sagt dir wo, iperf3 sagt dir wie viel.
Dauerhaft messen. Ohne Verlauf ist jeder Wert nur eine Behauptung.