FPS, Frametimes und Ruckler: Was die Zahlen wirklich bedeuten

Warum Durchschnitts-FPS in die Irre führen

FPS sind eine abgeleitete Größe: „Frames pro Sekunde“ ist der Kehrwert der Zeit, die ein einzelnes Bild braucht. Ein Durchschnitt glättet zwangsläufig alles, was kurz passiert. Genau diese kurzen Ereignisse (ein Frame braucht plötzlich viel länger) sind aber das, was als Ruckler wahrgenommen wird.

Ein Beispiel zur Größenordnung: 60 FPS entsprechen im Mittel 16,67 ms pro Frame, 120 FPS 8,33 ms und 240 FPS 4,17 ms. Wenn ein Spiel „im Schnitt 120 FPS“ liefert, aber alle paar Sekunden ein einzelner Frame 40–80 ms braucht, fühlt sich das als Hänger an, obwohl der Mittelwert hoch bleibt.

Dazu kommt: Durchschnitts-FPS ignorieren, wie gleichmäßig die Frames kommen. Zwei Systeme können beide 120 FPS im Schnitt erreichen, aber das eine liefert sehr konstante 8–9 ms pro Frame, das andere springt zwischen 5 ms und 20 ms. Letzteres wirkt trotz identischem Durchschnitt unruhig (Frame-Pacing-Problem).

Frametimes: die wichtigere Größe (und die Umrechnung)

Frametime bedeutet: Wie viele Millisekunden (ms) vergehen zwischen zwei fertig gerenderten Bildern. Das ist die direkt messbare Größe für „wie gleichmäßig“ eine Ausgabe ist. Statt „120 FPS“ zu lesen, sieht man „meist ~8,3 ms, gelegentlich 25 ms“. Genau diese Ausreißer erklären Ruckler.

Die Umrechnung ist simpel: FPS = 1000 / Frametime(ms). Umgekehrt: Frametime(ms) = 1000 / FPS. Darum sind kleine Änderungen bei hohen FPS in ms besonders relevant: Von 240 auf 200 FPS klingt nach wenig, bedeutet aber von 4,17 ms auf 5,00 ms pro Frame – eine spürbare Verschiebung, wenn es um Input Lag und Konsistenz geht.

Wichtig: Frametime ist nicht automatisch „GPU-Zeit“. In modernen Engines kommt ein Frame durch mehrere Phasen (Game-Thread/CPU, Render-Thread, GPU, Treiber-Queue, Präsentation). Der Frametime-Wert am Ende ist das Ergebnis aus dem langsamsten Glied plus möglichem Queueing.

• 60 FPS ≈ 16,67 ms
• 90 FPS ≈ 11,11 ms
• 120 FPS ≈ 8,33 ms
• 144 FPS ≈ 6,94 ms
• 165 FPS ≈ 6,06 ms
• 240 FPS ≈ 4,17 ms

1% Low und 0.1% Low: was diese Zahlen wirklich ausdrücken

1% Low und 0.1% Low sind Perzentil-Werte, keine „schlechteste Sekunde“ und auch nicht „Minimum-FPS“. Üblich ist: Man erfasst viele Einzel-Frames, sortiert sie nach Frametimes bzw. daraus abgeleiteten FPS und schaut, welcher Wert am Rand liegt.

1% Low bedeutet: 99% aller Frames waren schneller (besser), 1% waren langsamer (schlechter). 0.1% Low entsprechend: Nur die schlechtesten 0,1% der Frames zählen. Das ist näher an seltenen, aber deutlich spürbaren Hängern.

Warum das hilfreicher ist als Min-FPS: Ein einzelner Ausreißer (z. B. ein Alt-Tab, ein Hintergrunddienst, ein Shader-Hitch) kann das Minimum ruinieren, ohne typisch für das Spiel zu sein. Perzentile sind robuster und korrelieren oft besser mit subjektiver „Smoothness“.

Wovon 1%/0.1% Low abhängen

Die Werte hängen stark von Messdauer, Szene und Messmethode ab: Ein 30‑Sekunden-Lauf kann andere 0.1% Lows ergeben als ein 5‑Minuten-Lauf, weil seltene Events unterschiedlich oft vorkommen. Auch die Frage „Frametime-Perzentil und dann in FPS umrechnen“ vs. „FPS pro Frame direkt perzentilieren“ kann Unterschiede erzeugen. Seriöse Messungen dokumentieren deshalb Tool, Laufzeit und Szenario.

Frametime-Graph lesen: Peaks, Plateaus und Muster

Ein Frametime-Graph zeigt typischerweise auf der X‑Achse die Zeit (oder Frame-Index) und auf der Y‑Achse die Frametime in ms. Niedriger ist besser. Eine „ruhige“ Linie mit wenig Streuung wirkt flüssig, auch wenn sie nicht extrem niedrig ist.

Peaks nach oben sind die klassischen Ruckler. Ein einzelner Peak auf 33 ms in einem 120‑FPS‑Setup heißt: Dieses Bild brauchte etwa viermal so lang wie üblich. Mehrere Peaks hintereinander wirken wie ein kurzer Stotterer oder „Nachziehen“.

Plateaus sind ebenfalls aussagekräftig: Wenn die Linie häufig auf exakt ~16,7 ms, ~33,3 ms oder ~50 ms „einrastet“, deutet das auf Framelimits, V-Sync/VRR-Verhalten oder Queueing hin. Die typischen Stufen entstehen, weil bei fester Ausgabe an ein Display-Refresh (z. B. 60 Hz) Frames ggf. auf den nächsten Refresh warten.

