Why a 1000 Hz Mouse Reads Lower in the Browser Than Its Setting

A 1000 Hz mouse is configured to send a position report every 1 millisecond. When you run a browser-based test, the median reading often lands a little below the setting. This is not a defect. It is the expected result of how operating systems and browsers process input.

The mouse sends USB reports to the host controller at its configured rate. The operating system receives those reports, processes them through the HID stack, and queues pointer events for the browser. The browser then delivers those events to the page. Each step adds a small amount of timing variation.

By default, browsers align pointermove delivery to the display refresh cycle. On a 144 Hz display, the browser produces at most 144 event batches per second. Each batch can contain multiple coalesced samples — the intermediate positions that occurred between frames. The getCoalescedEvents method on PointerEvent returns those intermediate samples with their original timestamps. This site uses that method to count every sample the browser received.

Even with coalesced events, the timestamps come from the browser event loop. The OS scheduler, USB host controller interrupts, and browser garbage collection all introduce jitter. A 1 ms reporting interval leaves almost no margin. If the OS delivers a batch 1.1 ms after the previous one, that 1-second window counts as roughly 909 Hz. Occasional interrupts from other devices, CPU frequency scaling, or background activity can push individual windows lower still. The median across 30 seconds usually lands just under the setting.

This undershoot is normal. It does not mean the mouse is faulty, the cable is bad, or the setting failed to apply. It means the browser observed the rate after the full software stack processed it. The test labels every result “browser-observed” for this reason.

The pointerrawupdate event on Chromium-based browsers delivers samples that are not frame-aligned. They arrive as soon as the browser processes them, with their own timestamps. This can produce a higher observed rate than the coalesced path on the same hardware. However, even pointerrawupdate has a ceiling — the maximum number of distinct timestamps the browser can produce per second. When the observed rate reaches that ceiling, the test shows a “Browser-limited” banner.

For 4000 Hz and 8000 Hz mice, the gap is much larger. A 4000 Hz mouse reports every 0.25 ms. An 8000 Hz mouse reports every 0.125 ms. The OS USB stack, the display pipeline, and the browser event loop cannot reliably distinguish timestamps at that granularity on every system. Coalesced events help, but the number of distinct timestamps per second is capped by the browser ceiling. The real hardware rate may be higher; the browser simply cannot observe it.

No browser-based test can distinguish a hardware fault from a software-stack limit. If your 1000 Hz mouse reads 600 Hz, that is outside normal undershoot and suggests interference, low battery, receiver distance, or USB contention. The troubleshooting section of the browser guide lists steps to isolate the cause.

The key point: a browser reading is an observation of the software pipeline, not a measurement of the hardware timer. The gap between the setting and the reading is expected and varies by browser, display refresh rate, and system load.

Display refresh rate plays a direct role. A 60 Hz display refreshes every 16.7 ms. A 240 Hz display refreshes every 4.2 ms. The browser’s default frame alignment means the maximum observable rate without coalesced events cannot exceed the display refresh rate. With coalesced events, the browser can report intermediate samples, but the timestamps are still quantized by the browser’s internal timer resolution. This is why the same mouse on the same system can show different medians when the display refresh rate is changed.

The warm-up period in this site’s test discards the first 300 ms after the test starts. The first few hundred milliseconds often include browser initialization, event-loop settling, and the first display frame alignment. Discarding that window prevents an artificially low first window from pulling down the median.

Duplicate timestamps are also deduplicated. If the browser delivers two samples with the identical timeStamp, only the first counts. This prevents a single event from inflating the rate.

The variation percentage shown in the results — coefficient of variation across 1-second windows — captures how much the observed rate swings from window to window. A low variation means the undershoot is consistent. A high variation means something is interrupting the pipeline: wireless interference, USB contention, or CPU saturation.