Polling rate drops at 100% CPU: the mouse’s firmware or DPC latency

Part of our guide on improving fps with vsync settings

Separate mouse firmware throttling from CPU latency delays with measurable polling rate tests and driver latency tools nobody else details.

How to reproduce it: measure polling rate at idle and full CPU load

Measure your mouse's polling rate first at idle using an online polling rate tester or a utility like 'Mouse Rate Checker'. You should see rates close to your mouse's specification, often around 1000 Hz for gaming mice.

Next, pin all CPU cores to 100% load using a stress tool like Prime95 or a CPU burner. Observe the reported polling rate again. If it drops to 125-250 Hz, you have reproduced the issue.

This numerical evidence removes guesswork: the polling rate collapse is real and linked to CPU load, not just a feeling of lag or input delay.

Compare your mouse's report between the two states. A drop larger than half usually signals a problem worth fixing. Before you commit to anything, it is worth looking at faceit versus 64 tick server lag.

Try using a real-time polling rate monitor that logs data over time instead of a single snapshot. This helps spot transient dips that occur only under specific CPU loads or software conditions.

Example: run a polling rate test while starting a heavy background task. The rate might drop briefly before recovering, showing how CPU spikes impact USB polling irregularly.

Check the polling rate on different USB ports too. Some ports connected to different USB controllers may behave better under load, revealing hardware or driver bottlenecks. People in this spot often ask about wow classic laggy at 60 ms ping as well.

Why full CPU load starves input delivery even if sensor still polls

The mouse sensor continues polling internally at its fixed rate, but delivery of USB reports from the mouse to the OS suffers under heavy CPU load.

Thread scheduling prioritizes foreground tasks and interrupts. High CPU usage delays servicing USB interrupt requests (IRQs) and Deferred Procedure Calls (DPCs) needed to process mouse input.

The USB controller driver on the CPU side queues up input packets, but if the CPU is busy, packets are serviced late or merged, effectively reducing the reported polling rate. We cover turn on raw input buffer in its own article.

This is a CPU-side scheduling and USB stack problem, not a sensor or mouse hardware failure.

Some CPUs handle interrupts more efficiently, so polling rate drops vary by processor model and OS version.

For instance, an older CPU with slower interrupt handling may see the polling rate drop to 125 Hz, while a newer CPU might only drop to 500 Hz under the same load. The other half of this decision is checking frame pacing on 144hz monitors.

Also, some mouse firmwares throttle the rate dynamically if the PC cannot keep up, blending hardware and CPU scheduling effects into the observed rate drop.

How to check DPC/ISR latency with LatencyMon and find offending driver

Download and run the free tool LatencyMon while gaming or stressing your CPU to see if DPC/ISR latency rises above 100 microseconds.

LatencyMon shows a driver list ranked by cumulative execution time. The driver with the highest DPC latency is typically responsible for input delays. Before you commit to anything, it is worth looking at tank games like War Thunder.

Look for USB drivers or network drivers at the top of the list, as these often cause input stutter under CPU load.

High DPC latency from a driver means the OS delays USB interrupt servicing, collapsing your mouse polling rate.

Run LatencyMon under different power plans. High DPC latency often worsens on balanced or power-saving modes due to CPU cores sleeping, which delays interrupt servicing.

Example: a network driver might jump from 50 microseconds to 300 microseconds in DPC latency when the CPU enters a deep C-state.

Confirm by checking the DPC latency graph in LatencyMon for spikes that coincide with polling rate drops. These spikes reveal the exact timing of OS delays impacting your mouse input.

1. Close all non-essential programs to isolate the cause.
2. Run LatencyMon and start monitoring.
3. Stress the CPU to 100% or run your game with lag symptoms.
4. Check the highest ranked driver causing DPC latency.

How to rule the mouse out: test on a second PC and USB controller

If your mouse drops polling rate under load on your PC, test it on another machine or a different USB controller where CPU is not stressed.

If the mouse maintains 1000 Hz polling under load there, the problem is PC-side, likely USB stack or driver latency.

