Warum Latenz für Gameserver und das Spielerlebnis zählt

Was Latenz mit einem Multiplayer-Spiel macht

Latenz ist die Verzögerung zwischen der Aktion eines Spielers und der Reaktion der Spielwelt darauf. Sie drücken ab, und es vergeht eine Lücke, bevor der Server bestätigt, dass Sie geschossen haben, entscheidet, ob Sie getroffen haben, und jedem anderen Client mitteilt, was passiert ist. Bleibt diese Lücke klein und gleichmäßig, fühlt sich das Spiel präzise an: Schüsse landen dort, wo Sie gezielt haben, Bewegungen sind direkt, andere Spieler bewegen sich flüssig. Wächst sie oder schwankt sie, fühlt sich dasselbe Spiel schwammig, unfair oder kaputt an, obwohl auf keiner Maschine etwas ausgefallen ist.

Das Nützlichste, was man verstehen sollte: Der Ping ist nicht die ganze Geschichte. Er misst einen Abschnitt der Strecke, den Round Trip über das Netzwerk. Was ein Spieler spürt, ist eine längere Kette, zu der auch gehört, wie oft der Server die Welt aktualisiert, wie der Client die Verzögerung kaschiert und ob die Verbindung stabil ist oder jittert. Ein Server kann einen hervorragenden Ping zeigen und sich trotzdem schlecht anfühlen, und ein Server in zweitausend Kilometern Entfernung kann sich für das passende Genre gut anfühlen.

Für einen Host ist die Antwort in einer Zeile kurz: Stellen Sie den Server nahe an Ihre Spieler, auf Hardware, die ihre Tickrate unter Last hält. Der Rest des Artikels erklärt, warum diese beiden Dinge dominieren und was Sie am Rest ändern können und was nicht.

Dieser Artikel ergänzt unseren Leitfaden zum Betrieb von Gameservern auf Bare Metal und den ausführlicheren Blick auf die Spieleleistung auf Bare Metal im Vergleich zu virtualisierten Systemen. Hier ist der Fokus enger: woher Verzögerung kommt und wie sie beim Spieler ankommt.

Die Bestandteile eines Round Trips

Wenn ein Spieler klickt, ist die gefühlte Verzögerung die Summe mehrerer Stufen, und nur ein Teil davon ist das Netzwerk. Ein einzelner Input, verfolgt von der Maus bis zum Bildschirm:

1. Input-Sampling. Der Client fragt Maus und Tastatur nach seinem eigenen Zeitplan ab. Ihr Klick kann ein oder zwei Frames liegen bleiben, bevor die Spielschleife ihn überhaupt liest. Bei 120 fps sind das ein paar Millisekunden, bei 30 fps über 30.
2. Senden durch den Client. Der Client verpackt den Input und schickt ihn ab. Auch Clients bündeln und senden in ihrem eigenen Takt, es kann also kurz dauern, bis das Paket losgeht.
3. Letzte Meile. Das Paket durchläuft die Verbindung des Spielers: WLAN, Heimrouter, das Zugangsnetz, bis zum ersten echten Hop. Hier entsteht ein großer Teil der Latenz bei Endkunden und der meiste Jitter.
4. Transit und Peering. Das Paket durchquert ein oder mehrere Netze, um das Netz des Servers zu erreichen. Wie direkt es dort ankommt, hängt vom Peering ab: Ein gut gepeerter Pfad übergibt an einem Internet Exchange in derselben Region, ein schlechter macht vorher einen Umweg durch ein anderes Land.
5. Warteschlange auf dem Server. Das Paket kommt an und wartet, bis der Spielprozess es liest.
6. Tick-Alignment. Diese Stufe wird gern vergessen. Der Server verarbeitet Ihren Input nicht in dem Moment, in dem er ankommt, sondern im nächsten Simulationstick. Tickt der Server 20-mal pro Sekunde, kann Ihr Input bis zu 50 ms auf den nächsten Tick warten, bevor irgendetwas mit ihm passiert, egal wie schnell das Netzwerk war.
7. Verarbeitung. Der Tick führt die Simulation aus: Er wendet Ihren Input an, wertet Treffer aus, bewegt Entitäten und bestimmt den neuen Zustand der Welt. Ist der Server überlastet und braucht ein Tick länger als sein Budget, dehnt sich diese Stufe, und jeder Spieler spürt es gleichzeitig.
8. Rückweg. Der Server schickt den aktualisierten Zustand zurück, und die gesamte Netzwerkstrecke läuft in umgekehrter Richtung, bevor Ihr Bildschirm das Ergebnis zeigt.

