How to Read a Polling Rate Stability Graph
Published October 12, 2026
The stability graph is the centerpiece of the mouse polling rate test. It plots the 1-second window rates across the test session. This post explains each element so you can read it confidently.
The horizontal axis is time in seconds. The vertical axis is the observed rate in Hz for each 1-second window. The test uses fixed consecutive 1-second windows. The first 300 ms after the test starts are discarded as warm-up. The first plotted window covers roughly 0.3 s to 1.3 s.
The line connects the window rates. Each point is the unique sample count for that window. Samples with identical timestamps are deduplicated — only the first counts.
Below the graph, a summary table shows:
- Median: the middle value of all completed windows. Half the windows are above, half below. This is the best single summary because it is robust to brief spikes or drops.
- Mean: the average across windows. It is pulled by spikes and drops. If the mean is much higher than the median, there are upward spikes. If much lower, there are deep drops.
- Min / Max: the lowest and highest 1-second window observed. A single deep drop can pull the min far down even if the rest of the session is steady.
- Variation: coefficient of variation (standard deviation divided by mean, expressed as a percentage). Lower is steadier. A perfectly steady 1000 Hz session would show 0% variation. Wired connections remove radio interference and battery throttling as variables, generally yielding lower variation than wireless setups in identical conditions.
- Class label: the nearest standard rate (125, 250, 500, 1000, 2000, 4000, 8000 Hz) shown only when the median sits within ±10% of that class and the window rates stayed inside that band for at least 3 consecutive seconds (three successive windows). If either condition fails, the test shows the observed median Hz with no class label.
- Browser-limited banner: appears when the observed rate reaches the browser’s measured ceiling for distinct timestamps per second. The real hardware rate may be higher.
The graph shades two bands:
- Drop windows: any window below 80% of the session median is shaded as a drop. For a 1000 Hz median, windows below 800 Hz are shaded. These are moments where the browser received far fewer samples than typical.
- Spike windows: any window above 120% of the session median is shaded as a spike. For a 1000 Hz median, windows above 1200 Hz are shaded. These are moments where the browser received more samples than typical — often due to timestamp clustering or a catch-up burst after a drop.
Patterns and what they suggest (without diagnosing hardware faults):
- Occasional single-window drops: normal. OS scheduler, interrupt handling, or a brief pause in movement can cause one window to dip. If drops are rare and isolated, the connection is likely healthy.
- Repeated drops every few seconds: suggests a periodic interference source or a power-saving behavior. Wireless mice with low battery sometimes throttle periodically.
- Clusters of drops: suggests sustained interference, a loose receiver, or CPU saturation. Check background apps.
- Spikes immediately following drops: common. The browser may deliver a burst of coalesced samples after a gap, inflating the next window.
- Steady line with low variation: the mouse is delivering reports consistently through the full software stack. This is what you want.
- Sawtooth pattern (regular up-down): can indicate a display refresh interaction or a USB scheduling artifact. Compare with a different display refresh rate.
The numeric table alternative (provided for screen readers and prefers-reduced-motion) lists every window rate. You can copy it for offline analysis.
Comparing two runs fairly:
- Use the same browser (Chrome or Edge recommended for coalesced and raw pointer support).
- Use the same display refresh rate (set both to 144 Hz, 240 Hz, etc.).
- Run each test for the same duration (30 seconds minimum).
- Move both mice in a similar smooth pattern (circles or figure-eights).
- Close the same background apps for each run.
- Record the median, variation, and whether the class label appeared.
- If one mouse shows “Browser-limited” and the other does not, the limited one may have a higher real rate that the browser cannot observe.
The copy-to-clipboard button writes a plain-text summary with all these fields plus the browser name and test duration. Paste it into a text file to keep a record.
The graph animation respects prefers-reduced-motion. If you have reduced motion enabled in your OS, the line draws instantly without animation.
The stability graph shows what the browser observed. It does not measure the mouse firmware, the USB packets, or the hardware timer. A drop in the graph means the browser received fewer samples in that window. The cause could be the mouse, the cable, the receiver, the USB port, the OS, or the browser. The troubleshooting section of the browser guide lists steps to isolate the cause.
Sources
W3C — Pointer Events Level 3
https://www.w3.org/TR/pointerevents3/
Last checked 2026-10-12
MDN Web Docs — PointerEvent.getCoalescedEvents()
https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents
Last checked 2026-10-12
MDN Web Docs — Element: pointerrawupdate event
https://developer.mozilla.org/en-US/docs/Web/API/Element/pointerrawupdate_event
Last checked 2026-10-12
W3C — UI Events Specification
https://www.w3.org/TR/uievents/
Last checked 2026-10-12
URLs are listed as plain text. This site does not link out to other sites.
Last reviewed 2026-10-12