Gameserver-Performance: Bare Metal vs. virtuelle Maschinen

Die kurze Antwort

Bare Metal gewinnt bei den zwei Zahlen, die darüber entscheiden, ob sich ein Gameserver gut anfühlt: die Worst-Case-Tick-Zeit und die Worst-Case-Latenz. Eine Single-Tenant-VM auf Hardware, die Sie selbst kontrollieren, kommt so nah heran, dass die meisten Spieler den Unterschied nie bemerken. Bei einem überbuchten Multi-Tenant-VPS, der Sorte, die das billige Ende des Gamehostings füllt, bricht es zusammen, denn genau das, was ein Hypervisor unter Konkurrenzdruck tut (Ihre CPU auf ihre Reihe warten lassen), ist genau das, was eine Game-Loop mit fester Tickrate nicht abfangen kann.

Das ist das ganze Argument in einem Absatz. Ein Gameserver wird nicht daran gemessen, wie viel Arbeit er pro Sekunde schafft, sondern daran, ob jeder einzelne Tick innerhalb seines Budgets fertig wird. Verpassen Sie einen Tick, sieht es jeder verbundene Spieler: Rubberbanding, ein Treffer, der nicht registriert wurde, ein Rollback. Der durchschnittliche Durchsatz kann perfekt aussehen, während das schlechteste eine Prozent der Ticks still und leise das Match ruiniert. Virtualisierung fügt genau diesem schlechtesten einen Prozent Varianz hinzu, und billige Virtualisierung fügt davon eine Menge hinzu.

Die ehrliche Position ist also bedingt, nicht tribal. Bare Metal ist die sichere Standardwahl für alles Kompetitive oder Vielbeschäftigte. Eine VM ist in Ordnung, manchmal sogar die bessere Wahl, wenn Sie den Hypervisor selbst besitzen und kontrollieren, wer sonst noch auf der Maschine läuft. Ein geteilter VPS von einem Anbieter, der viermal mehr vCPUs verkauft, als er Cores hat, ist die Konstellation, die die „warum lagt mein Server"-Threads erzeugt. Dieser Artikel erklärt den Mechanismus hinter beidem und zeigt Ihnen, wie Sie messen, in welcher Situation Sie sich tatsächlich befinden.

Dieser Leitfaden behandelt:

• was ein Hypervisor einer Tick-Loop hinzufügt: vCPU-Scheduling, Steal-Time, Timer-Jitter, NUMA und I/O-Pfade
• warum bei einer Simulation mit fester Tickrate die Tick-Zeit im 95. Perzentil zählt, nicht der Durchschnitt
• die Overcommitment-Ökonomie, die billiges VPS-Gamehosting zum Ruckeln bringt
• wie Sie Steal-Time und Tick-Zeit auf Ihrem eigenen Server messen, mit echten Befehlen
• warum Container keine VMs sind, und wann eine VM wirklich das richtige Werkzeug ist

Für das größere Bild (Managed Hosting gegenüber dem Betrieb einer eigenen Maschine, und die Wahl der Hardware) ist der Leitfaden zu Bare-Metal-Gamehosting der Grundlagenartikel, dem dieser Artikel untergeordnet ist.

Was ein Hypervisor tatsächlich hinzufügt

Beginnen wir mit der freundlichen Version. Ein moderner Hypervisor wie KVM führt CPU-Instruktionen des Gasts mit Hardwareunterstützung (VT-x oder AMD-V) auf dem echten Prozessor aus. Bei reiner Rechenarbeit läuft eine VM innerhalb weniger Prozent der nativen Leistung, und wäre ein Gameserver CPU-gebunden im Sinne von „ein großes Array durchrechnen", würde Virtualisierung kaum eine Rolle spielen. Ist er aber nicht, und genau das ist der Haken. Ein Gameserver ist latenzgebunden nach einem sich wiederholenden Zeitplan, und der Hypervisor sitzt zwischen diesem Zeitplan und der Hardware. Hier ist, was er einfügt.

