Input Lag & Mouse Polling Rate Tester: Conversions

Convert ms to Hz

How to convert ms to Hz

Dividing 1000 by the interval in milliseconds converts it to polling rate in Hz. At 1 ms, the rate is 1000 Hz; at 0.125 ms, it is 8000 Hz, the current ceiling for consumer gaming mice.¹

Common ms to Hz conversions

Why this conversion matters for gaming performance

Frequency and interval describe the same hardware property from opposite directions. Manufacturers advertise polling rate in Hz; latency calculations use intervals in ms. Converting between them lets you reason about the actual time gap between position reports.¹ At 1000 Hz, each report arrives 1 ms after the previous one; cursor lag stays at most 1 ms at that rate. At 8000 Hz, the lag ceiling drops to 0.125 ms. Understanding the interval in ms makes the practical performance difference tangible rather than abstract.

Turning interval changes into polling-rate changes

A small interval change at high rates can still represent a large Hz jump, so treat the converter result as a paired frequency and interval. That pairing keeps the result connected to the report timing you are actually evaluating. For example, shortening the interval from 1 ms to 0.5 ms doubles the polling rate from 1000 Hz to 2000 Hz, but shortening it further from 0.25 ms to 0.125 ms doubles it again from 4000 Hz to 8000 Hz; each step delivers the same proportional improvement while the absolute time savings shrink, which explains why the perceptible difference between 4000 Hz and 8000 Hz is smaller than between 1000 Hz and 2000 Hz.

Why the interval matters more than the label

For players upgrading from 1000 Hz to 8000 Hz, converting the new interval to milliseconds makes the improvement concrete: from 1 ms per report to 0.125 ms per report. During a 50 cm/s flick, a 1000 Hz mouse sends one report every 0.05 cm of physical travel; at 8000 Hz, one report arrives every 0.00625 cm. The cursor path during the flick follows the physical hand arc with eight times the positional resolution, capturing micro-corrections that fall between report boundaries at lower rates and contributing to smoother aim tracking at high movement speeds.²

That conversion also helps when your test result does not match the setting in software. If a mouse configured for 8000 Hz reads 1000 Hz in the polling rate test, the real operating interval is 1 ms, not 0.125 ms. Converting the measured rate instead of the advertised maximum keeps your latency expectations tied to the path your browser actually receives.

How polling rate relates to input pipeline latency

Polling rate is one stage in the total input latency pipeline, not the only one. After the mouse sends a report at the configured polling rate, the USB controller schedules the interrupt, the OS input driver processes the event, and the application receives a PointerEvent. USB interrupt scheduling follows the endpoint polling interval rather than acting as an independent latency guarantee.³ Input-device latency research also shows that polling rate affects only part of the measured delay; forced 1000 Hz polling reduces latency for some devices but not all.⁴ Higher polling rate reduces the polling interval contribution but cannot eliminate downstream processing stages.

Understanding where the polling interval fits within total pipeline latency prevents over-attributing improvements to polling rate increases alone. The polling interval is the minimum stage in the chain: at 8000 Hz, it contributes 0.125 ms. Browser-measurable input delay then includes the OS handoff to the browser, event handling, and any main-thread work before callbacks can run. The W3C Event Timing API exposes this delay as processingStart minus startTime, while web.dev describes the same unavoidable OS-to-browser handoff and main-thread work as part of input delay.⁵⁶ Reducing polling interval further would not measurably change the total if downstream stages dominate.

Practical polling rate guidelines

For non-competitive use, 125 Hz (8 ms interval) is adequate. For casual gaming, 500 Hz (2 ms) provides noticeable improvement. For competitive play, 1000 Hz (1 ms) is the accepted minimum. At 4000 Hz (0.25 ms), most players notice improved tracking smoothness during fast movements. At 8000 Hz (0.125 ms), the improvement over 4000 Hz is real but subtle. Increasing polling rate above your system's capability to deliver reliably produces no benefit; use the polling rate test on this tool to confirm your hardware is actually delivering the configured rate before making performance judgements.

When to verify polling rate before relying on these intervals

Assuming your hardware delivers its configured polling rate without verification can lead to incorrect expectations about the interval you are actually operating at. A mouse set to 8000 Hz that reads 1000 Hz in the polling rate test delivers a 1 ms interval rather than 0.125 ms, making the 8000 Hz conversion result inapplicable to your system. Running the polling rate test before treating any conversion result as your operational interval confirms whether your specific hardware and configuration is delivering the rate the conversion assumes.