Der Ping misst grob die Stufen drei, vier und acht, sonst nichts. Deshalb ist er notwendig, aber nicht ausreichend. Zwei Server mit identischem Ping von 30 ms können sich unterschiedlich anfühlen, weil sich die Stufen eins, zwei, sechs und sieben unterscheiden. Vor allem das Tick-Alignment ist für den Ping unsichtbar und bei einem Spiel mit niedriger Tickrate oft größer als die Netzwerkverzögerung.

Tickrate und Latenz sind zwei verschiedene Uhren

Ein Server simuliert die Welt in einzelnen Schritten, den Ticks. Die Tickrate gibt an, wie viele dieser Schritte pro Sekunde laufen, und sie legt die Auflösung von allem fest, was der Server tut. Sie ist eine eigene Uhr neben der Netzwerklatenz, und Sie müssen beide kurz halten.

Die Rechnung ist einfach. Minecraft betreibt seine Welt mit 20 Ticks pro Sekunde, ein Tick alle 50 ms, laut dem Tick-Modell des Spiels. Selbst auf einem Server im selben Gebäude kann ein Minecraft-Input also bis zu 50 ms auf den nächsten Tick warten, und Redstone-Timing ist in 50-ms-Schritte quantisiert. Das ist kein Lag durch einen schlechten Host, sondern das Design des Spiels.

Kompetitive Shooter laufen viel schneller, weil sie feineres Timing brauchen. Riot hat Valorant auf 128-Tick-Servern aufgebaut, ein Tick alle 7,8 ms, gezielt damit ein Verteidiger Zeit hat, auf einen Angreifer zu reagieren, der um eine Ecke peekt. Counter-Strike 2 ging einen anderen Weg: Die Server laufen mit 64 Tick, aber Valve hat ein Subtick-System ergänzt, das jeden Input auf die Millisekunde mit einem Zeitstempel versieht und ihn zu dem Zeitpunkt anwendet, an dem er geschah, statt ihn auf den nächsten Tick zu runden. Das soll den größten Teil des Abstands zu echtem 128-Tick-Gefühl schließen. Ob es das vollständig schafft, ist unter Spielern weiter umstritten, aber die Absicht des Designs ist klar: die Verzögerung durch das Tick-Alignment zu verringern, ohne die Arbeit des Servers zu verdoppeln.

Survival- und Sandbox-Spiele liegen niedriger und setzen auf Konfigurierbarkeit. Rust und ARK bieten die Tickrate als Servereinstellung an, und von der Community betriebene Instanzen belassen sie häufig bei etwa 30: weniger Reaktionsschnelligkeit im Tausch gegen CPU-Reserven auf Maschinen, die große Welten hosten. Es geht nicht um die exakte Zahl für einen Titel, die sich zwischen Patches ändert, sondern um das Muster.

Tickraten ändern sich zwischen Spielversionen und sind bei selbst gehosteten Titeln konfigurierbar; lesen Sie dies als grobe Orientierung, nicht als Datenblatt. Prüfen Sie den aktuellen Wert für Ihre Version, bevor Sie ihn zitieren.

Eine höhere Tickrate verkürzt die Wartezeit durch das Tick-Alignment und sonst nichts. Die Leitung wird dadurch nicht kürzer. Ein 128-Tick-Server auf dem falschen Kontinent lässt Spieler weiterhin auf den Round Trip warten; ein 20-Tick-Server in der richtigen Stadt lässt sie weiterhin 50 ms auf den nächsten Tick warten. Beide Uhren sind real, und ein guter Host achtet auf beide.

Wie Netcode die Verzögerung verbirgt und wo die Illusion bricht

Weder Tickrate noch Peering bringen die Latenz auf null, also täuschen Spiele stattdessen überzeugend. Netcode ist die Sammlung von Tricks, die die Verzögerung vor dem Spieler verbergen. Vier davon zählen am meisten.

