Mouse Polling Rate Explained: 125 Hz to 8000 Hz, Latency and CPU

Polling rate is one of the most advertised numbers on a gaming mouse, and one of the most misunderstood. It describes how often the mouse can report to the computer. It is not your click latency, and it is not your reaction time. Your reaction time test score includes polling, but only as one small slice of the whole chain.

What polling rate actually is

Polling rate is the number of reports per second a mouse can send, in hertz. Logitech's explainer puts it simply: at 1000 Hz, the mouse reports 1,000 times a second, or once every millisecond.

On a wired USB mouse, the host checks the mouse's interrupt endpoint at an interval set in the device descriptor. Microsoft's documentation for the USB endpoint descriptor explains that this bInterval value is relative: the actual polling frequency also depends on whether the device runs at low, full or high speed. Full-speed USB is organised in 1 ms frames, which is why 1000 Hz is the common ceiling. High-speed USB divides time into 125 µs microframes, which is what makes 8000 Hz possible. Razer, for example, markets its 8000 Hz HyperPolling as cutting the 1 ms interval of a 1000 Hz mouse to 0.125 ms.

The interval math

The interval is 1000 / rate in Hz, in milliseconds. If a click or movement becomes ready at a random moment between reports, it waits on average about half an interval before the next one. That is a simple model, not a measurement, but it shows the shape of the tradeoff:

These figures are arithmetic. They are not click-latency results, and they don't promise that a particular mouse achieves its advertised rate.

Why the gain shrinks at higher rates

Each step up halves a number that is already small. Going from 125 Hz to 1000 Hz saves about 3.5 ms of modeled average wait. Going from 1000 Hz to 8000 Hz saves about 0.44 ms, an eightfold rate increase for an eighth of the benefit.

Measured results look similar. In TechPowerUp's testing of one wireless mouse, its motion-delay lead over the control mouse was 0.5 ms at 2000 Hz, 0.7 ms at 4000 Hz and 0.8 ms at 8000 Hz. Each doubling added less.

For scale, a 60 Hz display shows a new frame every 16.7 ms and a 240 Hz display every 4.2 ms (again, arithmetic). Once you're at 1000 Hz, the mouse report interval is already much smaller than the display step. The monitor refresh rate guide covers that part of the chain.

Two more limits matter:

• No movement, no report. TechPowerUp notes that if the mouse isn't moved enough to generate new motion data, fewer updates are sent. At 4000 Hz, that means at least 4000 counts of movement per second. Slow hand speed or low DPI can keep the real report rate below the setting.
• Polling is not click latency. Switch design, debounce and firmware add their own delay before a click is ready to report. The input lag vs reaction time guide separates those pieces.

The CPU cost

More reports means more work for the computer. Corsair's support guidance says higher polling rates come with a higher CPU usage cost. The effect is minimal for keyboards, but can be greater on older systems. TechPowerUp's 4000 Hz review goes further: on weaker CPUs, the extra load can make input response worse, and it suggests a strong CPU and a 240 Hz or 360 Hz display to get any benefit.

Razer's own troubleshooting advice for 8000 Hz devices is to try a lower setting, such as 4000 or 2000 Hz. That is a sensible rule for any brand: if a game stutters, frame times spike, or the cursor feels uneven at the highest rate, step down and see if the problem goes away.

When polling rate matters

What a browser can and can't see

A web page doesn't see USB reports. It sees pointer events after the operating system and browser have handled them. MDN notes that pointerrawupdate fires as often as the browser can produce events, while pointermove may be delayed for performance. Raw updates are only available in secure contexts and aren't supported in every browser. Both event types can still be merged together.

That is why the WiredReflex polling rate tool reports two separate observations, event dispatch cadence and coalesced sample cadence, and labels itself as browser observation rather than certification. Use it to check that a setting change reaches the browser, not to verify a manufacturer's spec.

How to test a polling change honestly

1. Confirm the new setting in the maker's software, then check it in the polling tool.
2. Keep everything else fixed: mouse, port, display refresh, browser, power mode and posture.
3. Run several visual-test sessions per setting in an A-B-B-A order, and compare medians and spread, not best trials.
4. If the difference is smaller than your run-to-run spread, call it inconclusive.

Sensitivity is a separate setting from polling rate. For that, read eDPI and cm/360 explained.

Sources & context

Polling definitions and transport: Logitech's polling rate explainer, Microsoft's USB_ENDPOINT_DESCRIPTOR reference, Microchip's developer guide to USB frames and microframes, and Razer's HyperPolling page. CPU cost: Corsair's higher polling rates guidance and TechPowerUp's 4000 Hz closer look, which is one review of one mouse, not a general benchmark. Browser events: MDN on pointerrawupdate and getCoalescedEvents. The interval and average-wait figures are arithmetic from 1000 / Hz, not measurements. See how we measure for how WiredReflex timestamps input.