• Gleichmäßige, schmale Streuung: gutes Frame-Pacing
• Vereinzelte hohe Peaks: Hitches (kurze Blocker wie Shader/Streaming/CPU-Spike)
• Regelmäßige Stufen bei Vielfachen: Sync/Refresh-Quantisierung oder Limitersignal
• „Sägezahn“: schwankende Last, oft CPU-Grenze oder Streaming

Woher Mikroruckler kommen (und warum sie nicht immer GPU-Limit sind)

Mikroruckler sind meist kein „zu wenig FPS“-Problem, sondern ein „zu ungleichmäßige Frametime“-Problem. Ursachen liegen oft in kurzen Blockaden oder in unruhigem Scheduling zwischen CPU, GPU und Treiber.

Shader-Kompilierung ist ein häufiger Kandidat: Wenn ein Spiel Shader erst beim ersten Auftauchen eines Effekts kompiliert (oder Pipeline-State-Objekte erstellt), kann das einzelne Frames massiv verlängern. Das passiert besonders beim ersten Durchlauf nach Patch/Driver-Update oder in neuen Arealen. Warum Spiele überhaupt in so kurzen Abständen Updates bekommen, erklären wir unter Warum Spiele ständig Patches bekommen.

Asset-Streaming (Texturen, Geometrie, Audio) kann ebenfalls Hitches erzeugen, wenn Daten nicht rechtzeitig aus dem Speicher nachgeladen werden. Die Größenordnung hängt stark von Speicher (RAM/VRAM), Datenträger (SSD vs. langsamere Medien), Kompression und der Engine-Streaming-Strategie ab.

CPU-Spitzen entstehen z. B. durch KI, Physik, Script-VMs, Garbage Collection oder Netcode/Entitäten-Management. Gerade in Multiplayer-Szenen kann die CPU-Last stark schwanken, obwohl die GPU noch Reserven hätte. Wo die Grenze zwischen CPU- und GPU-Limit in der Praxis liegt, ordnen wir in der Kaufberatung für 1440p-Grafikkarten ein.

Frame-Pacing und Treiber-Queue

Selbst wenn die GPU theoretisch schnell genug rendert, kann eine zu tiefe oder zu tiefe Render-Queue (Vorbereitung mehrerer Frames) die Gleichmäßigkeit und den Input Lag beeinflussen. Engines und Treiber versuchen, Auslastung zu maximieren, was zu stärkerem Queueing führen kann. Das zeigt sich als „fühlt sich träge an“ trotz hoher FPS und als unruhige Frametime-Verteilung bei Lastwechseln.

Sync, VRR und Frame-Limiter: warum „stabil“ oft besser ist als „hoch“

V-Sync verhindert Tearing, kann aber bei Unterschreiten der Refresh-Rate zu sichtbaren Sprüngen führen, weil Frames auf den nächsten Refresh warten müssen. Bei 60 Hz sind die „Stufen“ 16,67 ms, 33,33 ms, 50 ms usw. – ein einzelner verpasster Refresh verdoppelt sofort die Frametime.

VRR (Variable Refresh Rate, z. B. FreeSync/G-SYNC Compatible) kann diese Stufen innerhalb der VRR-Range reduzieren, weil das Display seinen Refresh an die Frame-Ausgabe anpasst. Das verbessert wahrgenommenes Smoothness bei schwankender Performance, ersetzt aber keine stabile Frametime: große Peaks bleiben große Peaks.

Ein Frame-Limiter kann helfen, die Ausgabe zu glätten und die Render-Queue zu verkleinern, wenn er sauber implementiert ist. In der Praxis gilt: Ein knapp unter der Display-Refresh-Rate gesetztes Limit (z. B. wenige FPS darunter) reduziert oft Sync-Konflikte und stabilisiert Frametimes — das genaue Optimum hängt aber von Engine, VRR, Treiber und Monitor ab.

Praktisch messen und interpretieren: worauf du achten solltest

Für aussagekräftige Zahlen brauchst du reproduzierbare Szenen und ausreichend lange Messungen. Kurze Runs bevorzugen Durchschnitts-FPS und können 0.1% Low verfälschen, weil seltene Hitches zufällig fehlen oder überrepräsentiert sind. Deshalb immer Kontext notieren: Map/Level, Route, Spielmodus, Patchstand, Treiberstand.

Beim Interpretieren hilft eine einfache Checkliste: Erst schauen, ob du im GPU-Limit oder CPU-Limit bist (Auslastung, Takt, Render-Thread-Zeiten). Dann prüfen, ob die Frametime-Linie eher „Rauschen“ (stetige Streuung) oder „Peaks“ (Hitches) zeigt. Rauschen deutet auf schwankende Last, Peaks eher auf Blocker wie Streaming oder Shader.

Wenn du Optionen änderst, ordne sie der Ursache zu: Auflösung/Upscaling und AA beeinflussen primär die GPU; Sichtweite, NPC-Dichte, Physik und hohe Framerates belasten oft die CPU. Das Ziel ist nicht der höchste Durchschnitt, sondern ein enger Frametime-Korridor mit wenigen Ausreißern. Wie wir genau das im Testparcours nachmessen, steht in unserer Methodik zum Gaming-Monitor Test.

• Nicht nur Average-FPS vergleichen: immer 1% Low/0.1% Low und Frametime-Graph ansehen
• Auf „Stufen“ achten: Hinweis auf V-Sync/Refresh-Quantisierung
• Peaks korrelieren: treten sie beim Drehen der Kamera, beim Betreten neuer Bereiche oder in Gefechten auf?
• Bei neuen Treibern/Patches: erster Run kann Shader-Hitches zeigen, zweiter Run oft weniger

Häufige Fragen

Veröffentlicht am 18. September 2026 · Zuletzt aktualisiert am 30. September 2026