Client-side Prediction. Statt darauf zu warten, dass der Server Ihre Bewegung bestätigt, zeigt der Client sie sofort an und sagt voraus, was der Server mit hoher Wahrscheinlichkeit akzeptiert. Ihre Figur bewegt sich in dem Moment, in dem Sie nach vorn drücken. Trifft das maßgebliche Update des Servers ein und stimmt überein, merken Sie nichts. Weicht es ab, korrigiert der Client.

Entity Interpolation. Die Positionen anderer Spieler kommen als einzelne Snapshots an, im Abstand der Tickrate und vom Netzwerk ungleichmäßig gemacht. Um sie flüssig zu zeichnen, hält der Client einen kleinen Puffer und rendert sie leicht in der Vergangenheit, interpoliert zwischen den letzten beiden bekannten Positionen. Deshalb sehen andere Spieler selbst auf einer bescheidenen Verbindung flüssig aus. Es bedeutet aber auch, dass Sie alle anderen stets einen Takt hinter ihrer tatsächlichen Position auf dem Server sehen.

Lag Compensation. Wenn Sie schießen, spult ein server-autoritatives Spiel seinen eigenen Zustand um Ihre Latenz zurück und bewertet den Schuss danach, wo das Ziel auf Ihrem Bildschirm war, als Sie geschossen haben, nicht danach, wo es jetzt ist. Riot beschreibt genau dieses Zurückspulen in seinem Beitrag zum Netcode. Ohne Lag Compensation könnten Spieler mit hohem Ping nie ein bewegtes Ziel treffen. Mit ihr bekommen sie eine faire Chance.

Rollback. Fighting Games, die keinerlei Input-Verzögerung vertragen, nutzen Rollback-Netcode. Der Client nimmt die nächsten Inputs des Gegners an, simuliert ohne Verzögerung vorwärts, und lag die Annahme falsch, setzt er den Spielzustand zurück, simuliert ab dem Punkt der Abweichung neu und spult dann bis zur Gegenwart vor. Bekannt wurde die Technik durch das GGPO SDK, und inzwischen wird sie bei kompetitiven Fighting Games erwartet. Gut umgesetzt fühlt sich Online-Spiel wie lokales Spiel an, bis die Verbindung so schlecht wird, dass die Korrekturen sichtbar werden.

Die Illusion bricht an vorhersehbaren Stellen, und jeder Spieler kennt sie:

• Peeker's Advantage. Der Spieler, der sich um eine Ecke bewegt, sieht den stillstehenden Verteidiger, bevor der Verteidiger ihn sieht, weil Interpolation und Round Trip dazu führen, dass der Client des Verteidigers die Vergangenheit zeigt. Zusammen mit Lag Compensation gewinnt der Peeker oft das Duell. Riot nennt genau dies als Grund für die Wahl von 128-Tick-Servern.
• Der Streit darüber, wer zuerst geschossen hat. Sie gehen hinter Deckung und sterben einen Moment später. Auf Ihrem Bildschirm waren Sie sicher; auf dem Bildschirm des Schützen, durch Lag Compensation zurückgespult, standen Sie noch frei, als er schoss. Der Server hat seine Sicht übernommen. Niemand hat geschummelt.
• Rubberbanding und Warping. Liegt die Vorhersage falsch oder gehen Updates verloren, reißt die Korrektur Ihre Figur, oder die eines anderen Spielers, an die Stelle zurück, an der sie laut Server sein sollte. Dieser Ruck zurück ist die Illusion, die in Echtzeit versagt, und die Ursache ist fast immer Paketverlust oder eine jitternde Verbindung, nicht der Ping an sich.

Wie viel Latenz jedes Genre verbergen kann

Netcode verschafft in verschiedenen Genres unterschiedlich viel Spielraum, daher gibt es keine einzelne Zahl für "akzeptable" Latenz. Das meistzitierte Modell ist das von Claypool und Claypool aus dem Jahr 2006 in den Communications of the ACM, das die Latenztoleranz eines Spiels an die Perspektive des Spielers knüpft und daran, wie präzise und zeitkritisch seine Aktionen sind.

