Input Lag: Was dahintersteckt und wie du ihn grob messen kannst

Definition: Input Lag, Latenz und was genau gemessen wird

Input Lag meint im Gaming-Kontext meist „Motion-to-Photon“-Latenz: vom physischen Auslösen (Taste/Click/Stickbewegung) bis zum Moment, in dem das Ergebnis als Licht am Bildschirm sichtbar ist. Davon abzugrenzen ist Netzwerk-Latenz (Ping) sowie Reaktionszeit des Menschen.

Wichtig ist der Messpunkt: Manche Tools betrachten nur „Eingabe bis Frame präsentiert“ (CPU/GPU-Pipeline), andere messen tatsächlich „bis sichtbar“ inklusive Display-Scanout. Für Vergleichbarkeit musst du wissen, ob das Display in der Messung enthalten ist.

Input Lag ist nicht konstant. Er schwankt mit Frametimes (Frame-Pacing), Lastspitzen in der Engine, Scheduler-Verhalten von CPU/GPU und mit Features wie V-Sync, Frame Limiting oder Upscaling, die die Renderpipeline beeinflussen.

Die Kette von der Eingabe bis zum Bild: Überblick

Praktisch ist es, Input Lag als Kette zu betrachten: (1) Peripherie erfasst die Aktion, (2) Übertragung/Abtastung bringt sie zum PC/der Konsole, (3) Betriebssystem und Treiber stellen Events bereit, (4) Spiel/Engine verarbeitet Input, Simulation und Netcode/Tickrate, (5) Renderpipeline berechnet und queued Frames, (6) Display baut das Bild zeilenweise auf und (7) die Pixel wechseln ihren Zustand.

Nicht jedes Glied ist immer dominant. Ein 60-Hz-Display setzt durch den Bildaufbau allein eine zeitliche „Rasterung“ von 16,67 ms pro Frame. Umgekehrt kann bei sehr hohen Hz und niedrigen Frametimes die Engine-/GPU-Queue (z. B. durch V-Sync oder zu tiefe Render-Queues) den größeren Anteil liefern.

• Merksatz: Input Lag ≈ Input-Erfassung + System/Pipeline + Display-Scanout (+ Pixelreaktion)
• Je niedriger und stabiler die Frametimes, desto geringer und gleichmäßiger meist auch der Input Lag
• Die „End-to-End“-Messung ist am aussagekräftigsten, aber am schwierigsten

Peripherie und Abtastrate: Maus, Tastatur, Controller

Bei Maus und Tastatur ist die Abtastrate (Polling Rate) ein zentraler Faktor. Bei 1000 Hz wird der Zustand idealisiert alle 1 ms gemeldet, bei 500 Hz alle 2 ms, bei 125 Hz alle 8 ms. Das ist keine feste Verzögerung, sondern eine Abtast-Quantisierung: Im Mittel kommt eine zusätzliche Wartezeit von etwa einer halben Polling-Periode dazu (also ca. 0,5 ms bei 1000 Hz; ca. 4 ms bei 125 Hz). Das ist eine Größenordnung aus der Sampling-Theorie, nicht aus einem spezifischen Gerätetest. Was daraus für die eigene Einstellung folgt, steht bei DPI, eDPI und Sensitivity.

Controller können zusätzlich durch interne Signalverarbeitung (Entprellen, Filter, Deadzones, ggf. Bluetooth-Stack) Zeit kosten. Bei Funkverbindungen hängt die Latenz stark vom Protokoll, der Interferenzlage und Energiesparmechanismen ab. Eine pauschale Millisekundenangabe ist ohne konkrete Messung unseriös; als Daumenregel gilt nur: Kabel ist einfacher zu reproduzieren, Funk kann variabler sein. Wie groß der Unterschied bei Maus, Tastatur und Headset tatsächlich ausfällt, haben wir in Funk oder Kabel getrennt betrachtet.

Ein oft unterschätzter Punkt: Manche Spiele lesen Input nicht ständig, sondern an festen Punkten im Frame (z. B. zu Beginn der Simulation). Wenn dein Click „knapp nach“ diesem Zeitpunkt passiert, wartet er bis zum nächsten Frame-Schritt – und das ist direkt mit deinen Frametimes gekoppelt.

