CS2 Latency Testing: Wie ich Input-Lag wirklich gemessen habe

Was dieser Beitrag ist: ein Mess-Protokoll, kein Gaming-Ratgeber. Ich beschreibe, wie ich auf einem konkreten PC die Frame-Stabilität und Eingabe-Latenz von Counter-Strike 2 (CS2) gemessen habe, was die Werkzeuge können, was ihre Grenzen sind, und welche kleinen Schlüsse sich daraus ziehen lassen. Wer eine Checkliste «installiere X für mehr FPS» sucht, ist hier falsch. Wer verstehen will, wie man so etwas methodisch sauber misst, hoffentlich richtig.

Was er nicht ist: keine universelle Empfehlung. Mein System ist eine Konfiguration; jede andere Hardware, jede andere Treiber-Version und jeder andere Monitor verändert die Messung. Übernimm keine bcdedit-Setzung blind. Bei manchen Setups bringt sie nichts, bei anderen ist sie sogar kontraproduktiv.

Setup

Wichtig: das ist eine Konfiguration. Bei einem System mit weniger CPU-Headroom verhalten sich Frame-Limiter anders, und ein 240-Hz-Monitor hat ganz andere Latenz-Spielräume als 540 Hz.

Was die Werkzeuge messen – und was nicht

Bevor Zahlen kommen, die wichtigste Unterscheidung:

CapFrameX misst, wie schnell und wie gleichmässig die Engine Frames produziert. Es zeigt FPS, Frame-Time-Verteilung, 1 %- und 0.1 %-Lows. Es zeigt nicht die Eingabelatenz, die Du als Spieler tatsächlich fühlst. Hohe Average-FPS bei wackeligen Frame Times fühlen sich oft schlechter an als niedrigere, aber stabile FPS – genau das ist der Grund, warum CS2 trotz hoher FPS schwammig wirkt.

LDAT misst dagegen die Click-to-Photon-Latenz: vom physischen Mausklick (LDAT klemmt einen Sensor an die Maus und löst aus) bis zu dem Moment, an dem das resultierende Pixel auf dem Monitor leuchtet (LDAT misst per Photodiode). Das ist der Wert, der das Spielgefühl bestimmt. Aber: LDAT misst kein Netzwerk-Verhalten; auf einem realen Server kommt Netzwerk-Latenz zu LDAT-Werten dazu.

Wer nur eines der beiden Tools nutzt, hat ein halbes Bild.

Baseline auf der Dust2-Benchmark

Erste Messung mit CapFrameX, Engine-Settings:

• GSync: off
• VSync: off
• Reflex: enabled
• Frame-Limit: keiner

Die hohe Durchschnittsrate ist kein Qualitätssiegel. Die 1 %-Lows liegen bei 261 FPS – das heisst, die schlechtesten 1 % der Frames brauchen deutlich länger als die anderen. Subjektiv fühlt sich das ungleichmässig an.

Variante 1: -noreflex + NVIDIA Frame-Limiter

CS2 Launch-Option -noreflex, externer Frame-Limiter im NVIDIA Control Panel auf 550 FPS.

Der Trick ist nicht «mehr FPS», sondern gleichmässigere Frame Times. Ein extern auferlegtes Limit sorgt dafür, dass die GPU nicht in Stoss-Spitzen rennt, in denen sie kurz vor dem Throttle die Pipeline überfüllt. Die Methode aus der Mess-Forenkultur:

1. Starte mit einem Limit ca. 10 % unter der durchschnittlichen FPS im Spiel.
2. Senke das Limit in 10-FPS-Schritten.
3. Bleib bei dem Wert, bei dem die 1 %-Lows am höchsten sind.

Wichtig: Das ist eine Frame-Stabilitäts-Optimierung, keine Latenz-Optimierung. Ob das auch die Click-to-Photon-Latenz verbessert, hängt vom System ab und braucht eine LDAT-Messung.

Variante 2: Valve-Empfehlung – GSync + VSync + Reflex

Beim ersten Start von CS2 empfiehlt Valve GSync + VSync + Reflex. Das ist die Kombination, die Adaptive-Sync-Tearing vermeidet und gleichzeitig den GSync-typischen Latenz-Penalty durch Reflex kompensiert.

Reine Frame-Werte sind nicht alles. LDAT-Messungen für die drei Varianten folgen.

End-to-End-Latenz mit LDAT (Aim Botz, localhost)

Auf der Aim-Botz-Map gegen einen lokalen Server, ~ 20 Messungen pro Variante:

• Reflex + Boost (ohne GSync/VSync, ohne externen Limiter): die niedrigste Latenz.
• -noreflex + NVIDIA Frame-Limiter (siehe oben): praktisch gleichwertig, im Rahmen der Mess-Streuung kein klar besserer oder schlechterer Wert.
• GSync + VSync + Reflex (Valve-Empfehlung): messbar etwas höher, aber im akzeptablen Bereich.

