Input Lag vs. Aim Leak: Warum nicht jede verpasste Kugel am Setup liegt

«CS2 fühlt sich off an» ist keine Diagnose, sondern ein Gefühl. Verlorene Duelle landen reflexartig in der Schublade «Input Lag», und der nächste Reflex ist meistens, im Nvidia Control Panel herumzudrehen oder einen weiteren bcdedit-Tweak aus einem Forum zu kopieren. Manchmal ist das System tatsächlich das Problem, und CS2 fühlt sich trotz hoher FPS schlecht an, weil Frame Times oder Latenz nicht stimmen. Sehr oft ist es das aber nicht – sondern ein wiederkehrender Mechanikfehler: zu spät stehen geblieben, zu tief vor­gehalten, zu früh den Spray verlängert, zu inkonsistent gezielt. So ein Muster heisst hier Aim Leak, und es lässt sich nicht durch Treiber-Optionen wegklicken.

Diese These ist die Grundlage des Beitrags: Bevor Du Settings änderst, lohnt es sich zu trennen, ob die verpasste Kugel an der Hardware-Pipeline lag oder an der Hand. Beides braucht andere Werkzeuge, andere Daten und andere Massnahmen.

Was Input Lag wirklich bedeutet

Input Lag ist kein einzelner Wert, sondern eine Kette. Vom Mausklick bis zum leuchtenden Pixel laufen mehrere Stationen ab: Maus-Sensor, USB-Polling, Betriebssystem, Spiel-Engine, GPU-Render-Queue, Display-Pipeline, Panel-Response. Jede dieser Stationen kostet Zeit, und jede kann unter Last zucken.

Was Spieler oft vermischen: System-Latenz und Netzwerk-Latenz. System-Latenz ist die Click-to-Photon-Zeit auf der lokalen Maschine. Netzwerk-Latenz ist alles, was zwischen Deinem PC und dem Server passiert – Tickrate, Routing, Server-Auslastung. Beide Werte addieren sich, aber sie haben unterschiedliche Ursachen und unterschiedliche Hebel. Wer nur auf «Ping» schaut, sieht die System-Seite gar nicht; wer nur die System-Seite optimiert, ignoriert, dass der Valve-Deathmatch sich anders anfühlt als die lokale Aim-Botz-Map.

Eine technische Fallstudie, in der diese Trennung an einem konkreten Setup gemessen wurde, liegt unter CS2 Latency Testing. Sie ist bewusst kein Ratgeber, sondern ein Mess-Protokoll – mit den Caveats, die zu jeder einzelnen Konfiguration gehören.

Was ein Aim Leak ist

Ein Aim Leak ist nicht ein einzelner verfehlter Schuss. Ein einzelner Whiff ist Statistik, kein Diagnoseinstrument. Ein Aim Leak ist ein wiederkehrendes mechanisches Muster, das in vergleichbaren Situationen reproduzierbar zu schlechteren Ergebnissen führt. Der Test ist immer derselbe: Sieht man das Verhalten in Demo-Aufnahmen über mehrere Runden, mehrere Maps und mehrere Sessions wieder?

Wenn ja, ist das Problem mechanisch. Wenn nein, war es ein Ausreisser, oder die System-Pipeline hat zu einem ungünstigen Moment gehustet. Diese Trennung ist mühsam, aber sie verhindert, dass man jeden verlorenen Aim-Duell auf eine ungünstige Bewegung des Maus-Polling-Sterns schiebt.

Typische Aim Leaks

Vier Muster tauchen besonders oft auf, und alle sind in Demos sichtbar:

