You switched the mouse from 1 000 Hz to 8 000 Hz, expecting the aiming to feel different, and it does not. Or worse, it feels slightly less smooth than before, with occasional hitches that were not there yesterday. Both outcomes have the same explanation, and it has nothing to do with the mouse being bad. Above a certain rate, the extra reports arrive during an interval in which your screen cannot change.
Two clocks that do not agree
A polling rate is how often the computer asks the mouse where it is. At 1 000 Hz that question is asked every 1 ms. At 8 000 Hz, every 0.125 ms.
A refresh rate is how often the display can show you something new. At 144 Hz a new frame appears every 6.94 ms. At 240 Hz, every 4.17 ms. At 360 Hz, every 2.78 ms.
Divide one by the other and the mismatch is obvious. On a 240 Hz display polled at 1 000 Hz, the computer already receives 4.17 mouse reports per frame. Raise the mouse to 8 000 Hz and it receives 33 reports per frame — thirty-three positions competing to be represented by one image. Thirty-two of them will never be drawn as their own picture.
This is not an argument that polling rate does nothing. It is a statement about where its effect actually lives: not in smoothness, which the frame rate owns, but in the wait between moving the mouse and the next opportunity for that movement to be noticed.
What faster polling actually buys
The gain is the shortening of that wait. At 1 000 Hz, a movement that happens just after a poll waits up to 1 ms for the next one and, averaged over random timing, about 0.5 ms. At 8 000 Hz the same wait averages 0.0625 ms.
Independent latency testing puts the theoretical improvement in click-to-photon time from 1 000 Hz to 8 000 Hz at about 0.875 ms. That is the honest number, and it is worth holding onto, because the marketing around 8 K polling implies something categorical while the measurement describes something under a millisecond.
Now put it against the whole chain. Measurements of complete system latency — click to the photon that leaves the panel — come in at roughly 21 ms on a 144 Hz display, 24 ms at 120 Hz, and 52 ms at 60 Hz. Against 21 ms, saving 0.875 ms is a 4 per cent improvement in the thing you actually experience.
The number that reframes it
Percentages of total latency are the standard way to dismiss high polling rates, and they undersell the mechanism. Here is a better way to think about it, and it is our own arithmetic rather than anybody's specification.
Your movement only becomes visible when a frame is drawn. So the question is not "how much latency did I save" but "how often does that saving move my action into an earlier frame". A saving of 0.875 ms matters exactly when it lands across a frame boundary, and the chance of that is the saving divided by the frame interval:
- At 240 Hz, 0.875 ÷ 4.17 — roughly 21 per cent of the time.
- At 144 Hz, 0.875 ÷ 6.94 — roughly 13 per cent.
- At 60 Hz, 0.875 ÷ 16.7 — roughly 5 per cent.
So 8 K polling is not "always a millisecond faster". It is "one frame earlier, one time in five, on a 240 Hz screen" — and one time in twenty on a 60 Hz one. That is a real effect with a real bound, and it explains why the change is so hard to feel: four times out of five, the identical frame appears at the identical moment.
The cost side, which is not zero
Eight thousand reports per second is eight thousand interrupts per second for the host to service, and that work has to happen somewhere.
Reported overhead runs from about 1 to 3 per cent of CPU on current hardware, rising to 2 to 5 per cent per core on older or mid-range processors. In a game that is already limited by the processor rather than the graphics card, that overhead is not spread evenly across a comfortable margin — it lands on whichever thread services the interrupts, and if that thread is the one running the game's simulation, the result is frame-time variance rather than a lower average frame rate.
Which produces the outcome at the top of this article. A player upgrades polling on a CPU-bound shooter, gains a 13 per cent chance of a frame's worth of latency, and pays for it with occasional stutter — a change that is far easier to perceive than 0.875 ms, and in the wrong direction.
There is a second, quieter cost on shared USB. Eight thousand reports per second consume host-controller scheduling that other devices on the same controller also need, which is why two 8 K mice on one root hub is a documented way to find the limits of a chipset.
Reports are not measurements
One distinction is worth holding onto, because a good deal of marketing lives in the gap. The polling rate is how often the host asks. The sensor's own frame rate is how often the mouse looks at the surface. These are two clocks, and a report can only ever carry information the sensor has already gathered.
When the host asks faster than the sensor produces new information, the additional reports carry either a repeated position or a smaller slice of the same movement. Neither tells the computer anything more about where your hand went. What changes is when the existing information arrives — which is exactly the sub-millisecond effect measured above, and nothing beyond it.
Where the milliseconds actually are
If the 21 ms figure above is the budget, it is worth knowing which line items are large enough to be worth attacking.
- Refresh rate. The measured difference between 60 Hz and 144 Hz was about 31 ms — more than thirty times what the polling upgrade offers. This is the single largest item most people can buy.
- Frame rate and the render queue. A game running at 60 fps holds each frame for 16.7 ms regardless of the panel. Queued frames waiting to be presented add their own delay, which is what the latency-reduction modes in modern drivers exist to drain.
- Panel response and processing. The display's own pipeline sits between the finished frame and the photon, and it varies by more between models than any polling setting varies at all.
- Polling. Real, bounded, and last on this list by an order of magnitude.
The recommendation, including when not to buy
If you play on a 144 Hz display, or your game is limited by your processor, do not pay extra for 8 000 Hz polling. You would be buying a 13 per cent chance of one frame's advantage and paying for it with an interrupt load that lands exactly where you can least afford it. Set the mouse to 1 000 Hz and spend the money on the display or the processor instead.
If you already own the mouse and the machine has headroom — a high-refresh panel, frame rates comfortably above the refresh, a processor that is not the limit — then raise it and keep it. The gain is small and real, and the cost in that configuration is genuinely negligible.
What nobody should do is treat the setting as free. It is the rare specification where the higher number carries a measurable price in stability, and where the benefit is capped by a clock the mouse cannot influence.
The check that takes a minute
Play twenty minutes at 8 000 Hz with a frame-time graph on screen, then twenty minutes at 1 000 Hz with the same settings and the same map. You are not looking at average frame rate, which will barely move. You are looking for spikes in frame time and for the 1 per cent low figure.
If those are identical, the polling rate is costing you nothing and you may as well keep it. If the spikes appear only at 8 000 Hz, you have just measured the trade directly on your own machine, and the arithmetic above tells you what you are giving up by going back: about one frame in five, on a 240 Hz panel, and less on anything slower.
How this was put together
Five independent sources sit under the figures above: laboratory latency testing of gaming mice that puts the 1 000 Hz to 8 000 Hz improvement at roughly 0.875 ms in click-to-photon terms; the polling intervals themselves, 1 ms and 0.125 ms, as specified; measured whole-system latency figures of about 21 ms at 144 Hz, 24 ms at 120 Hz and 52 ms at 60 Hz using a photon-sensing analyser; reported CPU overhead for 8 000 Hz polling of 1 to 3 per cent on current processors and 2 to 5 per cent per core on older ones; and documented reports of frame-time variance in CPU-bound titles when interrupt load lands on the game's thread.
The derived figures are ours: the 4.17 and 33 reports per frame at 240 Hz for the two polling rates; the average waits of 0.5 ms and 0.0625 ms; and the frame-boundary probabilities — 21 per cent at 240 Hz, 13 per cent at 144 Hz, 5 per cent at 60 Hz — that turn a sub-millisecond saving into a statement about how often you actually see it.