vCPU-Scheduling und Steal-Time. Die virtuellen CPUs Ihrer VM sind keine CPUs; es sind Threads, die der Host-Scheduler auf echten Cores ausführt, wann immer er es entscheidet. Wenn der Host mit anderen Gästen, Host-Prozessen oder Interrupts beschäftigt ist, wartet Ihr vCPU in einer Warteschlange auf einen physischen Core. Diese Wartezeit ist CPU-Steal-Time, gemeldet als %st oder st in top, vmstat und mpstat. Es ist Zeit, in der Ihr Game-Loop die CPU wollte und sie nicht bekam. Auf einer Maschine mit genug Cores für jeden Gast bleibt sie nahe null; bei Overcommitment steigt sie, und jede Millisekunde Steal-Time ist eine Millisekunde, um die Ihr Tick zu spät dran war. Leasewebs Analyse zu Steal-Time nennt als Faustregel, dass anhaltende Steal-Time über 10 Prozent bedeutet, dass der Gast langsamer läuft, als er sollte.

Timer- und Interrupt-Jitter. Ein Game-Loop wird 20- oder 64-mal pro Sekunde von einem Timer geweckt. Unter Virtualisierung wird dieser Timer-Interrupt selbst vom Hypervisor vermittelt, der jedem Weckvorgang eine kleine, variable Verzögerung hinzufügt. Auf einem untätigen Host ist die Verzögerung vernachlässigbar. Unter Last kann der Weckvorgang um Millisekunden driften, und eine Schleife, die zu spät aufwacht, wird auch zu spät fertig.

NUMA-Effekte. Auf einem Server mit zwei Sockeln ist Speicher, der an einem Sockel hängt, vom anderen aus langsamer zu erreichen. Wenn der Hypervisor Ihre vCPUs auf einem Sockel einplant, während der Speicher Ihrer VM auf dem anderen liegt, zahlt jeder Zugriff die Cross-Node-Strafe. Bare Metal hat dieselbe Physik, aber das Betriebssystem sieht die echte Topologie und platziert Threads entsprechend; eine VM sieht oft eine abgeflachte, künstliche Topologie, sofern der Host nicht bewusst die echte offenlegt.

Memory Ballooning. Das virtio-balloon-Gerät lässt den Host RAM von einem Gast zurückfordern, indem es in ihm einen „Ballon" aufbläst. Praktisch für die Dichte, feindlich für einen Gameserver: Wenn der Host den Speicher zurückholt, den Ihr JVM- oder Spielprozess genutzt hat, bekommen Sie im ungünstigsten Moment Swapping oder Garbage-Collection-Druck. Bei überbuchten Hosts ist Ballooning die Methode, mit der ein Anbieter mehr Gäste unterbringt, als RAM vorhanden ist.

virtio-I/O-Pfade. Disk und Netzwerk laufen über paravirtualisierte Treiber (virtio-blk und virtio-net, meist mit vhost). Die sind schnell; sie sind nicht kostenlos. Jedes Paket und jeder Diskzugriff überquert eine Grenze mehr, als er es auf Bare Metal täte. Bei einer Minecraft-Welt, die Chunks lädt, oder einem stark frequentierten Server, der Logs und World-Saves schreibt, zeigt sich dieser zusätzliche Pfadabschnitt als gelegentliche I/O-Stalls, die einen Tick in die Länge ziehen. Dieselbe VirtIO-Abgabe wird aus der Container-Perspektive in unserem Vergleich LXC vs. KVM behandelt.

Einzeln betrachtet sind das kleine Dinge. Das Problem ist, dass sie alle beim selben Opfer landen: dem Tick, der innerhalb von 50 Millisekunden fertig werden muss, oder 15.

Warum nur der schlechteste Tick zählt

Ein Minecraft-Server tickt 20-mal pro Sekunde, was jedem Tick 50 Millisekunden gibt, um alles zu erledigen: Mob-KI, Redstone, Blockaktualisierungen, Entitätsbewegung, und dann die Welt an jeden Spieler zu senden. Bleiben Sie im Budget, hält der Server 20 TPS. Überschreiten Sie es, dauert der Tick zu lange, der nächste beginnt zu spät, und die Zeit auf dem Server verlangsamt sich für alle gleichzeitig. CS2 lässt seine Simulation mit 64 Tick laufen, etwa 15.6 Millisekunden pro Tick, mit einem Subtick-System, das Eingaben zwischen den Ticks mit einem Zeitstempel versieht, sodass ein Schuss dort trifft, wo er abgegeben wurde. Ein langsamer Tick verzögert trotzdem, wann diese Eingaben verarbeitet werden.