USB, Betriebssystem und Treiber: wo Millisekunden verschwinden

USB selbst ist selten der Hauptschuldige, aber die Kombination aus USB-Polling, Interrupts, Treiberpfaden und Scheduling kann Latenz und vor allem Jitter (Schwankung) erzeugen. Bei stabiler Systemlast sind das meist kleine Anteile; unter CPU-Last oder bei ungünstigen DPC/ISR-Latenzen können Eingaben verzögert beim Spiel ankommen.

Für eine praktische Fehlersuche gilt: Wenn sich Input Lag „sprunghaft“ anfühlt (mal direkt, mal schwammig), sind unruhige Frametimes, Hintergrundlast oder Treiber-Probleme oft wahrscheinlicher als das Eingabegerät selbst. Die Kette ist so stark wie ihr instabilstes Glied.

Frametimes als Brücke zwischen System und Gefühl

Input reagiert nicht auf den FPS-Durchschnitt, sondern auf Frametimes. Ein Spiel kann im Mittel 120 FPS liefern, aber wenn einzelne Frames auf 25–30 ms ausreißen, spürst du das als „Lag-Spike“. Deshalb gehören Frametimes und Input Lag in der Praxis zusammen gedacht. Am Ende der Kette steht das Panel, und die Unterschiede zwischen OLED, IPS, VA und TN entscheiden mit, wie viel davon beim Auge ankommt.

Engine, Simulation, Tickrate und Netcode: Input wird erst „gültig“

In der Engine passiert mehr als „Input rein, Bild raus“. Zuerst wird Input gesammelt, dann werden Simulation und ggf. Physik berechnet. Bei Online-Spielen kommen Netcode-Entscheidungen hinzu: Client-Side Prediction, Interpolation und Server-Tickrate bestimmen, wie schnell eine Aktion sichtbar wird und wie stark die Darstellung geglättet wird.

Tickrate ist nicht gleich Input Lag, aber sie setzt einen zeitlichen Takt für serverautorisierte Ereignisse. Bei 64 Tick entspricht ein Tick 15,625 ms, bei 128 Tick 7,8125 ms. Das bedeutet nicht, dass jede Aktion um genau diese Werte verzögert wird, aber es beschreibt die zeitliche Auflösung, in der der Server Zustände verarbeitet und bestätigt. Lokal kann ein Client trotzdem schneller „vorhersagen“, während die Bestätigung später kommt.

Auch Singleplayer-Spiele können Input puffern (z. B. für Animationen oder Kombo-Logik). Das ist dann bewusstes Design und oft reproduzierbar als feste Zusatzlatenz.

Renderpipeline: Queue, V-Sync, Frame Limiter, Upscaling

Auf der GPU-Seite entsteht Input Lag vor allem durch Warteschlangen: CPU bereitet Draw Calls vor, die GPU rendert, und das Ergebnis wird in einem oder mehreren Buffern zwischengespeichert. Je tiefer die Queue, desto höher die Latenz – dafür oft stabilere Auslastung. Manche Treiber-/Engine-Settings reduzieren die Render-Ahead-Queue, was Latenz senken kann, aber bei knapper GPU-Leistung zu Stottern führen kann.

V-Sync kann Input Lag deutlich erhöhen, weil Frames auf das Display-Refresh warten. Bei 60 Hz sind das Schritte zu 16,67 ms; je nachdem, wann ein Frame fertig wird, kann er fast einen ganzen Refresh „verpassen“ und dann einen weiteren Zyklus warten. Variable Refresh Rate (VRR) kann Wartezeiten reduzieren, ersetzt aber nicht automatisch eine gut konfigurierte Pipeline.

Ein Frame Limiter kann Input Lag senken oder erhöhen, abhängig davon, ob er die Pipeline entstaut (gut) oder zusätzliche Pufferung/Waits erzeugt (schlecht). Upscaling (z. B. temporale Verfahren) kann Rechenzeit erhöhen oder senken, je nachdem, ob es GPU-Last reduziert oder zusätzliche Passes braucht. Entscheidend ist, ob die resultierenden Frametimes niedriger und gleichmäßiger werden.

