Polling rate vs response time: what's the difference?

Keyboard and mouse marketing often talks about polling rate and response time as if they were the same thing. They are not. Polling rate is one ingredient of response time — an important one, but only one — and confusing the two is how people end up paying for speed they cannot feel. Here is the distinction, plainly.

Polling rate: how often the device reports

Polling rate, measured in hertz (Hz), is how many times per second a keyboard or mouse reports its state to the computer. The report interval is simply 1000 divided by the rate: a 125 Hz device reports every 8 milliseconds, a 250 Hz device every 4 ms, a 500 Hz device every 2 ms, a 1000 Hz device every 1 ms, and an 8000 Hz device every 0.125 ms. When you press a key just after a report has gone out, your press waits until the next report before the computer even hears about it — so the polling rate sets a ceiling on one slice of delay, never the whole delay.

You can check what your own devices are doing with the free keyboard and mouse polling rate test. One honest caveat, which the tool states on the page: a browser cannot read a keyboard's USB report rate directly — it only sees key events when a key changes state — so keyboard mode measures your key event rate in the browser. Mouse mode is closer to a hardware reading, because continuous movement produces a stream of events at the mouse's report rate.

Response time: the whole journey of a keypress

Response time — sometimes called input latency or end-to-end latency — is the total time from your finger pressing a key to the result appearing on screen. It is a chain, and polling is just one link:

1. Switch actuation. The physical switch registers the press. Different switch designs actuate at different travel depths, which changes how early in the press the signal starts.
2. Debounce and scanning. Mechanical switches bounce electrically when they close, so the keyboard's controller waits briefly to confirm the press is real, and it scans its key matrix on its own cycle. This adds a small delay before any report is even prepared.
3. The USB report wait. This is where polling rate lives. The prepared report waits for the next scheduled report slot — up to 8 ms at 125 Hz, up to 1 ms at 1000 Hz.
4. Operating system and application processing. The OS receives the report, delivers it to the game or application, and the application acts on it. Background load and the application's own frame timing add delay here.
5. Display lag. The rendered frame waits for the monitor's next refresh, and the monitor itself takes time to show it. On a 60 Hz display, a frame can wait up to about 16.7 ms for the next refresh alone — more than the entire polling delay at any common rate.

That chain is why a single Hz number can never describe how responsive a setup feels. A 1000 Hz keyboard on a slow display with a busy system can feel slower than a 500 Hz keyboard on a fast, unloaded setup.

Where the gains shrink

The arithmetic shows why upgrades have diminishing returns. Moving from 125 Hz to 1000 Hz cuts the maximum report wait from 8 ms to 1 ms — a 7 ms improvement, which is genuinely noticeable in fast games. Moving from 500 Hz to 1000 Hz saves at most 1 ms. Moving from 1000 Hz to 8000 Hz saves at most 0.875 ms — less than a millisecond, and a fraction of the delay added by the display alone. That is also why very high polling rates can cost more CPU: the computer is woken thousands of extra times per second for a sub-millisecond gain. For most players, 1000 Hz is the sensible ceiling; above it, money and attention are usually better spent on a faster display or a cleaner system.

Related terms people mix up with polling rate

• DPI (mouse): sensitivity — how far the cursor moves for a given physical movement. It has nothing to do with how often the mouse reports. A high-DPI mouse can still poll at 125 Hz, and a low-DPI mouse can poll at 1000 Hz.
• Refresh rate (monitor): how often the display redraws, in Hz. It uses the same unit, which invites confusion, but it governs the last link of the chain (display lag), not the keyboard or mouse.
• Key repeat rate: how fast a held key repeats characters, set by the operating system at roughly 30 times per second. If a browser test shows about 30 Hz while you hold one key, that is the repeat rate — not your keyboard's polling rate, and not a fault.
• Debounce time: the controller's confirmation delay for a switch press. It is part of response time but is separate from polling rate, and it is why two keyboards at the same Hz can still feel different.

The practical takeaway

Think of polling rate as the reporting schedule and response time as the delivery time. Check the schedule with a test, but judge the delivery by the whole setup: the keyboard's switches, the connection (wired or a good 2.4 GHz link rather than Bluetooth), the system's load, and the display. If your polling rate is already 500–1000 Hz, the next improvement to chase is almost never more hertz.

Frequently asked questions