Try in the tool

Convert Hz to ms

How to convert Hz to ms

Dividing 1000 by the polling rate in Hz gives the interval between reports in milliseconds. 1000 ÷ 1000 Hz = 1 ms. 1000 ÷ 8000 Hz = 0.125 ms. This is the maximum time between successive position reports.

Common Hz to ms conversions

Polling rate in milliseconds: what each tier actually delivers

From Hz to ms, the conversion turns report frequency into the interval between reports. The result is not a separate latency source; it is the maximum gap between position reports at a given polling rate.¹ Converting Hz to ms makes the practical timing difference between polling rate tiers concrete. At 125 Hz (8 ms), the cursor can be up to 8 ms behind the physical mouse position, which appears as sluggishness during fast movements. At 1000 Hz (1 ms), that maximum gap is a single millisecond. At 8000 Hz (0.125 ms), the report interval is one eighth of a millisecond.² Knowing the interval in ms helps you evaluate whether a polling rate upgrade will produce a noticeable improvement for your movement speed and game type.

Comparing report interval with frame time

A report interval becomes meaningful when you compare it with the frame time your game is actually rendering. A 1 ms interval matters more at 360 FPS than at 60 FPS because the game samples cursor position more often and leaves less room between reports. At 60 FPS, each frame spans 16.67 ms, so a single polling interval is only 6% of the frame window. At 360 FPS, that same 1 ms interval consumes 36% of the available frame time, meaning the cursor position is fresher relative to the rendered output. The tighter the frame window, the more each fraction of a millisecond in report interval affects how current the sampled position appears on screen.

Converting frame rate to polling interval to understand the latency gap

Converting frame rate to polling interval shows how much smaller the cursor lag becomes at higher polling rates on high-refresh displays. At 360 FPS, each frame is 2.78 ms; a 1000 Hz mouse delivers one report every 1 ms, and cursor lag at sample time is at most 1 ms, which is 36% of a full frame interval. At 8000 Hz, the lag drops to 0.125 ms, which is 4.5% of the frame interval. The mouse delivers 22 reports per frame at 8000 Hz on a 360 Hz display, giving the game engine fresh cursor data at render time regardless of when movement started.

How polling rate relates to input pipeline latency

The polling interval is the minimum component of total input latency, not the total latency itself. USB interrupt transfers are scheduled around the endpoint polling interval, so polling rate is one contribution rather than the whole input path.³ Input-device latency research shows that forced 1000 Hz polling reduces latency for some USB devices but not all, which means downstream device and system stages still matter.⁴

Where the converted interval fits in total latency

For systems where downstream pipeline stages dominate total latency, converting Hz to ms primarily helps identify what is theoretically possible rather than what is currently occurring. Browser-measurable delay then includes the OS-to-browser handoff and event handling before callbacks begin. The W3C Event Timing API defines event delay as processingStart minus startTime, while web.dev describes input delay as the time from user interaction until event callbacks begin and notes unavoidable OS-to-browser handoff plus main-thread work.⁵⁶ Reducing the polling interval further cannot help at that point if downstream stages dominate the measured result.

Entering the measured rate instead of the configured rate keeps the converter honest about what your system delivers. If the browser chart shows 4000 Hz but the software claims 8000 Hz, the 0.25 ms figure from 4000 Hz is the real operational interval. Using the configured number would understate the gap between your hardware and your actual experience, which is the opposite of what the conversion is meant to reveal.

Practical guidelines for choosing polling rate

Treat 1000 Hz (1 ms) as the practical baseline for competitive gaming. Consider 4000 Hz (0.25 ms) if your mouse supports it and you play games requiring fast flick movements. Use 8000 Hz (0.125 ms) if your hardware supports it and your system delivers the rate reliably; verify with the polling rate test before treating 8000 Hz as active. Reduce polling rate if you notice frame rate instability on lower-end systems or older game engines, as Razer notes that some engines cannot handle high polling rate devices well.² Never assume your configured polling rate is being delivered without verifying it in a measurement tool.

Verification matters more than configuration for polling rate accuracy. Configuring a mouse at 8000 Hz without confirming the delivery produces interval assumptions that may not match reality. The polling rate test on this tool confirms which interval the system is actually achieving; use the measured rate in the Hz-to-ms converter to calculate your actual operational interval rather than the configured one. If the measured rate is 1000 Hz despite an 8000 Hz setting, your actual interval is 1 ms, and the steps to resolve that discrepancy are available on the polling rate diagnostic page.

