8000 Hz mice on Windows: what the polling rate really costs
How USB polling and Windows input work, what changes at 1000/4000/8000 Hz, and how to tell whether it helps or just burns CPU.
- Build
- 26300.9457
- Edition
- Pro (26H2)
- Architecture
- x64
- Support
- Documentation (E1)
- Evidence
- E1Official documentation
- Verified
- 2026-10-29
- Page type
- Concept
The short answer
Section titled “The short answer”A mouse reports its position at a fixed interval: 1000 Hz = every 1 ms, 8000 Hz = every 0.125 ms. Higher rates reduce input sampling latency — the worst case is one full interval.
Whether that matters depends on the whole chain:
| Stage | Typical latency |
|---|---|
| Mouse sensor + firmware | ~1 ms or less |
| USB polling interval | 1 ms at 1000 Hz, 0.125 ms at 8000 Hz |
| Windows input stack | sub-millisecond to a few ms |
| Game engine + render queue | often 10–30 ms |
| Display scanout | 4–16 ms |
Improving the 1 ms stage while the render queue is 20 ms is measurable in a lab and invisible in play.
What actually costs you
Section titled “What actually costs you”- CPU: at 8000 Hz the device generates 8000 interrupts/second. On a fast desktop that is tolerable; on a laptop it is measurable battery drain.
- USB controller sharing: a high-rate mouse on a hub shared with a keyboard and audio can cause dropped reports.
- Older games may poll input once per frame anyway, so the extra reports are dropped.
Windows exposes raw input so applications can read reports without the pointer-acceleration pipeline — but the application still has to ask.
Check what you have
Section titled “Check what you have”Get-PnpDevice -Class HIDClass | Select-Object FriendlyName,Status,InstanceIdGet-CimInstance Win32_PointingDevice | Select-Object Name,Manufacturer,NumberOfButtons,StatusThe polling rate itself is usually set in the vendor’s software and stored on the device. Windows does not show it in a supported UI.
For raw input behaviour, some games expose a “raw input” toggle — that bypasses Windows pointer acceleration and the desktop cursor pipeline.
Where high polling rate helps
Section titled “Where high polling rate helps”- High-refresh displays (240 Hz+): the sampling interval becomes a larger fraction of the frame time.
- Fast flick shots / tracking: more samples per frame means less positional error.
- Low-latency setups: when the rest of the chain is already optimised.
Where it does not:
- 60 Hz displays — one frame is 16.7 ms, so 0.125 ms sampling is noise.
- Office work — no perceptible difference, only battery cost.
- Wireless mice in power-saving mode — the radio link, not USB polling, is the bottleneck.
Mouse acceleration is the bigger variable
Section titled “Mouse acceleration is the bigger variable”Windows pointer acceleration (the “enhance pointer precision” setting) changes cursor movement non-linearly. Competitive players disable it; office users often prefer it.
For raw input in games, acceleration is bypassed by the application, so the OS setting matters less — but the desktop cursor still uses it.
Practical recommendations
Section titled “Practical recommendations”- Default 1000 Hz is the right choice for almost everyone.
- 2000–4000 Hz is reasonable on a desktop with a high-refresh monitor.
- 8000 Hz only if the CPU has headroom, the mouse is wired, and the display is 240 Hz+.
- Wireless: prefer a dedicated dongle on a front port over Bluetooth, regardless of polling rate.
Related
Section titled “Related”Lab boundary
Section titled “Lab boundary”E1. HID and raw-input architecture is documented by Microsoft; polling-rate behaviour is a device/USB property. The lab has no physical mouse, so no latency was measured and no comparative numbers are claimed.