Um eine Baseline zu haben, habe ich mal eine Messung auf der Dust2-Benchmark-Map mit CapFrameX gemacht.
Mein System besteht aus einem AMD 9800x3d, 32GB 6000MHz CL28 RAM und einer NVidia 5090.
Meine Oldschool-Einstellungen waren:
- GSync off
- VSync off
- Reflex enabled
- kein Frame-Limit
Bei dieser Option erreicht man zwar 932 FPS, aber diese sind alles andere als stabil. Diese Schwankungen machen sich auch mit einem ungleichmässigen Input-Lag bemerkbar.
-noreflex & NVidia Frame Limiter
Mit der Launch-Option -noreflex und einem Frame-Limit von 550FPS im Nvidia-Control-Panel haben sich die 1% Lows von 261 FPS auf 483 FPS verbessert.
Hierzu ist die Anleitung einfach: Starte mit einem FPS-Wert im Limiter, welcher ca. 10% niedriger ist, als Deine Durchschnitts-FPS im Spiel. Gehe dann in 10FPS-Schritten nach unten, bis zu Du den Wert hast, bei dem Du die höchsten 1% Lows messen kannst.
Die Methode zeigt die stabilste Framerate und wird von vielen Spielern genutzt, da sie gleichmässig den gleichen Input-Lag bietet.
Die Empfehlung von Valve: GSync & VSync
Beim Start von CS2 erhält man eine Empfehlung von Valve, man soll GSync, VSync und Reflex aktivieren. Daher habe ich auch diesen Einstellungen eine Chance gegeben.
Auch diese Option bietet 1% Lows in einem akzeptablen Rahmen – sie sind jedoch niedriger als bei der Noreflex-Option.
Und wie steht es um die Input-Latenz?
Thour auf X hat geschrieben, dass er wieder mit Reflex spiele, da die Latenz besser sei. Da ich über ein LDAT verfüge, habe ich mir gedacht, ich mache mal ein paar Messungen.
Map: Aim Botz, lokaler Server
Im Gegensatz zu den Messungen mit CapFrameX haben wir hier echte Daten von einem spürbaren Wert: Die Latenz einer Mausbewegung (Klick), bis diese auf dem Monitor sichtbar wird.
Resultate
Offenbar sind die folgenden beiden Optionen die besten:
- Reflex+Boost (ohne GSync&VSync oder Frame-Limiter)
- -noreflex mit dem NV Frame-Limiter
Etwas schlechter ist die Option von GSync&VSync, die Valve empfiehlt.
Zwischenresultat
Ich will nicht sagen, dass dieser Post vollständig ist, denn die Daten wurden alle auf dem «localhost» erhoben. Daher werde ich bald die 3 genannten Optionen auch auf einem Deathmatch-Server testen. Erste Experimente haben gezeigt, dass die 1% Lows um einiges niedriger sind, wenn man auf offiziellen Valve-Servern spielt. Zudem basieren die Angaben auf nur 20 Messungen auf einer Map, die ohnehin sehr viele FPS bringt.
Update – Deathmatch
Ich habe nun die erste Messung mit CapFrameX auf einem offiziellen Valve-Server erstellt. Die Einstellungen sind:
- GSync & VSync on
- Reflex on+Boost
- kein Frame-Cap
Die 1% Lows sind also von 447 FPS auf 240 FPS gesunken. Noch schlimmer steht es um die 0.1% Lows, welche von 300 auf 92.3 FPS gesunken sind.
Deathmatch -noreflex & NVidia Frame Limiter
Auch das habe ich natürlich gemessen:
Wie beim Testen auf dem «localhost», ist auch im Deathmatch diese Variante etwas besser, wenn man möglichst hohe 1% Lows haben möchte.
Und wie steht es um die Input-Latenz im Deathmatch?
Viele gute Spieler behaupten, dass sich -noreflex mit Frame-Cap besser anfühlen soll. Nun, hier die Resultate der Messung – unter dem Abschnitt «Deathmatch (Valve)»:
Zumindest in meinem kleinen Test hat hier -noreflex mit dem NVidia-Frame-Limiter eindeutig die besseren Resultate als Reflex on+Boost geliefert.
HPET Settings für CS2
Den HPET (High Precision Event Timer) zu deaktivieren, ist einer der bekanntesten Tweaks für CS2. Selbst Faceit empfiehlt dies, um die Performance von CS2 auf Ryzen-CPUs zu verbessern.
Ich habe früher die Einstellung auch einfach blind übernommen – wobei das Deaktivieren vom High Precision Event Timer im Gerätemanager keinen Effekt hat, denn wirklich deaktivieren kann man HPET nur über bcdedit.
Dazu öffnest Du CMD mit Admin-Rechten:
Dann deaktivierst Du HPET indem Du den Befehlt: bcdedit /deletevalue useplatformclock verwendest. Damit verwendest Du dann den TSC Clock.
(Mit bcdedit /set useplatformclock yes kannst Du HPET/Plattform-Clock wieder erzwingen.)
Nun gibt es noch 2 Optionen, nämlich den TSC-Tick (synthetisch, modern, wenig Interrupt-Overhead) oder den Plattform-Tick (erzwingt periodische Interrupts vom Plattform-Timer). Mit dem Befehl bcdedit /deletevalue useplatformtick wird der TSC-Tick verwendet.
So kann man auch TSC Clock + RTC Tick aktivieren, was aber eine zusätzliche Interrupt-Last bringt und theoretisch eher einen negativen Einfluss auf die DPC-Latenzen bringen müsste.
Ich habe aber die beiden Einstellungen mal innerhalb von CS2 gemessen und bin auf folgende Werte gekommen:
TSC Clock + RTC Tick bringt 0,3ms bessere Latenzen als TSC Clock + TSC Tick. Das klingt nach wenig, ist aber bei meinen 540Hz (Ein Frame dauert ≈ 1.85 ms, d. h. 0.3 ms ≈ 16 % eines Frames) eine enorme Verbesserung. Also sprich, so erzwingst Du TSC Clock + RTC Tick:
bcdedit /deletevalue useplatformclock
bcdedit /set useplatformtick yes
Im Zweifelsfall: Bleib bei TSC clock + TSC tick. Das ist der Windows-Standard und liefert in der Regel die niedrigste Latenz bei stabiler Frametime. QPC (QueryPerformanceCounter) via TSC ist explizit von Microsoft so designt/empfohlen; Plattform-Ticks sind laut MS nur für Debugging gedacht.
Mehr Informationen über die HPET-Settings findest Du auf xbitlabs.com.
tscsyncpolicy enhanced vs. legacy
Da bei mir bcdedit /set useplatformtick yes einen Vorteil von 0.3ms bringt, gehe ich von nun an von diesen Settings aus. Eine weitere Möglichkeit ist die TSCSyncPolicy zu definieren. Standardmässig wählt Windows selbst zwischen «legacy» oder «enhanced». Da ich aber gerade im Messfieber bin und hier oft bcdedit /set tscsyncpolicy legacy empfohlen wird, möchte ich auch diese beiden Werte messen.
Dazu muss ich nun noch die Werte mit bcdedit /set tscsyncpolicy enhanced messen, denn die Werte von bcdedit /set tscsyncpolicy legacy habe ich bereits bei den Timer Settings erhoben:
Leistung: realistisch betrachtet (robuste Masse) ist enhanced ca. 0,4–0,5 ms schneller als legacy.
Konstanz: im mittleren Bereich streut enhanced weniger (kleinerer IQR). Die scheinbar höhere Gesamt-Varianz kommt praktisch nur vom einem Ausreisser.
Was heisst das nun für mich und Dich?
bcdedit /deletevalue useplatformclock
bcdedit /set useplatformtick yes
bcdedit /set tscsyncpolicy enhanced
Das sind die bcdedit-Settings für die beste Latenz!
Für den Alltag würde ich jedoch eher
bcdedit /deletevalue useplatformtick
bcdedit /deletevalue tscsyncpolicy
empfehlen, da die obengenannten Einstellungen eher für Debugging gedacht sind und vielleicht Probleme mit anderen Anwendungen bringen könnten.
