Maus-Abfragerate: Ist 1000 Hz wirklich besser als 500 Hz?
Die Verdopplung der Abfragerate von 500 Hz auf 1000 Hz verkürzt das Meldungsintervall von zwei auf eine Millisekunde und senkt die durchschnittliche Planungswartezeit um etwa eine halbe Millisekunde. Diese Verbesserung betrifft nur eine Stufe der Eingabepipeline und zählt vor allem, wenn Display-Wiederholrate, Frame-Rate und Verarbeitung bereits schnell sind. Maushersteller bewerben höhere Raten als Schlüsselspezifikation, doch der sichtbare Gewinn bleibt hinter der Zahl zurück. Für Büroarbeit und Gelegenheits-Gaming reicht 500 Hz meist aus und kann Prozessor- oder Akkuverbrauch senken. Ein Browser-Tester zeigt Ereignis-Timing-Muster auf, doch nur ein natives Tool verifiziert die USB-Report-Rate selbst.
In Zahlen
| Abfragerate | Meldungsintervall | Durchschnittliche Planungswartezeit |
|---|---|---|
| 125 Hz | 8,0 ms | 4,0 ms |
| 500 Hz | 2,0 ms | 1,0 ms |
| 1000 Hz | 1,0 ms | 0,5 ms |
| 2000 Hz | 0,5 ms | 0,25 ms |
| 4000 Hz | 0,25 ms | 0,125 ms |
| 8000 Hz | 0,125 ms | 0,06 ms |
Der Sprung von 125 Hz auf 1000 Hz entfernt 3,5 ms durchschnittliche Planungswartezeit. Der Sprung von 1000 Hz auf 8000 Hz entfernt etwa 0,44 ms. Das sind berechnete Unterschiede auf der Abfragestufe, keine Ende-zu-Ende-Messungen einer bestimmten Maus oder eines bestimmten Systems.
Maushersteller bewerben 8000 Hz Abfragerate heute als Schlagzeilen-Spezifikation – mit der klaren Unterstellung, alles Niedrigere bremse Sie aus. Der Schritt von 500 Hz auf 1000 Hz ist auf dem Papier real, doch die Folge auf dem Bildschirm fällt deutlich kleiner aus, als die verdoppelte Zahl suggeriert, und höhere Raten bringen Kosten mit sich, die das Marketingmaterial verschweigt. Hier ist die ehrliche Bilanz.
Was die Abfragerate tatsächlich beschreibt
Ihre Maus tastet ihre Position ab und überträgt diese Daten mit fester Frequenz an den Computer. Bei 500 Hz meldet sie alle zwei Millisekunden, bei 1000 Hz jede Millisekunde, bei 8000 Hz alle 0,125 Millisekunden. Eine höhere Rate bedeutet häufigere Positionsupdates und damit potenziell weniger Verzögerung zwischen Handbewegung und Cursor-Reaktion.
Das entscheidende Wort ist potenziell. Abfragen ist eine Stufe in einer Latenzpipeline – und fast nie die längste.
Die Rechnung, die alle zitieren – und der Kontext, den sie auslässt
Der Unterschied zwischen 1000 Hz und 500 Hz beträgt eine Millisekunde im Meldungsintervall. Das ist der komplette messbare Vorteil auf der Abfragestufe, und da Bewegungen an zufälligen Punkten innerhalb eines Intervalls auftreten, liegt die durchschnittlich realisierte Ersparnis näher bei einer halben Millisekunde.
Setzen Sie das nun neben die anderen Stufen derselben Pipeline:
| Stufe | Typische Dauer |
|---|---|
| Abfrageintervall bei 1000 Hz | 1 ms |
| Abfrageintervall bei 500 Hz | 2 ms |
| Display-Refresh bei 144 Hz | 6,9 ms |
| Display-Refresh bei 60 Hz | 16,7 ms |
| GPU-Framezeit bei 60 fps | 16,7 ms |
| Menschliche visuelle Reaktion | ~200 ms (keine Pipeline-Verzögerung – eine völlig andere Kategorie) |
Die eine Millisekunde, die die Verdopplung der Abfragerate bringt, ist ein Rundungsfehler neben Display-Refresh und Frame-Rendering. Beachten Sie, dass die oben gelistete menschliche visuelle Reaktion von etwa 200 ms einer völlig anderen Messkategorie angehört – sie ist die Zeit, die das Gehirn braucht, um einen visuellen Reiz zu verarbeiten und darauf zu reagieren, keine Verzögerung in der Eingabepipeline. Sie durch das Abfrageintervall zu teilen, ist daher kein gültiger Vergleich. Dieses Verhältnis ist der gesamte Grund, warum viele Nutzer 500 Hz von 1000 Hz im gewöhnlichen Gebrauch nicht zuverlässig unterscheiden können – wobei die Empfindlichkeit je nach Hardware, Aufgabe und individuellen Unterschieden variiert.