• Richtwert aus Refresh-Intervallen: 60 Hz = 16,67 ms pro Bild, 120 Hz = 8,33 ms, 240 Hz = 4,17 ms
• Hohe und stabile FPS/kurze Frametimes reduzieren die „Wartezeit bis zum nächsten Frame“
• V-Sync und große Queues sind häufige Lag-Verstärker, wenn es um reines „Eingabe-zu-Bild“-Gefühl geht

Display: Scanout, Bildverarbeitung und warum „Game Mode“ zählt

Selbst wenn ein Frame fertig ist, wird er nicht instant sichtbar. Displays bauen das Bild zeilenweise auf (Scanout). Bei 60 Hz dauert ein kompletter Scanout etwa 16,67 ms, bei 120 Hz 8,33 ms. Im Mittel kommt dadurch – je nach Messpunkt und Trigger – ungefähr eine halbe Refresh-Periode als zusätzliche Wartezeit zustande, weil dein Ereignis irgendwo innerhalb eines Bildzyklus passiert.

Dazu kommt Bildverarbeitung im Display: Skalierung, Rauschfilter, Motion Interpolation, lokale Dimming-Algorithmen oder „Schärfe“-Enhancer können Puffern und so Latenz erhöhen. Deshalb ist ein echter Game Mode relevant: Er deaktiviert typischerweise einen Teil dieser Verarbeitung, was messbar sein kann – aber die genaue Größenordnung hängt vom jeweiligen Display und den aktivierten Funktionen ab.

Pixelreaktionszeit (Grey-to-Grey) ist nicht dasselbe wie Input Lag. Langsame Pixel können Bewegungen verschmieren, erhöhen aber nicht zwingend den Zeitpunkt, zu dem ein neues Bild „anfängt“ sichtbar zu werden. In der Praxis überlagern sich beide Effekte subjektiv.

Input Lag zuhause grob messen: Highspeed-Video und einfache Setups

Ohne Spezialgerät bekommst du eine brauchbare Näherung mit einer Highspeed-Kamera (Smartphone mit 120/240 fps, falls verfügbar) und einem Test, der gleichzeitig Eingabe und Bildreaktion sichtbar macht. Du misst dann Frame-genau die Zeitdifferenz in der Aufnahme. Die Genauigkeit ist durch die Kamera-FPS begrenzt: bei 240 fps entspricht ein Frame 4,17 ms, bei 120 fps 8,33 ms. Das ist die Messauflösung, nicht automatisch der Messfehler, aber es setzt die Größenordnung.

Praktischer Aufbau: Du filmst (1) deinen Finger auf einer Taste/Maustaste und (2) einen Bildbereich, der unmittelbar auf die Eingabe reagiert (z. B. Umschalten eines Menüpunkts, Schuss-Mündungsblitz in einem Trainingsbereich, oder ein lokales Testprogramm mit Farbumschlag bei Tastendruck). Danach zählst du in der Aufnahme die Frames zwischen dem Moment des physischen Drucks (sichtbarer Kontakt/Bewegungsumkehr) und der ersten sichtbaren Bildänderung.

Wichtig: Wiederhole das 20–30 Mal. Input Lag ist eine Verteilung, keine einzelne Zahl. Notiere Median und Spannweite, nicht nur den besten Wert. Stelle dabei sicher, dass die Szene reproduzierbar ist (kein Streaming im Hintergrund, keine Shader-Kompilierung, stabile Frametimes).

• Messauflösung: 120 fps ≈ 8,33 ms; 240 fps ≈ 4,17 ms
• Mehrere Versuche filmen, Median statt Minimum berichten
• Wenn möglich: gleicher Test mit und ohne V-Sync/mit Game Mode am Display, um den Einfluss einzelner Glieder zu sehen

Typische Fallstricke bei der Heim-Messung

Das größte Problem ist der Triggerzeitpunkt: „Finger bewegt sich“ ist kein perfekter Zeitpunkt für den elektrischen Schaltmoment. Das verfälscht absolute Werte, ist aber für Vergleiche (Setting A vs. B) oft trotzdem brauchbar, solange du gleich filmst. Zweiter Fallstrick: Kamera-Rolling-Shutter und Flimmern (PWM) können das „erste sichtbare Pixel“ schwer erkennbar machen – deshalb einen klaren Kontrastwechsel wählen.

Häufige Fragen

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