Hier kommt der Teil, der der Kapazitätsplanung ein Bein stellt: Das sind Worst-Case-Probleme, keine durchschnittlichen. Ein Server kann im Schnitt 19.9 TPS erreichen und sich trotzdem furchtbar anfühlen, weil ein Tick einmal pro Sekunde 180 Millisekunden dauert. Durchschnittswerte verbergen das; Perzentile nicht. Die nützliche Zahl ist die Tick-Zeit im 95. Perzentil (p95), nicht der Mittelwert, denn sie sagt Ihnen, wie Ihre langsamen Ticks aussehen, und die langsamen Ticks sind das, was Spieler spüren.

Ein Hypervisor, der hier 8 Millisekunden Steal-Time hinzufügt und dort eine Scheduling-Verzögerung von 12 Millisekunden, wird Ihren Durchschnitt kaum verschieben. Er wird aber Ihr p95 ruinieren. Das ist der ganze Grund, warum Bare Metal und eine gut betriebene VM denselben durchschnittlichen TPS-Wert erreichen und sich dabei in einem Feuergefecht völlig unterschiedlich anfühlen können. Der Durchschnitt sagt „gut"; das 95. Perzentil sagt „stockt unter Last", und nur eines von beiden ist das, was Spieler tatsächlich erleben.

Overcommitment: warum billiges VPS-Gamehosting ruckelt

Die Ökonomie von Budget-VPS-Hosting ist einfach, und sie arbeitet gegen Sie. Ein Anbieter hat eine Maschine mit, sagen wir, 32 physischen Cores. Ehrlich als Dedicated Cores verkauft, ist das eine feste Anzahl Kunden. Als vCPUs mit einem Overcommitment von 4:1 verkauft, sind es 128 vCPUs an Tarifen auf demselben Silizium. Meistens sind die meisten Gäste untätig, also geht die Rechnung auf, und der Anbieter verdient Geld.

In dem Moment, in dem mehrere Ihrer Nachbarn gleichzeitig aktiv werden (ein Backup-Job, ein anderer Gameserver, der volllädt, jemand, der einen Compile-Lauf startet), hat der Host-Scheduler mehr lauffähige vCPUs als Cores und lässt Ihren warten. Diese Wartezeit ist die Steal-Time aus dem letzten Abschnitt, und Sie haben keine Kontrolle darüber, denn die Konkurrenz kommt von Mietern, die Sie nicht sehen können. Das ist das Problem des störenden Nachbarn, und für einen Workload mit fester Tickrate kommt das einem Worst Case ziemlich nahe: Ihr Tick-Budget liegt fest bei 50 oder 15 Millisekunden, aber die CPU-Zeit, die Sie tatsächlich bekommen, ist jetzt eine Lotterie, die von der Auslastung anderer Leute bestimmt wird. Das ist auch, warum ein VPS um 3 Uhr nachts wunderbar benchmarken und bei Spitzenlast zusammenbrechen kann, im selben Tarif, ohne dass sich auf Ihrer Seite etwas geändert hat.

Wie Sie es auf Ihrem eigenen Server messen

Genug Theorie. So finden Sie heraus, ob Virtualisierung Sie auf der Maschine, die Sie haben, tatsächlich etwas kostet.

Steal-Time. Führen Sie top aus und lesen Sie den st-Wert in der Zeile %Cpu(s) ab:

%Cpu(s): 42.1 us,  3.2 sy,  0.0 ni, 38.0 id,  0.0 wa,  0.0 hi,  1.1 si, 15.6 st

Die 15.6 st ist die Zahl, auf die es ankommt: 15.6 Prozent der Zeit wollte diese vCPU laufen und konnte nicht, weil der Host anderswo beschäftigt war. vmstat 1 setzt dieselbe Zahl einmal pro Sekunde in seine ganz rechte st-Spalte, und mpstat -P ALL 1 schlüsselt %steal pro Core auf:

vmstat 1
mpstat -P ALL 1

Auf Bare Metal ist st immer 0, weil es keinen Hypervisor gibt, von dem gestohlen werden könnte, was selbst schon das Verräterische daran ist. Sehen Sie überhaupt Steal-Time, sind Sie auf einem Gast; sehen Sie anhaltend zweistellige Steal-Time, ist Ihr Host überbucht. Diese Ausgaben sind zur Veranschaulichung. Ihre Werte unterscheiden sich je nach Hardware, Last und wie beschäftigt Ihre Nachbarn sind.