That distinction matters when comparing settings across mice. Two mice can both show 8000 Hz in software, but only the one that sustains 8000 Hz in the browser chart is actually operating at a 0.125 ms interval. The conversion is exact, but it is only useful when the measured rate is the rate you enter.

Try in the tool

Convert Clicks per second to min debounce (ms)

How to convert Clicks per second to min debounce (ms)

Dividing 1000 by your clicks-per-second rate gives the minimum interval between legitimate clicks in ms. A debounce window shorter than this interval risks filtering rapid intentional clicks as bounce events. Set your debounce threshold at or below this value to avoid false positives.

Common Clicks per second to min debounce (ms) conversions

How click speed determines the safest debounce threshold

Your fastest intentional clicks set the ceiling for a safe debounce threshold. Debounce window length determines both click latency and maximum intentional click rate. A debounce window that is too long ignores rapid legitimate clicks, capping your effective click speed below your physical capability. A window that is too short fails to filter switch bounce on mechanical contacts, producing double events. Analog Devices explains that mechanical switches can make multiple transitions over tens of milliseconds, with one small pushbutton example bouncing for about 5 ms and another relay example bouncing for about 5.5 ms.¹ Calculating the minimum debounce for your intended click rate gives you the target threshold: any debounce window below this value safely accommodates your fastest clicking without interference.²

Matching debounce to your fastest intentional clicks

In a competitive session, your clicking rate varies widely across game moments: rapid bursts during close-range fights, slower deliberate clicks for precision shots, and fast sequences for inventory management or ability use. Testing at your measured peak rate from a dedicated click-speed test establishes a conservative minimum interval that covers your fastest intentional presses regardless of which game action produces them. Setting debounce below that minimum interval ensures the firmware accepts every legitimate input, including the burst presses that exceed your average session pace by a significant margin.

Why debounce dominates click latency on mechanical mice

Debounce window and polling rate are independent firmware features. Microsoft describes USB interrupt polling interval as bInterval, a firmware configuration that drivers cannot change, while debounce filters delay reporting until a switch state remains stable.³ Higher polling rate reduces the USB scheduling delay between a switch event and the next report slot, but it does not change the debounce window. Consequently, a mouse at 8000 Hz with a 5 ms debounce still has at least 5 ms of click latency; the polling interval contribution of 0.125 ms is small next to the debounce component.⁴ For click latency optimisation on mechanical-switch mice, reducing debounce time is more impactful than increasing polling rate.

Checking whether a debounce reduction improved click latency

Reducing debounce time shows a measurable improvement in the click latency log when debounce was the primary bottleneck. After adjusting the window in companion software, click repeatedly at a consistent pace inside the tracking zone and compare the new average to your baseline measurement. A drop approximately equal to the size of the window reduction confirms debounce was the dominant factor. A flat average after the reduction points to USB scheduling as the bottleneck; further debounce changes will not help at that point.

Recording the before and after average alongside the window size makes the result concrete instead of intuitive. If you shortened debounce by 4 ms and the average dropped by roughly 4 ms, you have confirmed the relationship on your own hardware. If the average barely moved, debounce was never the limiting factor and the next step is the USB path. Keeping both numbers turns guesswork into a documented check you can repeat.

Practical debounce guidelines

For optical-switch gaming mice, use the minimum available debounce setting because optical actuation can avoid mechanical contact bounce entirely; Razer describes optical mouse switches as using light-based actuation instead of physical contact points and offering zero debounce delay.⁵ For mechanical-switch mice, start with the lowest supported debounce step that prevents double events, then increase only if the log shows repeated double events. If your switch requires a much longer debounce window to avoid double-clicking, physical switch replacement is the better solution. Use the click latency test on this tool to verify your debounce setting is producing the expected latency values.

Retesting as the switch ages

Calibrating the minimum stable debounce requires a systematic protocol rather than a single pass. Click repeatedly at your normal competitive pace and during the fastest bursts you use in-game, then reduce debounce one step in companion software and repeat. Continue until the first double event appears, then step back one setting. That value marks the minimum stable debounce for your switch in its current condition. Repeating this protocol periodically during heavy use reveals whether the minimum threshold has crept upward due to contact wear, which tells you whether the debounce adjustment is buying time before replacement becomes necessary.²

Try in the tool