Wann 1000 Hz und darüber wirklich helfen
Höheres Abfragen macht am ehesten Sinn, wenn die anderen Glieder der Kette bereits schnell sind. Zum Beispiel:
- Ein Display mit hoher Wiederholrate, im Bereich 240 bis 360 Hz, damit der Bildschirm Updates tatsächlich in Intervallen unter vier Millisekunden darstellen kann.
- Durchgehend hohe Frame-Raten, deutlich über der Display-Wiederholrate, damit gerenderte Frames existieren, um diese Aktualisierungsmöglichkeiten zu füllen.
- Niedrige Systemlatenz insgesamt, einschließlich direkter USB-Verbindung, minimaler Hintergrundverarbeitung und keiner Overlays im Eingabepfad.
Innerhalb dieses engen, bewusst optimierten Wettkampffensters können manche Spieler aus 1000 Hz und gelegentlich höheren Raten echten Nutzen ziehen. Außerhalb davon fällt der Nutzen schwerer zu erkennen, weil der Engpass woanders liegt und zusätzliche Meldungen gebündelt oder abgetastet werden, bevor sie irgendetwas Sichtbares beeinflussen.
Die Kosten einer weiteren Erhöhung
Höheres Abfragen ist nicht kostenlos, und oberhalb von 1000 Hz werden die Trade-offs relevant:
Prozessorlast
Jede Meldung durchläuft den Eingabestack des Betriebssystems und oft die Spiel-Engine. Bei viertausend bis achttausend Hertz verbraucht das messbare Prozessorzeit, und auf schwächeren Systemen kann die daraus resultierende niedrigere Frame-Rate die Gesamtlatenz erhöhen statt senken.
Akkuverbrauch
Drahtlose Mäuse verbrauchen bei erhöhten Raten generell mehr Strom, und 8000 Hz kann die Laufzeit zwischen Ladungen bei manchen Modellen deutlich senken.
Meldungen, die selten sichtbaren Nutzen bringen
Eine 8000-Hz-Maus meldet alle 0,125 Millisekunden, während ein 360-Hz-Display alle 2,8 aktualisiert. Zwischen aufeinanderfolgenden Frames treffen mehr als zwanzig Meldungen ein; Betriebssystem und Spiel-Engine bündeln, sammeln oder sampeln sie in ihrem eigenen Takt, sodass die zusätzliche Granularität nicht zuverlässig bis in einen gerenderten Frame gelangt.
Abfragerate ist weder Zielgenauigkeit noch DPI
Zwei hartnäckige Verwechslungen verzerren Kaufentscheidungen:
- DPI ist Sensorempfindlichkeit und beschreibt die Cursorbewegung pro Zoll physischer Bewegung. Sie ist völlig unabhängig vom Abfragen und wird auf Komfort statt Latenz abgestimmt.
- Zielgenauigkeit entsteht aus Sensorgenauigkeit, Oberfläche, Griff und Übung. Eine 1000-Hz-Maus mit einem Sensor, der Glättung oder Winkelrasten zeigt, zielt schlechter als eine 500-Hz-Maus mit sauberer Sensor-Implementierung.
Keines von beiden wird durch die Abfrage-Spezifikation verbessert, und Hersteller profitieren von dieser Mehrdeutigkeit.
Prüfen Sie, was Sie tatsächlich erhalten
Konfigurierte und gelieferte Rate können auseinandergehen, doch ein Browser kann die Hardware-Abfragerate nicht direkt auslesen: Maus-Events unterliegen dem Browser-Coalescing, der Main-Thread-Planung und der Eingabeverarbeitung des Betriebssystems, sodass Web-Timing das tatsächliche USB-Report-Intervall nicht beweisen kann. Für eine zuverlässige Messung verwenden Sie ein dediziertes natives Tool, das Daten auf USB-Ebene liest, oder die Software Ihres Mausherstellers. Was ein Browser-Tool wie unser Maus-Tester beitragen kann, ist eine grobe Musterprüfung: ungewöhnlich lange und konsistente Lücken zwischen aufgezeichneten Updates können auf ein Verbindungs-, Treiber-, Empfänger- oder Planungsproblem hindeuten, das sich mit einem nativen Tool verifizieren lässt. Schließen Sie direkt an einen bekannten guten Mainboard-Port an und testen Sie erneut, bevor Sie die Maus für fehlerhaft halten.
Empfohlene Standardwerte
- Kabelgebundene Gaming-Maus: 1000 Hz sind auf den meisten modernen Systemen eine vernünftige Standardeinstellung; senken Sie sie, wenn Sie CPU- oder Frame-Time-Probleme beobachten.
- Drahtlose Maus: Viele moderne 2,4-GHz-Empfänger unterstützen 1000 Hz – wählen Sie nach Priorität: 1000 Hz, wenn Sie das kürzeste Meldungsintervall wollen, oder 500 Hz, wenn die Akkulaufzeit wichtiger ist. Der Unterschied im Gefühl ist für viele Nutzer schwer erkennbar, während die Akkuersparnis bei 500 Hz real sein kann.
- Wettkampf-Rig mit High-Refresh-Display und hohen Frame-Raten: Probieren Sie 1000 bis 2000 Hz und bewerten Sie ehrlich, ob Sie einen Unterschied erkennen. Wenn nicht, gehen Sie zurück und holen Sie sich den Prozessorspielraum zurück.
- Alle anderen, einschließlich der meisten Produktivitätsnutzung: 500 Hz reichen üblicherweise aus. Prüfen Sie die Einstellung nur bei der Fehlersuche an einem konkreten Problem.