Minecraft-Tick-Zeit. Installieren Sie den Spark-Profiler (ein Plugin oder Mod, je nach Serverart) und führen Sie /spark tps aus. Spark meldet die TPS gegen das Ziel von 20 und die Tick-Dauer gegen das 50-Millisekunden-Budget und liefert Ihnen Minimum, Median, 95. Perzentil und Maximum der MSPT:

/spark tps
TPS from last 5s, 10s, 1m, 5m, 15m:
  17.9, 18.8, 19.7, 20.0, 20.0
Tick durations (min/med/95%ile/max ms) from last 10s, 1m:
  22/47/96/210;  20/43/71/180

Achten Sie auf die Spalte 95%ile, nicht auf den Median. Ein Median von 47 Millisekunden bei einem 95. Perzentil von 96 ist ein Server, der im Schnitt gesund aussieht und unter Last stockt. Bei einem überbuchten Gast steigen dieser Perzentilwert und Ihre Steal-Time gemeinsam an, und genau so verbinden Sie das Symptom mit der Ursache. /spark health liefert dieselben TPS- und MSPT-Werte zusammen mit CPU und Speicher in einer Momentaufnahme. (Ausgabe beispielhaft.)

Source- und CS2-Server. Der Konsolenbefehl stats gibt die CPU-Auslastung und einen fps-Wert aus, der die Tickrate widerspiegelt: Ein gesunder 64-Tick-Server meldet fps auf oder knapp über 64, begrenzt durch die Tickrate, und jeder Einbruch unter Last ist ein Frame, das die Simulation nicht rechtzeitig fertigstellen konnte. Führen Sie den Befehl mehrmals hintereinander aus, um die Varianz zu sehen, denn eine einzelne Zeile ist nur eine Momentaufnahme.

Der sauberste Weg, die Kosten des Hypervisors zu isolieren, besteht darin, alles andere konstant zu halten: dieselbe CPU, derselbe RAM, dieselbe Spielversion, dieselbe Last, und nur zu ändern, ob der Server auf Bare Metal oder in einem KVM-Gast auf genau derselben Hardware läuft. Das ist ein Test, den es sich lohnt, in einem kontrollierten Lab durchzuführen, statt ihn aus ersten Prinzipien heraus zu behaupten.

Der Punkt, dem eine Messung eine Zahl geben würde, ist nicht umstritten: Auf identischer Hardware hält der Bare-Metal-Lauf eine niedrigere und flachere Tick-Zeit im 95. Perzentil, und der Nachteil des Gasts wächst mit der Last. Was ein Benchmark klärt, ist, wie groß der Abstand bei einer Single-Tenant-VM ist, die Sie selbst kontrollieren (meist klein), gegenüber dem, was Overcommitment daraus macht (das nicht).

Container sind keine virtuellen Maschinen

Ein Großteil der „soll ich virtualisieren"-Sorge verschwindet, sobald Sie Container von VMs trennen, denn es ist nicht derselbe Kompromiss. Ein LXC-Systemcontainer oder ein Docker-Container teilt sich den Kernel des Hosts. Es gibt keinen Gast-Kernel, keine virtuelle Hardware und keine vCPU-Scheduling-Schicht zwischen Ihrem Prozess und dem Core. Das bedeutet, es gibt praktisch keine Steal-Time und keinen Timer-Virtualisierungs-Jitter: Ein containerisierter Gameserver auf Bare Metal läuft mit im Wesentlichen nativer Geschwindigkeit, mit einer cgroup, die begrenzt, wie viel CPU und Speicher er nutzen darf. Der Overhead ist ein Rundungsfehler.

Also erfordert „ich möchte mehrere isolierte Gameserver auf einer Maschine betreiben" keine VMs. Container geben Ihnen Ressourcenlimits pro Server, ordentliche Verpackung und nahezu native Performance auf demselben Kernel, genau das, was ein Gaming-Panel wie Pterodactyl im Hintergrund macht. Die Kompromisse, die es tatsächlich gibt (schwächere Isolation als eine VM, ein gemeinsamer Kernel, keine Live-Migration), betreffen Sicherheit und Betrieb, nicht die Tick-Performance, und wir behandeln sie vollständig in LXC vs. KVM in Proxmox. Für reine Gameserver-Performance ist ein Container auf Bare Metal die nahezu native Option; eine VM ist diejenige, die die Scheduling-Schicht hinzufügt, um die es in diesem ganzen Artikel geht.