• Counter-strafe zu spät. Bevor der Schuss fällt, müsste die Bewegung restlos gestoppt sein. Wer mitten im Loslassen schiesst, akzeptiert den engine­seitigen Spread-Penalty – die First-shot-Genauigkeit kollabiert. Das ist kein Latenzproblem, das ist Timing.
• Crosshair zu tief. Wer auf Hüfthöhe pre-aimt, weil die Map im Spawn so aussah, kommt bei einem Off-Angle in der Mitte zu spät. Die Korrektur kostet messbare Zeit – Zeit, die im Engagement entscheidet.
• First bullet daneben. Selbst bei korrektem Counter-strafe und Pre-aim verfehlen viele Spieler den ersten Schuss, weil sie minimal über- oder untertippen. Die zweite Kugel sitzt dann oft, aber das erste Bild gehört dem Gegner.
• Sensitivity overshoot oder undershoot. Eine zu hohe Sensitivity verleitet zum Überzielen; eine zu niedrige zum Nachziehen. Beides ist mit der Zeit eintrainierbar, aber inkonsistente Sens-Werte zwischen Sitzungen (anderer Mauspad-Bereich, andere Tisch­höhe, andere Tagesform) verschieben das Resultat.
• Spray zu früh verlängert. Wer bei einem 1-vs-1 mit AK auf grössere Distanz nicht tappt, sondern den Spray durchzieht, verschenkt Genauigkeit. Das ist Shot-Discipline, kein FPS-Problem.

Keiner dieser Punkte verschwindet durch Reflex, durch ein anderes Frame-Limit oder durch bcdedit.

Wie man Input Lag und Aim Leak trennt

Die Trennung ist methodisch, nicht intuitiv. Subjektives «das fühlt sich anders an» reicht nicht. Sinnvoll ist eine kleine Mess-Routine, die zwei Seiten parallel beleuchtet:

• Frame Times statt Average FPS. CapFrameX zeigt, ob die Engine gleichmässig produziert oder ob 1 %- und 0.1 %-Lows einbrechen. Wenn die Frame Times stabil sind, ist die System-Pipeline plausibel sauber. Wenn sie zappeln, liegt ein realer System-Verdacht vor. Eine ausführlichere Erklärung, warum die Durchschnittszahl verkürzt, steht unter Average FPS lügt.
• Click-to-Photon, falls verfügbar. Mit dem NVIDIA Reflex Latency Analyzer lässt sich die End-to-End-Latenz messen. Ohne LDAT bleibt das Schätzwerk – Reflex selbst wurde bei der CS2-Veröffentlichung von Nvidia dokumentiert, aber die spürbare Auswirkung hängt vom restlichen Setup ab.
• Demo-Analyse für Mechanik. Eigene Demos sind die einzige ehrliche Quelle für Aim Leaks. Wer die Counter-strafe-Frames, die Pre-aim-Höhe oder die First-shot-Genauigkeit nicht sehen will, repariert sie nicht. Werkzeuge wie der Demo Analyzer von NextFrag zerlegen genau diese Punkte – mit den bekannten Grenzen einer Demo-Auswertung.
• Netzwerk separat betrachten. Hohe Server-Last oder asymmetrisches Routing verändern das Bild. Ein lokaler Test gegen localhost und ein Test auf einem Online-Server sind nicht dieselbe Messung; das Mess-Protokoll im Latenz-Beitrag zeigt, wie deutlich die Differenz wird.

Erst aus dieser Kombination ergibt sich eine Antwort, ob das Problem System oder Mechanik ist. Wer nur ein einziges Werkzeug nutzt, hat nur ein halbes Bild – und das halbe Bild hat schon viele Stunden im Nvidia Control Panel ge­kostet, ohne dass der nächste Match-Win näher gerückt wäre.

Wann Settings tatsächlich helfen

Settings helfen, wenn die Messung sie verlangt. Konkret: wenn die Frame Times unter Last instabil sind, wenn die 1 %-Lows in der Deathmatch-Realität einbrechen, wenn die Click-to-Photon-Latenz über mehrere Runs reproduzierbar zu hoch liegt – dann lohnt sich ein gezielter Eingriff. Reflex sauber gesetzt, ein FPS-Limit unterhalb der GPU-Spitze, eine Display-Pipeline ohne überflüssige Sync-Schichten: alles legitime Stellschrauben.