Mein Take: Wer Reflex sauber einsetzt und keinen externen Limiter braucht, hat eine saubere Konfiguration. Wer den externen Limiter aus Frame-Time-Gründen will, verliert dabei keine spürbare Latenz – solange die anderen Settings stimmen.

Was im Deathmatch passiert

Lokale Messungen sind das eine. Auf einem Valve-Deathmatch-Server wird der Vergleich brutaler:

Die Kollision mit Netzwerk-, Server-Tick- und Memory-Verkehr hebelt einen Teil der lokalen Optimierung aus. Auch hier zeigte sich, dass -noreflex + Limiter die 1 %-Lows online stabiler hält als die GSync-Kombination – mit dem üblichen Caveat: eine Map, ein Spielmoment, eine Server-Auslastung. Ein vollständiges Bild bräuchte hunderte Messungen über verschiedene Tageszeiten und Server.

HPET, bcdedit und der Plattform-Timer

Das ist die Sektion, die im Internet als Heilsversprechen kursiert – «deaktiviere HPET im BIOS und gewinne 5 ms». Die nüchterne Antwort:

HPET (High Precision Event Timer) ist ein hardwareseitiger Timer. Modernere Windows-Systeme nutzen standardmässig den TSC (Time Stamp Counter) der CPU, weil der niedrigere Interrupt-Last hat. Im Geräte-Manager kann man HPET «deaktivieren», aber das ist Theater: Windows nutzt HPET sowieso nicht als Hauptzeitgeber, wenn TSC verfügbar ist. Was wirklich umschaltet, ist bcdedit.

Die zwei Achsen, die Windows erlaubt:

• Plattform-Clock (useplatformclock) — gibt vor, ob Windows die HPET als Hauptuhr erzwingt.
• Plattform-Tick (useplatformtick) — gibt vor, ob die periodischen Tick-Interrupts vom Plattform-Timer kommen oder ob der TSC-Tick verwendet wird.

In der Regel sind beide nicht gesetzt (also Windows-Default = TSC Clock + TSC Tick) die richtige Wahl. Microsoft selbst beschreibt diese Architektur und empfiehlt explizit, die bcdedit-Schalter nur für Debugging zu setzen.

Was ich gemessen habe – und nur bei meinem Setup:

• TSC Clock + TSC Tick (Windows-Default): Referenz.
• TSC Clock + RTC Tick (bcdedit /deletevalue useplatformclock + bcdedit /set useplatformtick yes): bei meinen Messungen ca. 0.3 ms niedrigere LDAT-Latenz.

Bei einem 540-Hz-Monitor sind 0.3 ms etwa 16 % eines Frames. Das ist messbar, aber im Alltag nur schwer als «fühlbar» einzuordnen. Wer kein Mess-Equipment hat, wird das nicht spüren. Wer sehr ehrgeizig ist, wird 0.3 ms gerne mitnehmen.

Zur Einordnung: diese Setzungen sind für Debugging gedacht. Sie können andere Anwendungen beeinflussen (Audio-Treiber, Virtualisierungssoftware, Video-Capture). Eine pauschale «das macht alles schneller»-Empfehlung ist hier explizit falsch.

tscsyncpolicy: enhanced vs. legacy

Eine weitere Stellschraube: bcdedit /set tscsyncpolicy enhanced vs. legacy. Standardmässig wählt Windows eigenständig, je nach CPU.

In meinen Messungen war enhanced gegenüber legacy im Median ungefähr 0.4 bis 0.5 ms schneller, mit etwas geringerer Streuung im mittleren Bereich. Das deckt sich mit der Erwartung – auf modernen CPUs ist der TSC sauber synchron über die Cores; «legacy» ist eher für ältere Architekturen gedacht. Wieder: bei anderer Hardware oder unter VM-Betrieb kann das Resultat anders aussehen.

Kombiniert ergeben sich also für mein Setup als latenz-optimal:

bcdedit /deletevalue useplatformclock
bcdedit /set useplatformtick yes
bcdedit /set tscsyncpolicy enhanced

Für den Alltag würde ich aber eher die konservativere Variante nehmen:

bcdedit /deletevalue useplatformclock
bcdedit /deletevalue useplatformtick
bcdedit /deletevalue tscsyncpolicy

Das ist wieder Windows-Default und in der Regel die Variante mit der niedrigsten Latenz bei stabilster Frametime und ohne Nebenwirkungen.

Was diese Messung nicht zeigt