Wann eine VM die richtige Wahl ist

Virtualisierung ist nicht der Feind; Overcommitment ist es. Es gibt echte Fälle, in denen eine VM das richtige Werkzeug ist, und sie teilen ein Merkmal: Sie kontrollieren die Konkurrenz.

• Dev-, Staging- und Testserver. Niemandes kompetitives Erlebnis hängt vom p95-Tick einer Staging-Maschine ab. Setzen Sie VMs auf, so viel Sie wollen; die Isolation und der Komfort von Snapshots sind mehr wert als die letzten paar Millisekunden.
• Kleine oder Casual-Server. Ein Survival-Server für Sie und ein Dutzend Freunde verbringt die meisten Ticks weit innerhalb des Budgets. Da ist so viel Spielraum, dass der Overhead des Hypervisors nie zum Engpass wird, und eine bescheidene VM ist völlig in Ordnung.
• Eine VM auf Ihrem eigenen Hypervisor. Das ist die wichtige. Wenn Sie eine ganze Bare-Metal-Maschine mieten und Ihren eigenen Hypervisor darauf betreiben, entscheiden Sie, wie viele Gäste sich die Cores teilen und ob sie überbucht sind. Pinnen Sie die Game-VM an dedizierte Cores, committen Sie nicht über, und Sie bekommen den größten Teil der Flexibilität von Virtualisierung mit Steal-Time, die Sie selbst kontrollieren, statt Steal-Time, die Ihnen Ihr Host aufzwingt. Der Unterschied zwischen diesem Fall und einem billigen VPS dreht sich vollständig darum, wer die Overcommitment-Entscheidung trifft.

Die Konstellation, die Sie bei allem Vielbeschäftigten oder Kompetitiven vermeiden sollten, ist die, bei der jemand anders diese Entscheidung für Sie getroffen und dabei aggressiv kalkuliert hat.

Falls Sie virtualisieren müssen: Tuning, das hilft

Bei einer VM auf Hardware, die Sie selbst kontrollieren, holen ein paar Einstellungen den größten Teil der verlorenen Worst-Case-Performance zurück:

• vCPUs an physische Cores pinnen. CPU-Pinning (vcpupin in libvirt) bindet die vCPUs der Game-VM an bestimmte physische Cores, sodass der Scheduler sie nicht mehr hin- und herspringen lässt. Das reduziert Jitter und verbessert das Cache-Verhalten. Teilen Sie diese gepinnten Cores nicht mit anderen Gästen.
• Das Host-CPU-Modell verwenden. Stellen Sie den Gast auf host-passthrough (oder mindestens host-model), damit die VM die echte CPU und ihren vollen Befehlssatz sieht, statt ein Modell nach dem kleinsten gemeinsamen Nenner, das Leistung verschenkt.
• Die Cores, auf die es ankommt, nicht überbuchen. Ordnen Sie der Game-VM vCPUs im Verhältnis zu echten Cores zu, und halten Sie die insgesamt zugesagten vCPUs bei oder unter der Zahl der physischen Cores, wenn Tick-Stabilität wichtig ist. Die Dichte, auf die Sie verzichten, ist die Latenz, die Sie behalten.
• Ballooning für die Game-VM deaktivieren. Geben Sie ihr eine feste Speicherreservierung, damit der Host mitten im Match keinen RAM zurückfordern kann. Lassen Sie Ballooning bei Gästen zu, die das vertragen können.
• Die schnellen NIC- und Disk-Pfade beibehalten. Nutzen Sie virtio mit vhost-net, und legen Sie den Spielzustand auf NVMe. Die Dimensionierungsseite davon steht im Sizing-Guide für Server, der auch für weniger, schnellere Cores statt vieler langsamer plädiert.

Nichts davon lässt eine VM Bare Metal schlagen. Es schließt die Lücke bis zu dem Punkt, an dem der Unterschied auf einer Maschine, die Sie selbst kontrollieren, für die meisten Server aufhört, eine Rolle zu spielen.

Das Urteil, je nach Situation

Latenz ist die andere Hälfte von „fühlt sich gut an", und dabei geht es vor allem um Geografie und Routing, nicht um die Frage Bare Metal gegen VM; der Leitfaden zur Gameserver-Latenz behandelt diese Seite.