Was nicht hilft: pauschale Tweak-Listen, die ein Setting für alle Setups behaupten. Eine Konfiguration, die auf einem System mit viel CPU-Headroom funktioniert, kann auf einem System ohne Headroom kontraproduktiv sein. Der Latenz-Beitrag macht diesen Punkt nüchtern – einschliesslich der Stellen, an denen ein bestimmter bcdedit-Schalter nur 0.3 ms brachte und in einem anderen Kontext null Effekt gehabt hätte.

Wann Demo-Analyse hilft

Demo-Analyse hilft, sobald die System-Seite nicht das offensichtliche Problem ist – oder wenn Du gar nicht erst weisst, ob es das ist. Sie hilft auch, wenn Du Dein Spielgefühl bewusst trainieren willst, statt es nur zu erleiden.

Konkret: Wenn die Frame Times sauber laufen, die Click-to-Photon-Latenz im Bereich des Setups ist und Du trotzdem Duelle verlierst, ist der nächste Schritt nicht ein weiterer Treiber-Switch. Der nächste Schritt ist, fünf eigene Demos anzu­schauen und nach Mustern zu suchen: Wo war die Counter-strafe nicht sauber? Wo lag das Crosshair zu tief? Wo war der erste Schuss daneben? Tools wie Counter-strafe-Analyse, Crosshair-Placement oder First-Bullet-Accuracy machen aus diesem Eindruck eine Zahl. Eine Zahl, die man trainieren kann.

Methodisch ist das übrigens kein CS-spezifisches Phänomen. Wer Marktforschung in der eigenen Disziplin betrieben hat, kennt das Muster: ohne sauber definierte Hypothese und ohne Mess-Setup wird jede Optimierung zur Vermutung. Mehr dazu in Empirische Forschung – Vor- und Nachteile und im Projekt­hinter­grund unter Nextfrag.

Eine dritte Schicht bleibt in diesem Beitrag bewusst aussen vor: der Zustand des Spielers selbst — Tilt, Müdigkeit, Druck. Sie verändert Demos genauso wie ein System-Engpass oder ein Aim Leak, nur eben über andere Mechanismen. Wer Demo-Daten auswerten will, ohne diese Variable mitzudenken, kommt schnell zu falschen Schlüssen. Die saubere Trennung zwischen Mechanik und Player State steht unter CS2 Tilt oder Aim Leak.

Fazit

Erst messen, dann schrauben. Sonst ist es Voodoo mit Nvidia Control Panel. Ein Aim Leak verschwindet nicht durch Reflex; ein Pipeline-Problem verschwindet nicht durch mehr Aim-Botz-Stunden. Die saubere Reihenfolge ist banal und unbequem: Frame Times prüfen, Click-to-Photon prüfen (wenn möglich), Demos prüfen, dann entscheiden. Wer diese Reihenfolge umdreht, optimiert lange das falsche Problem.

Quellen und Einordnung

• Microsoft Learn – Acquiring high-resolution time stamps – Hintergrund zu HPET, TSC und der Zeitgeber-Architektur unter Windows.
• NVIDIA – Counter-Strike 2 Released Featuring NVIDIA Reflex – offizielle Beschreibung der Reflex-Integration in CS2.
• NVIDIA – Reflex Latency Analyzer & 360 Hz G-SYNC Monitors – Hardware-Tool zur Click-to-Photon-Messung.
• CapFrameX – Open-Source-Frametime-Analyse, hier für die Frame-Stabilitäts-Seite genutzt.
• NextFrag – CS2 Demo Analyzer und CS2 Demo Analysis: Limitations – Werkzeuge und Grenzen der Demo-Analyse, methodisch eingeordnet.
• NextFrag – Counter-strafe Analysis und First Bullet Accuracy – konkrete Mechanik-Metriken, die Aim Leaks sichtbar machen.

Caveat wie immer: kein einzelner Beitrag ersetzt eine eigene Messung. Was hier steht, ist Methodik, kein Versprechen.

CTA

Wenn Du die Systemseite prüfen willst, lies die Latenz-Fallstudie. Wenn Du wissen willst, ob Dein Problem mechanisch ist, analysiere eine Demo mit NextFrag – und vergleiche die Muster über mehrere Sessions, nicht über eine.