Average FPS lügt: Warum 1%-Lows und Frame Times wichtiger sind
Average FPS sieht gut aus, erklärt aber oft nicht, warum CS2 schlecht läuft. Frame Times, 1%-Lows und 0.1%-Lows sind die ehrlicheren Metriken.
Average FPS ist beliebt, weil sie eine einzige Zahl ist. Eine Zahl passt in einen OSD-Balken, in einen Benchmark-Screenshot, in einen Hardware-Test im Internet. Was sich auf dem Monitor abspielt, ist aber kein Durchschnitt. Was Spielgefühl ausmacht, ist die Verteilung dahinter – und vor allem die schlechten Stellen darin.
Average FPS ist wie Durchschnittseinkommen: statistisch hübsch, individuell oft beleidigend. Entscheidend ist nicht der schöne Mittelwert, sondern wie schlecht die schlechten Frames sind. Diese These zieht sich durch alle CS2-Performance-Diskussionen, die ehrlich geführt werden – und sie ist die Klammer, die die Latenz-Fallstudie und «hohe FPS, schlechtes Spielgefühl» zusammenhält.
Warum Average FPS so beliebt ist
Eine einzelne Zahl ist verkaufsfreundlich. Sie ist lesbar, vergleichbar, twitterbar. Hardware-Hersteller mögen sie, weil sie das Marketing einfach macht. Spieler mögen sie, weil das OSD sie sofort liefert. Für Vergleiche zwischen sehr unterschiedlichen Hardware-Klassen ist sie tatsächlich nicht nutzlos – wenn 60 FPS auf einer Karte und 240 FPS auf einer anderen herauskommen, ist klar, dass die Klassen unterschiedlich sind.
Sobald die Diskussion aber innerhalb einer Klasse stattfindet – «warum fühlt sich mein 600-FPS-Setup nicht so geschmeidig an wie das andere mit 500 FPS?» – ist Average FPS nicht mehr aussagekräftig. Dort beginnt die Lüge.
Warum Average FPS gefährlich verkürzt
Average FPS ist eine Aggregation. Sie verliert per Definition Information über die Verteilung. Zwei Setups können denselben Average liefern, aber komplett unterschiedlich aussehen, wenn man die einzelnen Frame Times nebeneinanderlegt.
Beispiel, methodisch nüchtern: Ein Setup mit 500 Average-FPS, dessen Frame Times zwischen 1.5 ms und 2.5 ms schwanken, läuft objektiv ruhiger als eines mit denselben 500 Average-FPS, aber Frame Times zwischen 1.0 ms und 4.5 ms. Auf hohem Refresh wird die Differenz spürbar – nicht als Stutter, sondern als unklares «Gefühl». Die Average-Zahl ist in beiden Fällen identisch, das Erlebnis nicht.
Was Frame Times sind
Frame Time ist die Zeit, die ein einzelner Frame zwischen Anforderung und Anzeige braucht – meist in Millisekunden. Aus den Frame Times ergibt sich die FPS-Kurve, nicht umgekehrt. Wer Frame Times kennt, kennt FPS automatisch mit; wer nur FPS kennt, weiss nichts über die Stabilität.
Frame Times zeigen drei Dinge, die ein Average verschweigt:
- die mediane Frame-Time (der ehrlichere Durchschnitt für asymmetrische Verteilungen),
- die Streuung zwischen den Frames,
- die Ausreisser in den schlechten 1 % oder 0.1 % der Messung.
Werkzeuge wie CapFrameX zeichnen genau diese Verteilung auf. Wer ohne ein solches Tool argumentiert, argumentiert ohne die relevanten Daten.
Was 1 %-Lows und 0.1 %-Lows bedeuten
1 %-Lows sind die Zeiten, die in den schlechtesten 1 % der Frames erreicht wurden – ausgedrückt als FPS-Wert. Ein Lauf mit «average 600 FPS, 1 %-Lows 250» bedeutet: Der Durchschnitt sah gut aus, aber 1 % der Frames hatte effektiv nur das Tempo von 250 FPS.
0.1 %-Lows sind dieselbe Logik, eine Stufe schlechter: die schlechtesten 0.1 % der Frames. Genau diese Frames sind oft Grund für Stutter-Eindrücke, weil sie nicht gleichmässig verteilt sind, sondern in Engagement-Momenten gehäuft auftreten – Smokes, Molotovs, viele Hit-Box-Events, Memory-Verkehr, Scene-Changes.
In der CS2-Praxis: Auf einem Valve-Deathmatch-Server brachen 0.1 %-Lows in der Latenz-Fallstudie von 300 auf 92 FPS ein, während die lokale Mess-Map noch sauber lieferte. Average FPS hätten diesen Einbruch komplett kaschiert.
Warum Stutter subjektiv stärker zählt als Durchschnitt
Wahrnehmung ist kein lineares System. Eine grosse Streuung wird stärker registriert als ein konstant niedriger Wert – das ist seit der Frühzeit der Wahrnehmungspsychologie ein bekanntes Muster. Dieselbe Logik gilt am Monitor: 200 FPS, die konstant 200 FPS sind, fühlen sich oft besser an als 400 FPS mit gelegentlichen 60-FPS-Frames.
Subjektives «Lag-Gefühl» ist deshalb häufig kein Latenz-Problem, sondern ein Frame-Time-Problem. Wer dieses Gefühl mit einem Treiber-Tweak bekämpfen will, behandelt das falsche Symptom. Der saubere Test trennt System-Pipeline und Mechanik – ausführlich beschrieben in Input Lag vs. Aim Leak.
Warum FPS-Limits manchmal bessere Werte liefern
Es klingt paradox: Ein FPS-Limit unterhalb der maximal möglichen Rate kann die 1 %-Lows hochziehen. Die Logik ist banal. Wenn die GPU nicht permanent gegen die Decke rennt, throttled sie weniger, läuft mit ruhigerer Frame-Time-Kurve und die schlechtesten Frames werden weniger schlecht.
Auf einem konkreten Setup zeigte das in der Latenz-Fallstudie eine deutliche Verbesserung der 1 %-Lows ohne nennenswerte Latenz-Verschlechterung. Das war eine Messung, kein Glaubenssatz. Die Mess-Anleitung dazu ist banal: Limit ungefähr 10 % unter dem Average setzen, in 10-FPS-Schritten senken, bei der besten 1 %-Lows-Marke bleiben.
Auch hier gilt: was auf dem einen Setup hilft, kann auf einem anderen nutzlos oder kontraproduktiv sein. Das ist kein Setting-Tipp, das ist ein Mess-Vorgehen.
Wie man CapFrameX-Werte liest, ohne sich selbst anzulügen
CapFrameX liefert eine Reihe von Kennzahlen. Drei davon lohnen besondere Aufmerksamkeit:
- Average FPS: nützlich nur für die Grobeinordnung; nicht für Setting-Entscheidungen.
- 1 %-Lows und 0.1 %-Lows: die ehrlichen Werte für Stabilität.
- Frame-Time-Verteilung: die Form der Kurve. Eine schmale Verteilung mit wenigen Ausreissern ist besser als eine breite Verteilung, selbst wenn der Average gleich aussieht.
Vermeidbare Selbstlügen:
- Nur einen Run messen. Streuung zwischen Sessions wird sichtbar, sobald man mehrere Runs vergleicht.
- Den schöneren von zwei Runs reporten. Das ist Kosmetik, keine Messung.
- Lokale Benchmarks auf Online-Server übertragen. Server-Last, Tickrate und Netzwerk verändern das Bild – Beispiele dazu in der Latenz-Fallstudie und in «CS2 trotz hoher FPS schlecht».
Wer Frame-Times liest, ohne sich auf einen einzelnen Lauf zu verlassen, wird ehrlicher mit dem eigenen Setup.
Bezug zur CS2-Latenz-Fallstudie
Die CS2-spezifischen Messwerte aus dem Latenz-Beitrag – Baseline auf der Dust2-Benchmark, externer Frame-Limiter mit -noreflex, Valve-Empfehlung mit GSync + VSync + Reflex – machen denselben Punkt aus drei Richtungen: Average FPS allein hätte die spannenden Differenzen verschwiegen. 1 %-Lows haben sie gezeigt. Die Click-to-Photon-Messung mit dem NVIDIA Reflex Latency Analyzer hat die Latenz-Seite ergänzt.
Der methodische Reflex dahinter ist nicht CS-spezifisch. Wer datenbasiert arbeitet, kennt das Muster aus anderen Disziplinen – mehr Hintergrund in Empirische Forschung – Vor- und Nachteile.
Fazit
Die schlechtesten Frames entscheiden oft mehr als der schönste Durchschnitt. Average FPS hat ihren Platz – als Grobvergleich. Für Spielgefühl, Setting-Entscheidungen und ehrliche Selbsteinschätzung sind Frame Times, 1 %-Lows und 0.1 %-Lows die robusteren Werte. Eine einzige hübsche Zahl ist verführerisch, aber sie ist keine Messung; sie ist eine Zusammenfassung von Messungen.
Quellen und Einordnung
- CapFrameX – Open-Source-Tool für Frametime-Analyse, Quelle der Frame-Time-Verteilung und 1 %-Lows.
- NVIDIA – Reflex Latency Analyzer & 360 Hz G-SYNC Monitors – ergänzendes Hardware-Werkzeug für die Latenz-Seite.
Wie immer: was hier steht, ist Methodik. Konkrete Zahlen aus dem Beitrag stammen aus der verlinkten Fallstudie auf einem konkreten Setup; sie sind keine Empfehlung, sie zu kopieren. Wer messen will, misst selbst.