Deployment bei Serverside

Wenn der Workload kompetitiv oder stark frequentiert ist, zeigt das Argument von oben in eine Richtung: die ganze Maschine, ohne Hypervisor zwischen Ihrer Tick-Loop und den Cores. Ein Serverside-Gameserver ist Single-Tenant Bare Metal in unserem eigenen Netzwerk (AS55285), es gibt also keine Steal-Time, keine störenden Nachbarn und kein Overcommitment, das jemand anders als Sie festlegt. Die Bereitstellung dauert unter einer Minute, und immer aktive DDoS-Mitigation sitzt vor der öffentlichen Schnittstelle, was bei einem Gameserver keine Option, sondern Pflicht ist. Wenn Sie lieber selbst eine Maschine in VMs aufteilen möchten, wird das auch unterstützt: Mieten Sie die dedizierte Hardware, betreiben Sie Ihren eigenen Hypervisor, und Sie kontrollieren jede Konkurrenzentscheidung, auf die Sie dieser Artikel hingewiesen hat.

Häufig gestellte Fragen

Fügt eine VM einem Gameserver immer Lag hinzu?

Nein. Eine VM auf Hardware, die Sie selbst kontrollieren, mit gepinnten vCPUs und ohne Overcommitment, fügt so wenig Overhead hinzu, dass die meisten Server es nie bemerken. Der Lag, den Leute der „Virtualisierung" anlasten, kommt fast immer vom Overcommitment und nicht vom Hypervisor selbst: ein geteilter VPS, bei dem Ihre CPU-Zeit von der Auslastung anderer Mieter abhängt. Der zugrunde liegende Mechanismus ist CPU-Steal-Time, und Sie können sie direkt messen.

Was ist CPU-Steal-Time, und ab welchem Wert wird es schlecht?

Steal-Time (%st in top) ist der Prozentsatz der Zeit, in der Ihre virtuelle CPU laufbereit war, aber warten musste, bis der Host ihr einen physischen Core zuteilte. Auf Bare Metal ist sie immer null. Bei einer gesunden VM bleibt sie nahe null. Eine gängige Faustregel besagt, dass anhaltende Steal-Time über 10 Prozent bedeutet, dass der Gast langsamer läuft, als er sollte, und bei einem Gameserver mit fester Tickrate zeigen sich schon wenige Prozent als langsame Ticks.

Warum ruckelt mein VPS-Gameserver, obwohl die CPU-Auslastung niedrig aussieht?

Weil die CPU-Auslastung innerhalb des Gasts keine Konkurrenz auf dem Host zeigt. Ihr Server kann bei 30 Prozent CPU liegen und trotzdem Ticks verpassen, wenn der Host Ihre virtuelle CPU immer wieder warten lässt; diese verlorene Zeit erscheint als Steal-Time, nicht als Auslastung. Prüfen Sie die st-Spalte in top oder vmstat 1. Hohe Steal-Time bei niedriger Auslastung ist das klassische Erkennungsmerkmal eines überbuchten VPS.

Sind Container für die Gameserver-Performance besser als VMs?

Bei reiner Performance: ja. Ein Docker- oder LXC-Container auf Bare Metal teilt sich den Kernel des Hosts, es gibt also keine vCPU-Scheduling-Schicht und keine Steal-Time, und er läuft nahezu nativ. VMs bieten stärkere Isolation und Funktionen wie Live-Migration, die Container nicht haben. Bei der Tick-Performance schlägt ein Container auf Bare Metal eine VM; bei der Isolation nicht vertrauenswürdiger Mieter gewinnt die VM. Unser Vergleich LXC vs. KVM zeigt den vollständigen Kompromiss.

Wie messe ich, ob Virtualisierung meinem Server schadet?

Zwei Zahlen. Für Steal-Time führen Sie top, vmstat 1 oder mpstat -P ALL 1 aus und lesen die Spalte st oder %steal. Für die Tick-Gesundheit unter Minecraft installieren Sie den Spark-Profiler und führen /spark tps aus, wobei Sie auf die MSPT im 95. Perzentil achten, nicht auf den Durchschnitt. Auf Source- und CS2-Servern meldet der Befehl stats einen fps-Wert, der die Tickrate widerspiegelt. Steigen Steal-Time und die Tick-Zeit im 95. Perzentil gemeinsam an, liegt das Problem beim Host.