Why this article exists

Every browser-based “polling rate checker” — ours included — measures delivered pointer events, not USB reports. That’s honest data about the event path, but the wire-level number lives where JavaScript can’t reach. Here are the methods that do reach it, in increasing order of effort and certainty.

Method 1 — Vendor software (what it’s set to)

Logitech G HUB, Razer Synapse, SteelSeries GG, Corsair iCUE, Pulsar and Lamzu’s tools all show the configured polling rate. Fast, free — but it’s the setting, not the delivered rate. A mouse set to 1000Hz that sags to 700Hz under movement will still say “1000Hz” here. Use this to confirm configuration; use the methods below to confirm reality.

Method 2 — Raw-input desktop tools (closest software truth)

Windows mouse-rate checker utilities read Raw Input / DirectInput — the HID report stream before the desktop’s frame-aligned event coalescing. They show real reports-per-second as you move the mouse, unconstrained by any browser cap. This is the practical method for most people: free, a 30-second test, and it answers “is my mouse actually delivering the rate it’s set to?” A steady circle on the pad should hold the rate flat within a few percent; visible sag or spiky readings are real findings.

On Linux, evhz and similar tools do the same job against evdev — report events straight from the kernel input layer.

Method 3 — USB capture: usbmon / Wireshark (the wire itself)

Linux exposes USB traffic to userspace via usbmon:

1. Find the mouse’s bus/device with lsusb.
2. Load the module: sudo modprobe usbmon.
3. Capture: sudo wireshark -i usbmon<N> (N = the bus number) or cat /sys/kernel/debug/usb/usbmon/<N>u.
4. Move the mouse steadily for 10 seconds. Count interrupt-IN URBs per second — that is the hardware polling rate, measured on the wire with zero estimation.

This is the same data a $1000 hardware analyzer shows, minus the box. Windows equivalents (USBPcap for Wireshark) capture the same USB layer.

Method 4 — Hardware analyzers and scopes (when nothing else counts)

• USB protocol analyzers (dedicated hardware between mouse and host) timestamp every packet — the gold standard for validating a claimed 8000Hz implementation.
• Logic analyzers / oscilloscopes on the cable’s data lines or on the encoder pins measure report intervals at the electrical level — how reviewers verify whether “8kHz” mice actually sustain 8kHz.
• High-speed cameras (1000fps+) filming cursor + physical mouse together measure end-to-end motion latency rather than report rate — the method behind publications like NVIDIA’s LDAT rig and hardware-review latency numbers.

What to trust

Claim	Trust level
Vendor software “polling rate”	The setting — not the delivery
Browser test ~60–144Hz	Real, but it’s the frame cap — see the tester’s honesty note
Raw-input tool ~1000Hz steady	Real delivered rate at the OS
usbmon/Wireshark packet count	Wire truth — the actual polling rate
Oscilloscope on the wire	The last word — what reviewers use

If your captured rate disagrees with the box, believe the capture. And once you’ve confirmed the hardware rate, our tester still earns its place — it shows how much of that stream survives the trip through the OS and the browser to a real web page, which is the number every web app you use actually sees.

Frequently asked questions

How do I check my mouse polling rate on Windows?

Easiest: the vendor software — Logitech G HUB, Razer Synapse, SteelSeries GG show the configured rate under sensitivity/polling settings. For the real delivered rate, use a raw-input desktop tool (a mouse-rate checker reading Raw Input/HID directly, which bypasses the browser's frame cap) while moving the mouse in circles.

How do I check polling rate on Linux or macOS?

Linux has the cleanest answer: sudo wireshark -k -i usbmonN or usbmon capture on the mouse's bus shows actual HID report packets — count them per second and that's the wire truth, no estimation involved. On macOS there's no usbmon equivalent exposed as easily; vendor software or a hardware analyzer is the practical route.

Why do browser mouse rate tests show ~60Hz?

Because that's all a page can see — browsers deliver pointer events once per animation frame and coalesce the rest. On a 60Hz display the delivered rate caps near 60Hz regardless of hardware polling; Chrome's getCoalescedEvents recovers sub-frame samples up to roughly ~1kHz. Our tester labels this honestly as the browser-observed rate.

My mouse is set to 1000Hz — is it really delivering 1000Hz?

Configured ≠ sustained. Under real movement some mice sag below the set rate (cheap sensor/MCU combinations), and power-saving wireless modes throttle the report rate deliberately. A usbmon capture or hardware analyzer shows the actual packets per second — the number that counts.