Mouse Polling Rate Stability, Jitter and Low 5% Explained

The estimator measures browser-visible mouse movement. It cannot check every USB poll or isolate device behavior from the rest of the input path. A score is meaningful only with the capture conditions and its measurement status.

Average starts at the first callback and ends at the current reading or test stop. Initial waiting is excluded; later pauses and trailing idle time remain. Coalesced samples in the first batch can predate that origin, so very short runs have boundary bias.

Consider these two calculated sequences of six complete 500ms arrival windows. Both cover three seconds and have a mean window rate of 1000Hz. These are illustrations, not recorded mouse measurements.

For sequence B, the population variance is (5 × 200² + 1000²) / 6 = 200000. Its standard deviation is about 447.21Hz. Substituting into the site formula gives 100 × (1 − 447.21 / 1000) ≈ 55.28%.

The average remains a useful throughput summary. It simply does not retain the ordering or distribution of delivery. The zero window could come from stopping movement, delayed delivery or another input-path effect. This example cannot tell us which cause occurred.

After the first callback, the estimator divides arrival time into fixed, non-overlapping 500ms windows. Each complete window's update count becomes a rate in Hz. It uses their mean μ and population standard deviation σ to calculate Stability = 100 × max(0, 1 − σ / μ).

All complete windows participate, including slow and empty ones. The last partial window is excluded from Stability and Lowest 500 ms Rate, but its samples and elapsed time still affect Average. Samples in a coalesced batch are assigned to the window in which the callback arrived.

A score of 100% means the complete windows had equal counts. It does not establish perfectly spaced reports inside those windows. Brief stalls or bursts can occur while half-second totals stay equal, and batch delivery near a boundary can change the score.

The denominator is the mean window rate. With eligible captures this is positive; the implementation also guards against zero. The lower clamp prevents a negative score when relative spread exceeds one. No published evidence establishes a universal percentage cutoff for a “good gaming mouse.”

The current test reports the minimum complete 500ms window rate. It does not report a fifth percentile or the average of the slowest 5%. Those statistics answer different questions and must be named separately.

A percentile implementation must specify interpolation or rank rules. A worst-5% mean must specify how many values to select when the sample count does not divide cleanly. A three-second capture has only six complete half-second windows, so 5% corresponds to less than one window. That is a poor basis for a tail estimate.

Working from individual intervals creates another choice. Long intervals are bad in a delay distribution, while low rates are bad in a frequency distribution. Transforming each interval to Hz and averaging is generally different from taking the reciprocal of mean interval. A comparison needs the actual formula, not only the label “5% Low.”

An FPS 1% low describes rendered-frame performance under its own calculation convention. It cannot be substituted for a mouse window-rate statistic. Keep game frame-time measurements separate from browser movement measurements.

Peak is the reciprocal of the shortest resolvable eligible sample interval. One short interval can raise it sharply. It does not establish a sustained rate or confirm an advertised polling setting. Timestamp rounding can distort very short intervals, which is why the estimator checks precision before exposing this metric.

Jitter uses population standard deviation divided by mean interval, expressed as a percentage. It describes interval spread at a finer time scale than Stability. In this estimator, zero intervals, intervals shorter than two estimated clock-grain units, and pauses of 100ms or more do not enter these interval statistics. The excluded pauses can still lower Average and Stability.

Long intervals exceed three times the median of the eligible interval distribution. The count identifies unusual observed gaps; it cannot label them USB packet loss. Different browser delivery paths and precision can make interval metrics unavailable or unsuitable for direct comparison.

For interval metrics, the capture needs valid uninterrupted input, sufficient timing samples, low duplicate-timestamp share and a median interval spanning enough estimated clock units. Read the browser-limits guide when Peak or Jitter is unavailable. Average and window metrics may still be usable.

1. Read measurement status. At least 3 seconds and 100 samples are needed for quality metrics. Browser limits, interruptions and invalid samples change what can be concluded.
2. Check the average and movement conditions. Compare captures at the same configured rate, DPI and similar continuous motion. Do not compare a paused run with an uninterrupted run as if only the mouse changed.
3. Check the complete-window pattern. Read Stability and Lowest 500 ms Rate together. A poor window result calls for repeat testing and investigation.
4. Use interval metrics when available. Peak, Jitter and long intervals provide additional timing detail, subject to the stated filters and clock limits.
5. Test gaming effects separately. Use repeatable game frame-time captures and an appropriate latency measurement if that is the question you want to answer.

A stable browser capture is evidence about that capture. To attribute a difference to hardware, repeat the comparison and use an independent reference appropriate to the claimed measurement layer.

Frequently asked questions