Wie USB Mausmeldungen auf Protokollebene handhabt
USB-Geräte kommunizieren mit dem Host über Endpunkte, von denen jeder für einen bestimmten Übertragungstyp konfiguriert ist. Mäuse nutzen Interrupt-Übertragungen, deren Abfrageintervall der Host-Controller mit der konfigurierten Frequenz einplant – der Host reserviert diese Zeitslots, wobei die tatsächliche Zustellung unter Systemlast dennoch schwanken kann. Das Gerät antwortet mit den Daten, die es bereit hat. Die Zeitgranularität hängt von der USB-Geschwindigkeit ab: Ein Full-Speed-Gerät (bei Mäusen typisch) wird in Ein-Millisekunden-Frames eingeplant, ein High-Speed-Gerät nutzt 125-Mikrosekunden-Microframes. Eine auf 1000 Hz konfigurierte Maus erhält auf einer Full-Speed-Verbindung daher einen Ein-Millisekunden-Slot; die genaue Endpunkt-Intervall-Semantik unterscheidet sich zwischen Full-Speed und High-Speed, und die tatsächliche Meldungskadenz hängt auch davon ab, wie der Deskriptor des Geräts sein Intervall deklariert.
Das Meldungspaket selbst definiert der HID-Deskriptor des Geräts, der Struktur und Größe der Daten deklariert, die die Maus sendet. Ein Standardbericht enthält ein Byte für den Tastenzustand, ein X-Delta, ein Y-Delta und optional Rad sowie weitere Achsdaten. Die Gesamtlast ist klein – typischerweise acht bis sechzehn Bytes –, weshalb Bandbreite fast nie die primäre Einschränkung ist. Die Einschränkung ist das Timing: wie oft der Host eine Übertragung einplant, wie schnell das Gerät sie füllen kann und wie rasch der Eingabestack des Betriebssystems sie verarbeiten kann.
Auf Betriebssystemebene löst jeder empfangene Bericht einen Interrupt aus, der sich durch den USB-Treiberstapel, den HID-Klassentreiber und schließlich das Eingabe-Subsystem fortpflanzt, das die Cursor-Position aktualisiert oder das Ereignis an die Vordergrund-Anwendung weiterreicht. Das Betriebssystem leitet nicht jeden Bericht einfach an die Spiel-Engine weiter; es bündelt sie, fasst sie zusammen oder verarbeitet sie nach seinem eigenen Eingabe-Design, was bedeutet, dass nicht jede Meldung zwangsläufig einen gerenderten Frame beeinflusst.
Dieses Verständnis auf Protokollebene klärt mehrere Punkte. Erstens ist die Abfragerate eine Eigenschaft der USB-Endpunkt-Konfiguration, nicht des Maussensors – der Sensor kann unabhängig in seinem eigenen Takt abtasten. Zweitens können kompatible Host und Gerät Meldungen im konfigurierten Intervall einplanen, doch die tatsächliche Kadenz hängt weiterhin von Deskriptor, Firmware, Verbindung und der Planung des Betriebssystems ab. Drittens summieren sich die Verarbeitungskosten bei extremen Raten und können die Spielleistung auf manchen Systemen drücken. Die Spezifikation beschreibt eine Planungskadenz, keine Garantie wahrnehmbarer Verbesserung, und die Schichten zwischen Kabel und Bildschirm führen jeweils Latenz ein, die die Abfragerate nicht adressiert.
Eine weitere Feinheit: Die Planung des USB-Controllers ist nicht perfekt deterministisch. Der Host-Controller verwaltet mehrere Geräte, die sich denselben Bus teilen, und anderer Verkehr kann kleine Zeitvariationen einführen. Wie groß diese Variation ausfällt, hängt von Controller, Treibern, angeschlossenen Geräten und Betriebssystem ab – sie sollte gemessen, nicht angenommen werden. Ein direkter Mainboard-Port ist ein sinnvoller Diagnosevergleich, doch USB 3.x ist für eine Maus nicht grundsätzlich erforderlich.
Eine Millisekunde ist der maximale Intervallunterschied zwischen 500 Hz und 1000 Hz auf der Abfragestufe. Er ist real und messbar, fällt aber für viele Nutzer schwer zu erkennen. Die anderen Pipeline-Stufen – GPU-Framezeit, OS-Verarbeitung und Display-Refresh – können weit mehr beitragen, und keine Maus-Einstellung verkürzt sie. Wer Gaming-Maus und High-Refresh-Monitor besitzt, für den ist 1000 Hz ein vernünftiger Ausgangspunkt; bewerten Sie aber CPU-Last, Frame-Time, Akkuverbrauch und Ihre eigene Erfahrung, statt es als universelle Anforderung zu behandeln.
Um zu verstehen, wo die Abfragerate in der gesamten Latenzkette sitzt, hilft es, eine einzelne Mausbewegung durch jede Stufe von der physischen Oberfläche bis zur sichtbaren Cursor-Änderung zu verfolgen. Jede Stufe trägt Zeit bei, und Abfragen ist nur eine davon.
Sensor-Abtastung. Der optische Sensor Ihrer Maus erfasst Bilder der Oberfläche mit einer hohen internen Rate – oft 12.000 bis 16.000 Bilder pro Sekunde – und vergleicht aufeinanderfolgende Bilder, um die Bewegung zu berechnen. Dieser Prozess läuft vollständig im Sensor ab und folgt seiner eigenen Frequenz, unabhängig von der USB-Abfragerate. Der Sensor erzeugt ein Positions-Delta und übergibt es an den Mikrocontroller der Maus.
Mikrocontroller-Verarbeitung. Der MCU empfängt das Sensor-Delta, wendet konfigurierte Verarbeitung wie Angle Snapping, Glättung oder Beschleunigung an und packt es in ein USB-Report-Paket. Diese Stufe fügt eine kleine, aber nicht null betragende Verzögerung hinzu – illustrative Modelle deuten auf unter eine Millisekunde bei sauber entwickelter Firmware, doch die tatsächlichen Werte variieren je nach Gerät und können bei Geräten mit aufwendiger DSP-Verarbeitung länger ausfallen.
USB-Übertragung. Das ist die Stufe, die von der Abfragerate bestimmt wird. Bei 1000 Hz wartet das fertige Paket auf die nächste eingeplante Interrupt-Übertragung, die jede Millisekunde stattfindet. Im Durchschnitt wartet das Paket die halbe Intervalllänge – 0,5 Millisekunden –, bevor es zum Host übertragen wird. Bei 500 Hz verdoppelt sich die durchschnittliche Wartezeit auf eine Millisekunde.
OS-Eingabestapel. Der Host empfängt den Bericht und verarbeitet ihn durch USB-Treiber, HID-Klassentreiber und Eingabe-Subsystem. Die Cursor-Position wird im OS-Compositor aktualisiert, und das Roh-Eingabeereignis geht an das Spiel. Diese Stufe wird üblicherweise auf ein bis drei Millisekunden modelliert, je nach OS, Treiberversion und Systemlast – als illustrative Spanne behandeln, nicht als Messung eines konkreten Systems.
Spiel-Engine-Verarbeitung. Das Spiel empfängt das Eingabeereignis, wendet seine eigene Eingabelogik an (darunter Empfindlichkeitsskalierung, Raw Input gegenüber gepuffertem Input und frame-ratenabhängiges Sampling) und integriert die Bewegung in den nächsten gerenderten Frame. Läuft das Spiel mit 60 fps, dauert jeder Frame 16,7 Millisekunden – die Bewegung kann also erst dann auf dem Bildschirm erscheinen, wenn der nächste Frame gerendert und an das Display übergeben ist.
Display-Präsentation. Der gerenderte Frame wandert zum Monitor, der ihn in seinem eigenen Refresh-Intervall darstellt. Bei 144 Hz erscheint der Frame innerhalb von 6,9 Millisekunden nach Ankunft im Eingabepuffer des Displays auf dem Bildschirm.
Summiert man die typischen Stufen mit durchschnittlichen Wartezeiten in einem illustrativen Modell (keine Messung einer bestimmten Maus oder eines bestimmten Spiels): Sensor (~0,25 ms) + MCU (~0,5 ms) + USB bei 1000 Hz (~0,5 ms durchschnittliche Wartezeit) + OS (~2 ms) + Spiel bei 60 fps (~8,3 ms durchschnittliche Frame-Wartezeit) + Display bei 144 Hz (~3,5 ms durchschnittliche Refresh-Wartezeit) ≈ insgesamt rund 15 Millisekunden. In diesem Modell trägt die USB-Abfragestufe grob 3 % zum Gesamten bei. Die Verdopplung des Intervalls auf 500 Hz fügt im Durchschnitt etwa 0,5 Millisekunden hinzu und erhöht die Summe auf rund 15,5 Millisekunden. Deshalb bleibt der gemessene Unterschied zwischen 500 Hz und 1000 Hz konstant unter einer Millisekunde – der Rest der Pipeline ändert sich nicht. Diese Zahlen sind ein illustratives Modell, keine Messung einer bestimmten Maus, eines bestimmten Betriebssystems oder Spiels; die realen Werte hängen vollständig von Ihrer Hardware, Ihren Treibern und Ihrer Software ab.
Die Konsequenz ist nicht, dass die Abfragerate irrelevant wäre, sondern dass sie die letzte zu optimierende Komponente ist. Im selben Durchschnittswarte-Modell: Läuft Ihr Spiel mit 60 fps, entfernt eine Anhebung auf 144 fps rund 4,9 Millisekunden durchschnittlicher Frame-Wartezeit (16,7 ms/2 minus 6,9 ms/2) – etwa das Zehnfache der Ersparnis durch Verdopplung der Abfragerate. Läuft Ihr Display mit 60 Hz, entfernt ein Upgrade auf 144 Hz im Durchschnitt ebenfalls etwa 4,9 Millisekunden (16,7 ms/2 minus 6,9 ms/2). Die genauen Zahlen hängen davon ab, ob Sie durchschnittliche Wartezeit, volle Framezeit oder Ende-zu-Ende-Latenz messen – behandeln Sie sie als illustrativ, nicht als universell. Beide Änderungen erzeugen außerdem sichtbare Verbesserungen der Bewegungsklarheit, die Anpassungen der Abfragerate nicht erreichen. Nur wenn Frame-Rate und Wiederholrate bereits hoch sind, wird der Beitrag der Abfragerate zu einem proportional größeren Stück der verbleibenden Latenz – und bleibt absolut betrachtet klein.
Die eine Zahl zum Merken
1000 Hz kann das Intervall auf der Abfragestufe gegenüber 500 Hz um bis zu eine Millisekunde senken – real, aber oft schwer wahrnehmbar. Richten Sie Ihren Optimierungsaufwand zuerst auf Display-Wiederholrate und durchgehaltene Frame-Rate, denn diese Stufen können deutlich größere Verzögerungen beisteuern, und prüfen Sie erst danach, ob die Abfragerate etwas verändert, das Sie wahrnehmen. Behandeln Sie 8000 Hz als Option für hochauflösende Berichterstattung statt als garantiert spürbares Upgrade, solange der Rest der Pipeline sie nicht nutzen kann.