Ihr Ergebnis in runden Zahlen: First-Person-Spiele wie Shooter und Rennspiele, in denen Sie einen Avatar direkt steuern und unter engen Fristen handeln, werden ab etwa 100 ms schlechter. Third-Person-Spiele mit Avatar, etwa viele Rollenspiele, bleiben bis rund 500 ms spielbar, weil Aktionen weniger zeitkritisch sind. Omnipräsente Spiele, in denen Sie Einheiten von oben steuern wie in Echtzeitstrategie, vertragen am meisten; spätere Arbeiten zum Genre setzen eine brauchbare Obergrenze bei etwa 1.000 ms an, weil ein Befehl keine Reflexhandlung ist.

Was diese Forschung für die Praxis bedeutet, unabhängig von den genauen Schwellen:

• Kompetitive Shooter und Fighting Games verzeihen am wenigsten. Spieler bemerken Dutzende Millisekunden, und Konstanz zählt genauso viel wie der Durchschnitt. In diesem Genre ist der Serverstandort praktisch nicht verhandelbar.
• MOBAs und Action-RPGs liegen in der Mitte. Sie verbergen mehr Verzögerung durch Vorhersage und weniger zeitkritische Inputs, aber kompetitives Spiel belohnt weiterhin niedrige, stabile Latenz.
• MMOs und Strategiespiele vertragen am meisten. Rundenbasierte und langsamere Echtzeitspiele können Spieler über einen ganzen Kontinent verteilen und laufen trotzdem gut.

Verstehen Sie das als Richtung. Die Zahlen verschieben sich mit dem konkreten Spiel, dem Können des Spielers und der Qualität des Netcodes. Die sichere Designregel: Wählen Sie Standort und Hardware des Servers für das latenzempfindlichste, was Ihre Spieler darauf tun werden.

Warum Jitter und Paketverlust mehr schaden als ein stabiler höherer Ping

Bei Latenz geht es nicht nur darum, wie hoch sie ist, sondern auch, wie stabil. Eine Verbindung, die konstant bei 80 ms liegt, fühlt sich meist besser an als eine, die im Schnitt 50 ms erreicht, aber stark schwankt, und der Grund ist der Netcode aus dem vorigen Abschnitt.

Interpolation und Vorhersage gehen beide von einer ungefähr konstanten Verzögerung aus. Bekommen sie einen stabilen Ping, finden sie einen Rhythmus; Puffergröße und Korrekturtakt bleiben fest, und das Timing des Spielers passt sich an. Jitter zerstört das. Springt der Round Trip zwischen 40 ms und 120 ms hin und her, kann der Client keinen Puffer wählen, der zugleich klein und sicher ist. Entweder vergrößert er den Puffer und fügt damit allen Verzögerung hinzu, oder er hält ihn knapp und bekommt verspätete Snapshots, die als Ruckeln sichtbar werden.

Paketverlust ist noch schlimmer. Ein verlorenes Update ist kein verspäteter Frame, sondern ein fehlender. Der Client hält entweder den letzten bekannten Zustand fest, wodurch ein anderer Spieler mitten im Schritt einfriert, oder er extrapoliert darüber hinaus und springt zurück, sobald die tatsächliche Position eintrifft. Dieser Sprung ist Rubberbanding. Ein konstanter Verlust von 1 bis 2 Prozent lässt ein Spiel kaputt wirken, bei einem Ping, der sonst hervorragend wäre.

Die Designlehre für einen Host: Ein gut gepeerter Pfad mit stabilem Timing schlägt einen etwas kürzeren Pfad, der überlastet. Eine Route, die gelegentlich einen Link sättigt und Pakete verliert, fühlt sich schlechter an als eine geringfügig längere, die das nie tut.

Geografie und Routing entscheiden das meiste

Von allem, was ein Host beeinflussen kann, ist die physische Entfernung der größte und am wenigsten verhandelbare Faktor. Licht in Glasfaser bewegt sich mit etwa zwei Dritteln seiner Geschwindigkeit im Vakuum, rund 200 km pro Millisekunde, woraus sich die nützliche Faustregel ergibt: etwa 1 ms Round-Trip-Verzögerung pro 100 km Kabel, vor jedem Routing-Overhead. Amsterdam nach Frankfurt sind ein paar Millisekunden auf der Leitung; Amsterdam nach Sydney kann nicht unter etwa 150 ms in eine Richtung liegen, egal was Sie zahlen, weil der Planet nun einmal so groß ist.