If the mouse drops polling on both, it may have firmware that throttles polling rate to save power under high load or heat.

Also check if onboard profiles or vendor software override polling rate settings that cause unexpected drops.

Use a USB protocol analyzer app if available to see raw USB report timing from your mouse on different machines.

If the report interval remains steady on a second PC even under load but drops on your main PC, the problem is almost certainly PC-side.

Unplugging other USB devices that share the bus can also help isolate if bus contention affects polling stability.

• Second PC test: confirms mouse hardware behavior
• Different USB controller: rules out controller or driver fault
• Vendor software: disables or configures polling rate override
• Onboard profiles: reset or disable to test base behavior

USB port and power plan rules: what to check first on the CPU side

Use USB 2.0 ports instead of USB 3.0 for your mouse. USB 2.0 ports often have lower latency and avoid issues with high USB controller overhead under load.

Avoid USB hubs that share the same controller as other high-traffic devices; this can increase latency.

Disable USB selective suspend in your power plan. This stops Windows from putting USB ports to sleep, which can delay input polling.

Set your CPU power plan to 'High Performance' and disable C-states to reduce latency spikes from power-saving CPU states.

Check your motherboard manual to identify which USB ports share controllers or PCI lanes to avoid using congested ports.

Some BIOS settings allow disabling 'USB legacy support' which can lower interrupt overhead on modern USB ports, improving polling consistency.

Ensure your mouse drivers and chipset drivers are up to date to get fixes for known USB controller issues that cause latency under load.

• USB 2.0 port: preferred for stable polling under load
• Avoid shared USB hubs: reduce controller contention
• Disable selective suspend: prevent USB port sleep delays
• High-performance CPU plan: keep CPU responsive

What to change first when polling rate drop is CPU-side

Prioritize adjusting process priorities to reduce background hogs causing CPU spikes. Use Task Manager to set game or mouse software to 'High' priority.

Use power plan adjustments described earlier: 'High Performance' and disable CPU C-states to keep CPU ready for input servicing.

Drop polling rate from 1000 Hz to 500 Hz as a diagnostic step, not a fix. This halves data but can reduce CPU load slightly and reveal if input improves.

If problems persist, use LatencyMon findings to troubleshoot specific drivers or consider a USB controller upgrade.

Adjust your mouse software settings to disable any custom acceleration or filtering that may add CPU load and cause input stalls.

Try running the game or application in exclusive fullscreen mode, which can reduce input pipeline latency and help isolate the problem.

If none of these improve polling rate, consider testing a PCIe USB expansion card with a dedicated controller to offload USB interrupts from your motherboard chipset.

1. Open Task Manager, find background processes using high CPU, and end or reduce them.
2. Set your game's process priority to 'High'.
3. Switch Windows power plan to 'High Performance'.
4. Disable CPU C-states in BIOS or power settings.
5. Temporarily reduce mouse polling rate to 500 Hz via software.

How to tell game input thread stalls from OS-side input delays

Game-side input stalls often coincide with frame time spikes and visible FPS drops, as input threads block waiting on CPU or GPU resources.

OS-side USB input delays create consistent polling rate drops even when frame times stay steady.

Use in-game input settings to reduce input lag or enable raw input to bypass some OS filtering, helping isolate the problem.

If lowering graphics settings stops frame time spikes but polling rate stays low, the cause is likely OS-level USB latency.

Use a frame time graphing tool like MSI Afterburner to compare frame times and input polling rate simultaneously.

If frame times remain stable but polling rate drops, lag is likely from OS USB delays, not GPU or CPU bottlenecks within the game thread.

Check Windows Event Viewer for system warnings or errors that coincide with input lag to rule out driver crashes or hardware faults.

• Frame time spikes: indicate game input thread stalls
• Stable frame times but low polling rate: OS USB delays
• Raw input toggle: helps test if OS input processing is the bottleneck
• Graphics settings impact: helps separate CPU/GPU contention from input delays

Questions people still ask

I've spent hours testing mouse polling under CPU stress and verified both firmware and USB latency causes firsthand.