The arithmetic first

Setting	Interval	Average wait (½ interval)
125Hz	8ms	~4ms
500Hz	2ms	~1ms
1000Hz	1ms	~0.5ms
4000Hz	0.25ms	~0.125ms
8000Hz	0.125ms	~0.0625ms

The jump 125→1000Hz saves ~3.5ms of average report delay — that one you can measure and, in a flick, plausibly feel. The jump 1000→8000Hz saves ~0.44ms. Everything else in this article is the argument about whether 0.44ms matters.

Where 0.44ms sits in the bigger picture

A mid-range competitive setup already carries roughly: mouse switch + debounce ~2–8ms, OS + game input sampling ~0.5–4ms, render + present a frame or two at your refresh rate (8.3ms at 120Hz, 4.2ms at 240Hz), display processing ~1–10ms. The input lag chain totals it — the polling slice shrinks from ~0.5ms to ~0.06ms while everything else stays put. It’s a real improvement sitting inside a rounding error.

There’s one corner where it’s not a rounding error: 240Hz+ displays. At 360Hz a frame is 2.8ms; at 500Hz, 2ms. When the display itself updates every couple of milliseconds, sub-millisecond report intervals stop being silly — the finer the sensor stream, the closer each displayed frame sits to true current position. That’s the honest case for 8000Hz: not “feel the speed”, but feeding a very fast display a denser motion stream.

The costs are not theoretical

• CPU/IRQ load. Every report is an interrupt. 8000Hz is eight times the interrupt rate of 1000Hz, plus correspondingly more raw-input processing in every listening app. CPU-bound games on mid-range chips can lose measurable FPS or pick up stutter.
• Battery. Wireless polling at 4000/8000Hz shortens runtime substantially — manufacturers’ own specs show the drop (often from ~100+ hours at 1000Hz to a fraction of that at 8000Hz).
• Sustained-rate reality. Some mice advertise 8000Hz but can’t hold it under real movement; a rate that sags or spikes is worse than a locked 1000Hz. And at very slow movements a high-rate mouse emits near-empty reports — tiny deltas that some older games handle badly.

So who should run 8000Hz?

Run it if: your mouse sustains it (verify — don’t trust the box), your display is 240Hz or faster, your CPU has headroom, and you’re the kind of player who already optimizes the rest of the chain. For wireless users, also accept the battery hit or keep a wired fallback.

Everyone else: 1000Hz is the correct answer. Sub-millisecond reports, zero meaningful cost, universally stable. If you’re unsure what your mouse is actually set to — or sustaining — the vendor software shows the configured rate and the hardware measurement guide shows how to verify the real one. Our tester shows what a browser can observe of it — which, per the honesty note, is the delivered fraction only.

Frequently asked questions

Is 8000Hz polling worth it?

For most players, no — the gain over 1000Hz is about 0.44ms of average report delay, roughly one-twentieth of a 120Hz frame. It becomes arguable at 240Hz+ displays in competitive play, where every sub-millisecond is chased deliberately and the PC has CPU headroom to spare. For everyone else, 1000Hz already delivers sub-millisecond reports with no cost.

Does 8000Hz use more CPU?

Yes — interrupt handling scales with report rate. Eight thousand HID reports a second is eight times the per-report kernel/driver work of 1000Hz, plus more frequent wake-ups for every app consuming raw input. On older or heavily loaded CPUs this shows up as stutter or a measurable FPS drop in CPU-bound games. Wireless mice also burn noticeably more battery at 8000Hz.

Can you feel the difference between 1kHz and 8kHz?

Blind tests and community A/B data say: mostly no. The interval difference is under half a millisecond — below the threshold where human motion perception reliably resolves timing, and smaller than the jitter elsewhere in the input chain. What some players report feeling is usually the monitor upgrade, the lighter mouse, or placebo. That's not an insult — it's the honest summary of the data.

Why does 8000Hz sometimes make tracking *worse*?

Two mechanisms. Some mice can't sustain the advertised rate — they drop reports, which is worse than a steady lower rate. And at tiny physical movements per report, 8000Hz can underfill packets (near-empty reports on slow swipes), which some games handle poorly. Checking for a stable rate is exactly what the hardware measurement guide is for.