Das Routing entscheidet, wie nah Sie dieser physischen Untergrenze tatsächlich kommen. Zwei Server in gleicher Entfernung können sich um Dutzende Millisekunden unterscheiden, je nachdem, wie ihr Traffic transportiert wird. Ein gut gepeertes Netz übergibt Traffic direkt an andere Netze an einem Internet Exchange in derselben Region und hält den Pfad kurz. Ein schlecht angebundenes Netz verlässt sich auf Transit, der Ihre Pakete womöglich durch eine entfernte Stadt schickt, bevor sie zurückkommen, mit zusätzlicher Latenz und zusätzlichen Hops, an denen Pakete verloren gehen oder sich verzögern können. Deshalb veröffentlicht unsere Netzwerkseite unser Peering: Der Pfad ist Teil des Produkts.

Die Schlussfolgerung für einen Host ist deutlich. Der Serverstandort wiegt schwerer als jeder andere Latenzhebel, den Sie kontrollieren, weil er die Untergrenze festlegt, innerhalb derer Tickrate und Netcode dann arbeiten. Eine europäische Spielerbasis sollte von einem gut angebundenen europäischen Standort bedient werden, nicht über einen Ozean dorthin geroutet, wo Kapazität am billigsten war. Deshalb gibt es unseren Standort Amsterdam als eigene Wahl: Für Spieler in Europa beseitigt das Hosting dort mehr gefühlte Latenz als jedes Tuning auf der Maschine selbst.

Die Latenz, die Sie als Host kontrollieren

Entfernung und Routing legen die Untergrenze fest. In den serverseitigen Stufen des Round Trips hält ein Host diese Untergrenze oder ruiniert sie, und das ist der Teil, den Sie selbst betreiben.

Das größte serverseitige Risiko ist ein Tick, der sein Budget überschreitet. Ein 20-Tick-Server hat 50 ms, um jeden Tick abzuschließen; ein 64-Tick-Server etwa 15 ms. Schafft die Simulation es nicht in diesem Fenster, verrutschen Ticks, die effektive Rate sinkt, und jeder verbundene Spieler spürt im selben Moment zusätzliche Verzögerung. Das meinen Leute meist mit "der Server laggt", unabhängig vom Ping eines einzelnen Spielers. Es ist ein CPU-Problem, und Spielsimulationen hängen an der Single-Thread-Leistung, weshalb schnelle Cores für diesen Workload viele langsame schlagen. Diesen Zielkonflikt behandeln wir im Artikel zu Bare Metal im Vergleich zu VMs.

Überbuchtes Shared Hosting ist der übliche Weg, auf dem das schiefgeht. Packt ein Anbieter zu viele Instanzen auf eine physische Maschine, konkurriert Ihr Spielprozess um CPU-Zeit, von der er dachte, sie gehöre ihm. Auf virtualisierten Hosts zeigt sich das als CPU Steal: Zyklen, die der Hypervisor einem Nachbarn gibt statt Ihnen. Steal Time wird zu verrutschten Ticks, und verrutschte Ticks werden zu gefühlter Latenz für jeden Spieler auf Ihrem Server, ohne dass das Netzwerk etwas dafür kann. Eine dedizierte Maschine entfernt den Nachbarn vollständig, und das ist das wichtigste Latenzargument für den Betrieb von Gameservern auf Bare Metal.

Angriffe sind ebenfalls eine Latenzquelle, nicht nur eine Ursache für Ausfälle. Ein volumetrischer DDoS-Angriff, der den Uplink sättigt, treibt Latenz und Paketverlust für legitime Spieler nach oben, lange bevor der Server ganz offline geht; das Spiel fühlt sich an, als ertrinke es in Jitter. Mitigation, die die Flut upstream herausfiltert, hält den Pfad sauber, und das ist ebenso ein Latenzgewinn wie ein Gewinn an Verfügbarkeit.

Der Rest ist gewöhnliche Hosting-Disziplin: Geben Sie dem Spielprozess die Cores, die er braucht, halten Sie die Tick-Schleife im Budget, und lassen Sie keinen Hintergrundjob und keinen lauten Mitmieter zu Spitzenzeiten Zyklen stehlen.

Richtig messen

