1000Hz vs 4000Hz vs 8000Hz: Latency Math and CPU Load

Polling rate describes the nominal cadence at which a mouse can report to the host. At frequency f in hertz, the corresponding period is T = 1000 / f milliseconds. A device setting specifies a cadence; it does not promise the same number of movement samples in every browser capture.

The mean-wait column assumes perfectly periodic reporting and that a new input becomes ready at a random, uniformly distributed point between reports. Waiting then ranges from almost zero to almost one full period, with a mean of half a period. Sensor sampling, processing and transport can change those assumptions.

Under this model, moving from 1000Hz to 4000Hz saves 0.375ms of mean report wait. Moving from 4000Hz to 8000Hz saves another 0.0625ms. The full 1000Hz-to-8000Hz change saves 0.4375ms. Subtracting the full periods gives 0.875ms, which is the difference in nominal periods, not a universal measured latency improvement.

For a movement to appear on screen, the sensor must detect it, the device must process and transmit it, the operating system must deliver it, and the game must consume it. Rendering, presentation and display scanout add further timing. Raising the polling setting changes one part of that chain.

A 240Hz display has a nominal frame period of about 4.167ms; a 360Hz display has one of about 2.778ms. These values help put the report periods in context. They do not set a rule that mouse polling rate must equal display refresh rate, and they do not prove that an improvement below one frame is invisible.

The moment a game samples input can affect which movement reaches a frame. A higher report cadence may provide a fresher sample at that moment. How the game reads and uses that input remains important. Microsoft's Raw Input documentation describes buffered reads for handling accumulated high-frequency input efficiently.

Higher report rates can increase input-processing work. The cost depends on the input stack, the game, background listeners and how events are handled. An eightfold nominal report rate does not establish an eightfold increase in total CPU usage.

In May 2023, Microsoft described Windows input-stack optimizations after high report rate mice and multiple background listeners consumed substantial processing time. The changes throttled and coalesced background raw mouse listeners. That report establishes a real mechanism for overhead; it does not predict performance on every current Windows build or game.

There is no defensible universal table saying a particular CPU loses a fixed percentage of FPS at 8000Hz. A meaningful result needs the game version, OS build, CPU and GPU, rendering settings, mouse and receiver firmware, movement conditions, and repeated runs. An aggregate CPU percentage can also hide a busy thread that affects frame delivery.

Use a supported rate as a control and change only the polling setting between captures. The following is a comparison protocol, not a report of tests performed by this site.

1. Record the setup. Note OS and game versions, hardware, mouse firmware, receiver, connection, DPI, display refresh rate and relevant background applications.
2. Confirm the setting. Apply it in the manufacturer's software or hardware controls. Check the active profile and whether the chosen receiver supports that rate.
3. Repeat a browser capture. Keep the page focused and move continuously at the same DPI and similar speed. Record measurement status as well as Hz. Use the browser-limits guide when the result is inconclusive.
4. Record game frame times separately. Use a repeatable local scene or replay where input movement is accepted. Keep duration, rendering settings, frame cap and background workload constant; include an idle-mouse control.
5. Repeat each setting several times. Alternate the order to reduce warm-up or drift effects. Compare frame-time traces and run-to-run variation before attributing a change to polling rate.
6. Keep the evidence together. Report every run, the capture tool and version, CPU measurement scope, and how any FPS low statistic was calculated. A small difference inside normal variation is inconclusive.

For wireless devices, measure battery behavior separately if it matters to your choice. Keep usage duration and conditions comparable rather than assuming a fixed runtime penalty from the polling setting alone.

Our practical recommendation is to use 1000Hz as an initial comparison point, then try 4000Hz and 8000Hz if your hardware supports them. Keep a higher setting when the benefit matters to you and repeated checks show acceptable frame pacing and battery use in your actual games.

If stutter repeatedly appears with continuous movement at a higher setting and disappears at a lower setting under the same conditions, that is a useful reason to investigate or use the lower rate. It does not identify the faulty component by itself.

The browser test can help compare what reaches the page. Its Stability and Lowest 500 ms Rate describe the capture, and cannot certify game performance. Read a game frame-time trace alongside the browser result before drawing a performance conclusion.

Frequently asked questions