In 2026, Logitech unveiled a $180 mouse carrying an 8000Hz polling rate, and Razer followed shortly after with a similar claim. The spec sheet looks impressive: a thousand reports per millisecond, tracking micro-movements that a human eye cannot consciously perceive. The Windows polling rate meter agrees, and the manufacturer’s review unit under ideal test conditions does too. But the moment you move that same mouse into a browser and let CapyToolkit’s Input Lag & Mouse Polling Rate Tester run its PointerEvent analysis, the number often looks very different.
This article will give you a working model of where your Hz number actually comes from, what headroom exists between the rated spec and what you observe locally, how to read a polling chart for signs of hardware or power-management problems, and most importantly, how to walk away from a purchase that overpromises in polling rate. By the end, you will have a clear sense of which number to trust and why that 8000Hz marketing claim is only half the story.
The 1000Hz Ceiling Your Browser Imposes
An 8000Hz mouse sends eight thousand position updates per second to the operating system, but your browser does not deliver all eight thousand of those events to JavaScript. Chromium and Firefox both cap main-thread PointerEvent delivery at around 1000 events per second regardless of the upstream hardware rate.1 The W3C Pointer Events specification defines the event model browsers implement; how aggressively each implementation delivers those events to your JavaScript is a separate decision.2 What you see from a browser-based tool is an OS-layer measurement rather than a direct measurement of the sensor’s raw polling frequency, and that distinction is what makes a number of marketing claims technically accurate but practically misleading.
Inside the browser, the OS schedules input events, and the browser coalesces rapid events to avoid overwhelming the main thread. Even when a high-polling-rate mouse is active, rapid PointerEvent delivery rises only while the pointer sits inside an active PointerEvent listener. Beyond that zone, browsers revert to their normal composite caps of 60 to 125 events per second. For competitive players chasing sub-2 millisecond response, the gap between 125 Hz and 1000 Hz matters. The gap between 1000 Hz and 8000 Hz is measurable on a chart but sits well above the perceptible threshold for most humans, who cannot reliably distinguish sub-millisecond response differences in real play.3 For a breakdown of each Hz tier and what the extra microseconds cost in latency, see USB polling rate explained from 125 Hz to 8000 Hz.
Browsers and PointerEvent delivery
On Windows, Chromium typically delivers at most around 1000 PointerEvents per second to a listener regardless of the connected hardware’s polling rate. Higher polling rates (2000 Hz, 4000 Hz, 8000 Hz) require the browser to support the getCoalescedEvents() API, which exposes the intermediate events the browser would otherwise merge. CapyToolkit’s Input Lag & Mouse Polling Rate Tester reads only the primary event timestamp from each delivery, so a 4000 Hz mouse reading as 1000 Hz in the chart is expected browser behavior, not a defective mouse.4 The OEM’s spec sheet measures under firmware, chipset, and port conditions most users do not replicate at home.
Your browser delivers the number CapyToolkit’s Input Lag & Mouse Polling Rate Tester plots because browsers treat input as a throttled stream rather than a firehose. Every stage from USB bus scheduling to the main thread introduces a slight delay or discard; the tool sums those delays into a single number you control. If that number sits near 1000 Hz with a flat line while your mouse box claims 8000 Hz, the browser cap has been hit. The hardware itself may be working perfectly.
The Full Polling Stack: From USB-Cable to PointerEvent
To solve where in the signal chain the bottleneck lives, you first need to map every hop your mouse position takes from the sensor to the screen. The path from your hand moving the mouse to a colored dot shifting on screen passes through several independent subsystems, each of which can limit the end-to-end rate. An optical sensor captures positional changes at the µcontroller polling rate, the firmware bundles those readings into USB HID packets, the USB controller schedules transmission to the OS, the OS scheduler delivers input events to browser processes, and the browser’s main thread renders the resulting PointerEvent. If any stage introduces a hard cap, the cap becomes the number your browser reports. For the first three stages, polling rate definition and how 125 Hz, 1000 Hz, and 8000 Hz compare covers the basics; for how long it takes between a physical button press and the operating system registering it, click latency from button press to the OS is the right read.
Between every stage in the signal chain, a small low-pass filter delays the physical movement before the browser event timestamp arrives. Sensor backlight refresh and internal debounce timing constrain the raw sensor rate. Wikipedia’s article on polling rate covers the mechanical and electrical basis behind these intervals at polling rate on Wikipedia. Through finite USB HID packet sizes, the OS sees discrete sampling intervals rather than a continuous stream. The browser schedules PointerEvent delivery on the main thread’s rendering frame. Each step looks small on its own, but they stack into the ±5 percent variance a browser tool reports compared with an OEM’s ideal numbers.
Think about this as a series of narrow funnels feeding a single pipe. The first funnel may pass 8000 individual readings per second, but if a USB hub on the same bus is also streaming HD webcam frames, that hub’s bucket fills faster and the scheduler slows your mouse updates down. The OS adds another funnel when it merges rapid events to save CPU cycles. To keep JavaScript from freezing the tab, the browser adds a final funnel of its own. The Input Lag & Mouse Polling Rate Tester reads the flow right after that last bottleneck; everything upstream of it remains invisible in a browser chart.
Where to Look for ΔReal vs ΔRated
What the box claims and what your browser shows is the gap worth optimizing. A clean 30-second measurement with the cursor sweeping inside the tracking zone of CapyToolkit’s Input Lag & Mouse Polling Rate Tester exposes the truth of your actual setup. Three specific checks reveal whether the gap comes from the device itself, your USB topology, or your OS configuration.
First, run the tool with the mouse connected to a dedicated rear motherboard USB port. Leave the cursor still for 10 seconds, then move at a steady pace for 30 seconds while the tool samples PointerEvents. A stable curve on the chart within ±5 percent of the advertised Hz validates the product. A seesaw between 8000 Hz and 1000 Hz suggests an OS or power-management cap, not a faulty sensor.
Second, cross-check on a second bus: move the same mouse to a front-panel USB-C header and re-measure. If the rear port reads 8000 Hz steady and the front panel header reads 1000 Hz, the front-panel wiring or its controller is the bottleneck. USB hub bandwidth sharing is the most common cause of polling rate drops on consumer desktop machines.
Third, plug in a second high-frequency device simultaneously with an 8K gaming keyboard using the same polling protocol, then observe whether the Hz number drops on either device within seconds. USB bandwidth contention shows up in real time as chart skew. A shared root hub that pipes both devices through the same microcontroller will throttle whichever device was assigned the lower transfer interval when both are under load.
Why manufacturers quote ideal conditions
Rather than reflecting real-world environments, marketing polling rates come from controlled lab benches. To hit a starred number, an OEM measures on a max-performance firmware build, with no other USB devices on the bus, on an Intel reference chipset with IRQ affinity pinned to a single CPU core, at 22 degrees Celsius, with a brand-new optical sensor that has not yet accumulated dust. Because those conditions exist nowhere outside a review sample’s test bench, everyday users will rarely replicate them.
A reviewer who replicates those conditions gets the starred number. An end-user in a room with a USB 3.0 hard drive spinning on the same hub, a Discord call eating CPU cores, and aggressive USB selective suspend enabled gets degraded delivery from the same silicon. On a shared hub, an 8000 Hz mouse often shows lower observed polling because the OS or browser layers below the sensor cap the visible rate. OS schedulers and USB bus contention cause this performance gap, not a physical defect. Re-measuring on CapyToolkit’s Input Lag & Mouse Polling Rate Tester reproduces the same drop in under a minute.
At 125 µs per report, an 8000 Hz sensor reports so fast that most USB bundles and operating system schedulers lose individual readings before they reach the browser. Whether your motherboard’s USB controller, firmware version, and power policy preserve that interval end to end is a separate question, one you can answer from your own desk in under ten minutes without installing any vendor software.
Before filing an RMA based on a low polling rate reading, work through three fixes that cost nothing to try. CapyToolkit’s Input Lag & Mouse Polling Rate Tester measures your mouse’s real reporting rate locally, so running it after each change tells you immediately whether that change restored throughput.
Placement first. Plug the mouse into a dedicated rear motherboard USB port, where the port is wired directly to the motherboard’s USB controller without going through a front-panel header. Front-panel headers, USB-C hub docks, and docking stations share bandwidth with other devices and introduce USB hub scheduling jitter that a polling-rate tool reveals within seconds. USB hub sharing is the single most common cause of polling rate drops on a consumer desktop machine.
Power management second. Windows USB selective suspend and Linux usbcore.autosuspend can cut polling intervals in half under light load.56 Disable USB selective suspend in the Windows power plan: open Control Panel, then Power Options, then Change plan settings, then Change advanced power settings, then USB settings, then USB selective suspend setting: Disable. On Linux, check the active autosuspend value with cat /sys/module/usbcore/parameters/autosuspend and if you see a positive number, add usbcore.autosuspend=-1 to your kernel boot parameters to disable it entirely.
Load discipline. A 4K video stream, a large file copy, and a Discord call collectively starve the USB controller of bus time. Run the test as the only active application. Close games, video streams, and background processes, then re-measure. Heavy CPU or GPU load causes OS scheduler delays that appear in the polling chart as sudden Hz drops or jagged gaps.
What Power Management Does to Hz
The tool’s Longest Gap metric is the clearest signal that something between the sensor and the screen is throttling delivery silently. On a truly stable 1000 Hz setup, a 1 millisecond gap is the boundary between consecutive PointerEvents. If you see a 5 millisecond gap on a mouse rated at 1000 Hz, five times longer than the expected interval, the OS has paused polling for long enough that a full frame of game time elapsed in the gap. That behavior points to power management putting the USB controller in a low-power state between polls.
Controlling USB power states on Windows: Open Device Manager, find your USB Root Hub or Generic USB Hub under Universal Serial Bus controllers, open Properties, go to Power Management, and uncheck “Allow the computer to turn off this device to save power.” Then disable USB selective suspend at the power plan level as described above.
Controlling USB power states on Linux: The suspect is usbcore.autosuspend. With it enabled at a positive value, even 1000, the kernel waits that many milliseconds of inactivity before suspending an idle device. Disable it by adding usbcore.autosuspend=-1 to your kernel boot options, then update-grub (Debian, Ubuntu) or mkinitcpio -P (Arch) and reboot. On macOS, the equivalent is Energy Saver: disable “Put hard disks to sleep when possible” and confirm “Wake for network access” stays enabled to prevent the USB subsystem from entering aggressive low-power states while you game.
What a Stable Reading Actually Looks Like
A clean 60-second measurement with the cursor sweeping inside the tracking zone produces one of several predictable patterns. Knowing which pattern you are looking at saves you from returning perfectly healthy hardware. CapyToolkit’s free browser-based hardware testing tools run entirely on your machine with zero uploads, so you can re-run this test whenever a USB change feels off without installing anything.
A clean 1000 Hz flatline on the chart sits near a constant height with rare red markers sprinkling the polyline. Most red marks appear during bursts of fast movement when the USB controller temporarily coalesces events. On the same scale, a clean 4000 Hz flatline shows four oscillations per unit width, but the line sits equally still between events. Either pattern is healthy as long as it does not staircase or drop to zero.
Persistent red vertical lines indicate real problems. Occasional red drops below 125 Hz during fast sweeps are expected behavior. The USB controller batches deliveries to save bandwidth. Persistent dropouts every few seconds point to a failing USB cable, a bandwidth-contested hub, or power management cycling the port. Watch the chart for 20 seconds with movement paused; if the Hz line drops to zero and then snaps back, the controller is being suspended mid-measurement.
A flat, perfectly stable line that sits at exactly 1000 Hz on a mouse rated 8000 Hz means the browser or OS is the ceiling, not the sensor. The hardware is capable of more, but the browser is not letting it through. Try Chromium with --enable-features=PointerEvents as a command-line flag to override the default main-thread throttle, then re-test. The live Hz chart showing whether your 8000 Hz mouse is reporting at full rate exposes whether the problem lies with the browser cap or the delivery layer. A chart that seesaws between 8000 Hz and lower values indicates a wired or power-management problem, not a defective mouse: the sensor reports multiple rates and the tool catches the variance, so check rear-port connection, USB cable integrity, and power-plan settings before opening an RMA.
When Does Hz Actually Translate to Aim
The perceptibility threshold between 500 Hz and 1000 Hz sits near the practical upper edge of what most players can feel. A jump from 1000 Hz to 4000 Hz reduces the report interval by 0.75 milliseconds, from 1.0 ms down to 0.25 ms. That difference is measurable on a chart but barely noticeable in a real match. Stepping from 4000 Hz to 8000 Hz saves only an additional 0.125 milliseconds, dropping the interval to 125 microseconds, a margin that sits well below the conscious reaction threshold for even the most elite players.7 For what high polling rates mean for practical competitive gaming, the linked guide at high polling rates for competitive gaming covers system requirements and what you actually feel on the crosshair.
Sub-millisecond differences do not change whether you hit that flick shot. Consistent 1000 Hz beats unstable 4000 Hz in every practical sense. A power-managed setup dropping from 1000 Hz to 500 Hz under load is exactly the pattern an OS USB selective suspend policy causes. It introduces a 1 millisecond variance window into your aim timing. That variance accumulates across hundreds of inputs in a competitive match. CS2 and Valorant players reading sub-millisecond consistency numbers understand this intuitively.
Set the lower bound. A stable, consistent polling rate matters more than reaching the millisecond ceiling. A 1000 Hz line that is rock-steady from session start to session end gives you better aim consistency than an 8000 Hz line that dips randomly under load. The browser-based measurement reflects the rate your operating system and browser actually deliver to your game, and that is exactly where aim timing happens.
When to Trust That Polling Rate Number and When to Walk Away
A flat reading within ±5 percent of the advertised Hz on a dedicated rear motherboard port with nothing else on the bus is an honest number. Ask yourself whether that precision actually matters for your games before you celebrate, though. A 1000 Hz setup that stays rock-steady across every session is more reliable than an 8000 Hz setup that burps to 1000 Hz under load.
A reading that oscillates wildly after the first 10 seconds, or sits capped at 1000 Hz regardless of what the box claims, warrants investigation before assuming the mouse is defective. USB port placement, power management, background IO load, and firmware version all affect this number independently of the sensor’s raw capability. For competitive players specifically, walk through this checklist to settle whether the value of higher polling rates justifies the cost of fixing your setup first:
- Run CapyToolkit’s Input Lag & Mouse Polling Rate Tester before the return window closes. A stable reading within ±5 percent of the advertised spec after placement and power fixes tells you the hardware is honest.
- A reading that oscillates between 1000 Hz and the rated Hz after three test runs indicates a USB topology or power-management issue, not a design flaw. Fix those first.
- The honest headline: an 8000 Hz rating proves the sensor and µcontroller can keep up. It does not prove your entire signal chain can deliver it. CapyToolkit’s Input Lag & Mouse Polling Rate Tester shows you the end-to-end number the browser hands to your games, with zero vendor software installed. You do not need the manufacturer’s driver to know what you are actually getting.
- 1.
W3C, “Pointer Events,” w3.org, June 2026. https://www.w3.org/TR/pointerevents3/
- 2.
Chrome for Developers, “Aligned input events,” developer.chrome.google.cn, June 2017. https://developer.chrome.com/blog/aligning-input-events
- 3.
David Halbhuber et al., “The Effects of Auditory Latency on Experienced First-Person Shooter Players,” ACM, September 2022. https://dl.acm.org/doi/fullHtml/10.1145/3543758.3543760
- 4.
Mozilla Developer Network, “PointerEvent.getCoalescedEvents(),” developer.mozilla.org, December 2023. https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents
- 5.
Microsoft, “Selective Suspend for HID Over USB Devices,” learn.microsoft.com, accessed July 2026. https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/selective-suspend-for-hid-over-usb-devices
- 6.
Alan Stern, “Power Management for USB,” kernel.org, February 2014. https://www.kernel.org/doc/html/latest/driver-api/usb/power-management.html
- 7.
TechPowerUp, “Razer DeathAdder V3 Review - Testing 8000 Hz,” techpowerup.com, July 2026. https://techpowerup.com/review/razer-deathadder-v3/6.html