Wenn Sie Latenz diagnostizieren, ist eine einzelne Ping-Zahl das am wenigsten nützliche Werkzeug, weil sie den gesamten Pfad in einen Wert zusammenfasst und verbirgt, wo die Verzögerung sitzt.

ping liefert Ihnen den Round Trip zum Server und, eine Weile laufen gelassen, einen Eindruck von Jitter und Verlust. Es beantwortet "wie weit und wie stabil", aber nichts über den Pfad.

ping -c 50 203.0.113.10

mtr kombiniert Traceroute und Ping: Es pingt jeden Hop entlang des Pfads fortlaufend und zeigt Verlust und Latenz pro Hop. Das sagt Ihnen, wo das Problem liegt. Tauchen Latenz und Verlust bei Hop 3 auf und bleiben bis zum Server hoch, liegt das Problem früh, nahe beim Spieler. Ist bis zum letzten Hop alles sauber, schauen Sie sich den Server an. Zeigt ein Hop in der Mitte Verlust, die Hops danach aber nicht, begrenzt dieser Hop wahrscheinlich nur seine eigenen ICMP-Antworten und kann ignoriert werden.

                             Packets               Pings
 Host                       Loss%   Snt   Avg  Best  Wrst
 1. 203.0.113.1              0.0%    50   0.5   0.3   1.2
 2. 198.51.100.9             0.0%    50   3.4   2.9   9.8
 3. 198.51.100.40            0.0%    50  11.5  10.9  24.6
 4. 192.0.2.50               0.0%    50  18.9  18.3  31.4

Der Net Graph im Spiel ist die Messung, die dem entspricht, was der Spieler spürt, weil er das Tick-Alignment und die Serververarbeitung einbezieht, die der Ping nicht sieht. Die meisten kompetitiven Titel haben einen: Er zeigt die Latenz vom Client zum Server, die Interpolationsverzögerung, Paketverlust und oft die Tick-Leistung des Servers selbst. Sieht der Ping eines Spielers gut aus, fühlt sich das Spiel aber schlecht an, zeigt der Net Graph meist den eigentlichen Verursacher: einen gedehnten Interpolationspuffer oder einen Server, dessen Tickrate eingebrochen ist.

Die Zahlen oben dienen der Veranschaulichung und nutzen für Dokumentation reservierte IP-Bereiche. Ihre eigenen Werte unterscheiden sich je nach Standort, Route und Tageszeit; führen Sie die Befehle gegen Ihren eigenen Server aus und lesen Sie die Form des Ergebnisses, nicht diese Zahlen.

Deployment bei Serverside.com

Latenz wird größtenteils entschieden, bevor sich der erste Spieler verbindet: dadurch, wo der Server steht und wie sein Netzwerk geroutet ist. Ein Serverside.com-Gameserver läuft auf Bare Metal in unserem eigenen Netz (AS55285). Ihre Tick-Schleife bekommt also eine ganze Maschine ohne lauten Nachbarn, der Zyklen stiehlt, und der Pfad zu Ihren Spielern läuft über Routing, das wir selbst peeren und veröffentlichen, statt über den Transit, der am billigsten war. Eine ständig aktive DDoS-Mitigation sitzt vor der öffentlichen Schnittstelle und verhindert, dass eine Flut zu Jitter für die Spieler wird, die tatsächlich da sind. Die Bereitstellung dauert weniger als eine Minute, Sie können also eine Maschine am richtigen Ort aufstellen und die Route testen, bevor Sie sich festlegen.

Für eine europäische Spielerbasis ist unser Standort Amsterdam derjenige, der die meiste gefühlte Latenz beseitigt: gut gepeert an den Exchanges der Region, sodass die Zeit auf der Leitung zu Spielern in der EU nahe an ihrer physischen Untergrenze bleibt. Wenn Sie zuerst das gesamte Angebot und alle Standorte sehen möchten, beginnen Sie beim Konfigurator für dedizierte Server und wählen Sie den Standort, der den Spielern am nächsten liegt, für die Sie bauen.

FAQ

Was ist der Unterschied zwischen Ping und Latenz in einem Spiel?