• Keine Generalisierung auf andere Systeme. CPU-Generation, GPU-Treiberversion, Monitor-Refresh, Maus-Polling, USB-Topologie und Hintergrundprozesse beeinflussen alle drei Werte (FPS, 1 %-Lows, LDAT). Übernimm meine Settings nicht 1:1.
• Keine Aussage über kompetitives Skill-Niveau. Eine 0.3-ms-Verbesserung der Latenz macht keinen mittelmässigen Spieler zu einem guten. Reproduzierbares Aiming, Map-Awareness und Crosshair-Placement haben für die Endgame-Performance einen vielfach grösseren Effekt.
• Keine Aussage über Server-Verhalten. Tick-Rate, Server-Auslastung und Netzcode hebeln einen Teil der lokalen Optimierung wieder aus.
• Keine Bestätigung von Internet-Tweak-Mythen. «Deaktiviere die Service XYZ» ohne Begründung ist Volkstheater. Was nicht in einem Mess-Setup wiederholbar ist, sollte man auch nicht propagieren.

Was ein Leser mitnehmen kann

Drei methodische Prinzipien, die robuster sind als jede konkrete Setting-Empfehlung:

1. Frame-Stabilität ≠ Average-FPS. Schau auf 1 %-Lows und 0.1 %-Lows, nicht auf den Average-FPS-Balken im OSD.
2. Frame-Stabilität ≠ Latenz. Wer Eingabelatenz wirklich kennen will, braucht ein dediziertes Tool wie LDAT. CapFrameX allein reicht dafür nicht.
3. Wer nicht misst, soll nicht behaupten. Internet-Tweaks ohne Mess-Belege sind keine guten Quellen. Auch dieser Beitrag ist nur die Messung eines Setups – mit allen Caveats, die das hat.

Quellen und Einordnung

• Microsoft Learn – Acquiring high-resolution time stamps – offizielle Dokumentation zu HPET, TSC, QPC und den bcdedit-Schaltern.
• NVIDIA Reflex – How It Works – technische Beschreibung der Reflex-Pipeline.
• NVIDIA Reflex Latency Analyzer & 360 Hz G-SYNC Monitors – Mess-Tool, das Click-to-Photon misst.
• CapFrameX – Open-Source-Tool für Frametime-Analysen.
• Threads aus der Reflex- und CS2-Performance-Community waren mir als Sparring nützlich. Sie sind aber keine Quellen, die ich für allgemeine Empfehlungen heranziehen würde.

Wer LDAT-Rohdaten oder die Original-CapFrameX-Sessions verlangt, soll ehrlich gefragt werden: ich habe sie für mich, aber ich teile sie nicht öffentlich – sie sind Teil meines persönlichen Mess-Setups und nicht für Benchmarks gegenüber anderen System-Konfigurationen geeignet. Wer Tabellen mit «meine Zahlen sind besser als Marcs» bauen will, soll selbst messen.

Verwandte Einordnung: Latenz, FPS und Aim Leaks

Dieser Artikel ist das Mess-Protokoll – eine Konfiguration, eine Reihe Werte, viele Caveats. Wer den Kontext drumherum sucht, findet ihn auf drei Nachbarseiten:

• Wer erst verstehen will, warum hohe FPS sich trotzdem schlecht anfühlen können, liest Warum fühlt sich CS2 trotz hoher FPS schlecht an?.
• Wer verstehen will, warum Average FPS irreführt und 1 %-Lows ehrlicher sind, liest Average FPS lügt.
• Wer Systemproblem und mechanisches Problem trennen will, liest Input Lag vs. Aim Leak.

Diese drei Beiträge ergänzen das Protokoll hier methodisch, ersetzen es aber nicht.

Warum das mit nextfrag.gg zusammenhängt

Diese Mess-Notiz steht inhaltlich nicht allein. Sie gehört zum Umfeld des Projekts Nextfrag – einer CS2-Initiative rund um Performance, Latenz und reproduzierbare Optimierung. Auf der Projektseite ist beschrieben, worum es bei Nextfrag geht, warum die übliche FPS-Folklore methodisch zu kurz greift und welchen Anteil ich als Konzept- und Mess-Person an der inhaltlichen Seite habe. Wer den Beitrag hier als Ausschnitt lesen will, findet dort die Einordnung – und den Link zur Plattform selbst.

Verwandte Beiträge

• Nextfrag (Projektseite) – CS2-Performance, Latenz und reproduzierbare Messung als Projektkontext.
• Empirische Forschung – warum Mess-Methodik vor Mess-Ergebnissen kommt.
• Human-Centered Design – wie man Werkzeuge an Menschen anpasst, statt umgekehrt.
• Anpassung an die Umwelt – warum «optimal» immer eine Funktion des Kontexts ist.
• Marketing-Pillar – andere Beiträge zu Strategie, Messung und Methode.