The short answer
Twelve seconds is long enough for a rare spike to show up and short enough that people actually finish it.
The longer one
The interesting events are not the average — they are the rare ones. A driver that holds a core for 5 ms once every few seconds is exactly the kind of thing that causes a stutter you notice and a benchmark you do not. To see something that happens every few seconds, the window has to be several times longer than that gap.
Three seconds would catch the average and miss the spike, which would produce a clean result on a machine with a real problem. That is the worst outcome a measurement can have.
Thirty seconds would catch more. It would also be a page most people abandon halfway, and an abandoned measurement measures nothing.
Why it has to be your movement
The mouse rate is taken from the raw input stream: one report per movement, as the device sends it. No movement, no reports, nothing to measure.
Timing Windows' ordinary mouse events would not work either. Those are delivered through the message pump, which coalesces them down to roughly the interface's own rate — a 1000 Hz mouse and a 125 Hz mouse look identical through it. That is a real bug this feature had, and reading raw input is the fix.
Do it right
- Move the mouse continuously, the way you would in a game — not one slow drag across the desk.
- Leave the machine otherwise as it normally is. Closing everything first measures a machine you never actually use.
- Run it again afterwards to compare. The page keeps your last runs and shows the change; a difference under 5% is reported as no change, because that is inside the noise.
Related
Did this page help?
What was missing, or what did not work? We read every one of these.
If this page did not solve it, write to us — say which article you read, and we will fix the article.