Der Ping ist eine Messung der Latenz: die Round-Trip-Zeit eines kleinen Pakets zum Server und zurück, meist per ICMP. Latenz, wie ein Spieler sie spürt, ist breiter. Dazu gehören der Ping, die Zeit, die Ihr Input bis zum Sampling wartet, die Zeit, die der Server bis zu seinem nächsten Simulationstick wartet, bevor er Ihr Paket verarbeitet, die Verarbeitung in diesem Tick und der Rückweg. Zwei Spieler mit demselben Ping von 30 ms können unterschiedlich viel Verzögerung spüren, wenn einer auf einem 20-Tick-Server spielt und der andere auf einem 128-Tick-Server, denn das Warten auf den Tick gehört zur gefühlten Latenz, und der Ping misst es nicht.

Senkt eine höhere Tickrate die Latenz?

Sie senkt einen bestimmten Teil davon. Eine höhere Tickrate verkürzt die durchschnittliche Wartezeit zwischen dem Moment, in dem der Server die Welt abtastet, und dem Moment, in dem er Ihren Input verarbeitet, weil Ticks häufiger stattfinden. Ein 20-Tick-Server aktualisiert alle 50 ms, ein Input kann also bis zu 50 ms liegen bleiben, bevor er verarbeitet wird; ein 128-Tick-Server aktualisiert alle 7,8 ms, die Wartezeit ist also viel kürzer. Was eine höhere Tickrate nicht ändert, ist der Round Trip über das Netzwerk. Steht der Server 5.000 km entfernt, behebt keine Tickrate die rund 50 ms, die das Paket in jede Richtung auf der Leitung verbringt. Tickrate und Netzwerkdistanz sind zwei getrennte Uhren, und Sie müssen beide kurz halten.

Warum verliere ich Duelle, die ich gewonnen glaubte, selbst mit niedrigem Ping?

Meist ist es Lag Compensation in Kombination mit Peeker's Advantage. Server-autoritative Shooter spulen den Spielzustand um Ihre Latenz zurück, um einen Schuss zu bewerten, daher wird der Spieler, der sich bewegt und um eine Ecke peekt, oft als derjenige gewertet, der zuerst geschossen hat, weil er Sie auf seinem Bildschirm sah, bevor Ihr Bildschirm ihn zeigte. Der Server respektiert, was jeder Client in dem Moment sah, in dem er handelte. Deshalb gewinnt meist derjenige das Duell, der um die Ecke kommt, und deshalb hat der Verteidiger das Gefühl, getroffen worden zu sein, nachdem er schon wieder in Deckung gegangen war. Das ist ein Designkompromiss, kein Bug, und eine niedrigere, stabilere Latenz auf beiden Seiten verkleinert die Lücke.

Sind Jitter oder Paketverlust schlimmer als ein hoher Ping?

Bei den meisten Spielen ja. Stabile 80 ms sind vorhersehbar, und sowohl der Netcode als auch das Timing des Spielers passen sich daran an. Jitter, bei dem der Round Trip etwa zwischen 40 ms und 120 ms schwankt, verhindert diese Anpassung, weil sich der Interpolationspuffer und die Vorhersage des Clients auf keine gleichbleibende Verzögerung einstellen können. Paketverlust ist noch schlimmer: Ein verlorenes Update bedeutet, dass der Client den letzten bekannten Zustand einfriert oder extrapoliert und dann korrigiert, und genau das sind Rubberbanding und Warping. Eine Verbindung mit höherem durchschnittlichem Ping, die stabil bleibt, fühlt sich meist besser an als eine mit niedrigerem Durchschnitt, die Spitzen hat und Pakete verliert.

Wie nah muss ein Gameserver an meinen Spielern stehen?

So nah, dass die Laufzeitverzögerung in die Toleranz Ihres Genres passt. Licht in Glasfaser legt rund 200 km pro Millisekunde zurück, als Faustregel gilt also etwa 1 ms Round-Trip-Verzögerung pro 100 km Kabel, vor Routing-Overhead. Ein kompetitiver Shooter braucht Spieler innerhalb weniger hundert Kilometer, damit die Zeit auf der Leitung im einstelligen Millisekundenbereich bleibt; ein Strategiespiel oder MMO kann viel weiter streuen. Für eine europäische Spielerbasis heißt das, an einem gut gepeerten europäischen Standort zu hosten, statt alle über einen Ozean zu routen, und das ist die größte Latenzentscheidung, die ein Host trifft.