📖 Reading time: approx. 17 minutes · 3,283 words · 18,457 characters
For a very specific reason, because quite a few questions have come up by now regarding latency measurements and 1K and 8K polling rates, I have prepared a marketing-free and clean calculation together with an assessment of the often-invoked topic of latencies. At the same time, I had to correct the previous classification at one crucial point, because the first measurements were formally clean, but in the case of one of the mice they were not performed with the switch configuration that made the most sense for USB operation. In the end, that is more instructive than any glossy slide. Because anyone writing about input latency while looking only at the mouse or at a USB number printed on the box is missing the real point. What matters to the player is not when a report arrives at the host, but when the action becomes visible on the display. That is exactly why an end-to-end measurement is the only meaningful starting point. NVIDIA explicitly describes LDAT as a method for measuring full input latency up to the visible reaction, and NVIDIA even calls Flash Indicator plus LDAT the gold standard because software-based methods do not fully capture either mouse latency or monitor latency. In the end, that is the level at which immersion is created or not. At first glance this may sound unspectacular, but it is already half the battle.
The fact is that a player does not feel a polling rate, a player feels the sum of switch, firmware, USB transport, operating system, input queue, game engine, render path, present, scanout, and panel response. So if someone holds up 1,000 versus 8,000 Hz on paper, they are measuring one small part of the chain very precisely and then declaring it to be the whole story. That is usually where the marketing fog already begins. And that is exactly what we are clearing up today, because all this 8K hype is something almost nobody truly needs as long as the rest of the chain is not tuned properly as well. The new measurements show even more clearly that an unsuitable debouncing setting can do more damage than 8K alone could ever fix.
Four Measurements as a Clean Baseline
The original measurements show two different mice from one manufacturer from the last mouse review. Image one shows mouse 1 in 1K mode, image two mouse 1 in 8K mode, image three mouse 2 in 1K mode, and image four mouse 2 in 8K mode. What matters today, however, is the added note that both mice were still running with a very conservative factory debounce setting, in other words with a configuration that is still understandable as a safety net for Bluetooth, but unnecessarily slows things down on USB cable operation with optical switches. So the first group of four was not wrong, it was just not yet the whole story:
Each measurement was taken as end-to-end latency with an identical synthetic still image. That matters because it reduces scene complexity. What it does not eliminate, however, are framing, queueing, present behavior, and the timing position of the input within a frame. That is exactly why the test remains practical and does not turn into a sterile mouse lab exercise. At the same time, this first series shows very clearly how easily one can still arrive at an incomplete conclusion in terms of content even with correct methodology if the mouse firmware settings do not match the selected operating mode.
That gave mouse 1, in the first reading, an advantage of 2.5 ms in 8K mode. For mouse 2, by contrast, the difference was only 0.3 ms. If one calculates the simple standard error from the respective standard deviations and n = 25, then the combined error for mouse 1 is roughly 0.64 ms and for mouse 2 about 0.58 ms. That means the difference for mouse 1 was clearly larger than the statistical scatter of this small sample, while for mouse 2 the difference was practically within the measurement noise of this series. This exact old classification now has to be supplemented by one decisive point, because on mouse 2 the factory-active debounce setting was the real brake.
Even at this point, it becomes clear why blanket statements about 8K are so unsatisfying. Mouse 1 reacts clearly, mouse 2 initially barely at all. But that was not proof that mouse 2 fundamentally does not benefit, it was above all evidence of how strongly an unsuitable switch configuration can distort the result.
Four New Measurements with Corrected Debounce Rate on Mouse 2
The real point is therefore delivered by the four additional measurements of the second mouse. Here, not only was there switching between 1K and 8K, but the debounce rate was also varied between 0 ms and 1 ms. That absolutely has to be included at this point, because this mouse uses optical switches. There, the classic contact bounce of mechanical switches is not a real issue, which means that a high debounce time on the USB connection mainly does one thing, it adds unnecessary waiting time. Anyone overlooking that is not measuring the performance capability of the mouse in the end, but rather the braking distance of the firmware.
And now it becomes really interesting. At 1K, increasing the setting from 0 ms to 1 ms already costs 0.9 ms. At 8K, the same step even costs 2.0 ms. Even more revealing is the direct cross-comparison. The mouse is on average faster at 1K and 0 ms than it is at 8K and 1 ms, namely 11.4 instead of 11.7 ms. In other words, an incorrect switch setting can completely wipe out the advantage of the higher polling rate. That is exactly why the focus of this article now deliberately shifts to these four new measurements. Because they do not just show that 8K does not perform miracles, they show above all that poor settings, excessively high debounce times, or low-quality mechanical switches can quickly reduce the entire rest of the discussion to absurdity. It also completely calls into question the point of an 8K polling rate on mice with mechanical switches that require debouncing.
If the new values are additionally compared with the original factory setting of the second mouse, the picture becomes even clearer. The old 1K measurement was 19.1 ms, the new 1K measurement with 0 ms debounce is 11.4 ms. The old 8K measurement was 18.8 ms, the new 8K measurement with 0 ms debounce is 9.7 ms. Of course, an end-to-end series is never just a naked debounce counter, because frame position, queueing, and jitter also play a role. But the magnitude clearly shows that the main culprit here was not the polling rate, but the factory setting. So anyone staring only at 8K while ignoring the debounce rate can ruin their own measurement very reliably.
The new group of four is the actual key. It is not the 8K label that first decides the result, but whether the switch path is tuned correctly and fast enough, with non-mechanical contacts. An excessively high debounce time at the very front easily consumes the small USB advantage. That is exactly why good switch quality together with appropriate firmware tuning is often more important in practice than the big number on the box.
What 8K Can Technically Deliver at All
USB interrupt transfers are queried by the host at fixed intervals. Microsoft describes intervals for high-speed USB down to 125 microseconds. That is exactly how 8,000 queries per second are created. At 1,000 Hz, the interval is 1.0 ms. What matters now is the small but decisive difference between period and average waiting time. If an event occurs randomly within an interval, it waits on average only half the period until the next poll. That means 1K becomes an average USB waiting time of 0.5 ms, while 8K becomes only 0.0625 ms. The average theoretical advantage of 8K over 1K is therefore only 0.4375 ms. In the absolute ideal case, it is a maximum of 0.875 ms. USB simply cannot save more than that at this point. This is exactly where the simple advertising narrative already collapses in on itself.
Eight times more polling rate does not mean eight times less total latency. It only means that a single, already small section of the chain becomes somewhat shorter. The rest initially remains completely unaffected.
Why the New Measurements Matter More than the Old 0.3 ms Difference
The original reading for mouse 2 was simple, but too simple. 19.1 ms at 1K versus 18.8 ms at 8K yielded only a 0.3 ms difference, in other words almost nothing. Today we know that this statement primarily reflected the wrong debounce setting. Only the new group of four shows how the mouse actually reacts when the switch path is configured correctly. With 1 ms debounce, the gap between 1K and 8K is 0.6 ms. That is already much closer to what can theoretically be expected from a higher polling rate. With 0 ms debounce, the gap even grows to 1.7 ms, which in turn shows that in the 8K mode of this mouse there is apparently more happening than just the naked USB clock. We had already seen exactly the same observation with mouse 1, only there it stood out even more at 2.5 ms.
That is the actual point. As soon as a mouse benefits much more strongly than the pure USB gain of an average 0.4375 ms would allow, there almost has to be more at play than just the polling rate. That can be due to internal scan cycles, different firmware scheduling, modified buffering, or different report packaging. Without access to firmware and protocol analysis, anything further would be little more than reading tea leaves with RGB. But that is exactly why a blanket judgment on 8K is so unsatisfying. Sometimes you see almost nothing, sometimes somewhat more, and sometimes what you are really measuring is merely the consequence of a suboptimal switch configuration.
The new measurements also allow a second statement that is much more important in practice. The difference between 1K and 8K at 1 ms debounce is only 0.6 ms. The difference between 8K at 0 ms and 8K at 1 ms, by contrast, is a full 2.0 ms. That means in this series the influence of the debounce rate is clearly greater than the pure change in polling rate within the same debounce stage. That is exactly what users need to understand. Anyone using a mouse with optical switches and an adjustable debounce rate should first configure the switch path correctly and only then talk about 1K or 8K.
Why Refresh Rate Matters Much More than Polling Rate, Calculation Model for 120, 240, and 360 Hz
Many games process inputs as part of their update step. Microsoft describes this in its examples as updating the game state once per frame. That immediately turns frame rate into a second clock source, and usually a much stronger one. A frame lasts about 8.33 ms at 120 Hz, 4.17 ms at 240 Hz, and 2.78 ms at 360 Hz. Because a click arrives randomly somewhere within that window, the average waiting time until the next processing step in the game is half the frame time, namely 4.17 ms, 2.08 ms, and 1.39 ms. Even at 360 Hz, this average frame waiting time is still significantly larger than the average USB advantage of 0.4375 ms. And if all constant parts of the chain are now combined into K, in other words switch, mouse internals, operating system, render path, scanout, and panel, then only USB plus frame processing remains for the variable portion. This results in a surprisingly simple model:
Theoretical Latency Component from USB and Frame Processing
That is the actual mathematical proof.
Refresh rate changes the game’s absolute waiting time significantly, but it does not change the advantage of 8K. On average, that still remains only 0.4375 ms. Higher monitor hertz values therefore do not suddenly make 8K amazing, they merely make the game’s relative share smaller. The USB advantage still remains tiny like a poorly tempered pixel.
Why 8K Can Also End Up Merely Tied or Even Lose
In the Raw Input model, Windows explicitly documents that even with 1,000 Hz mice, several input events can accumulate between two iterations of the message loop. That is a rather clear indication that high input frequencies are not automatically translated 1:1 into immediate benefit. First of all, they simply generate more events that have to be collected, buffered, and processed in the application at the right time. That is exactly where queueing, scheduling effects, and jitter arise.
This also makes clear why end-to-end measurements often turn out to be far less spectacular than marketing slides. And it also makes clear why the debounce rate is so important. Because if the firmware already adds extra milliseconds to the click before USB transport even begins, then one is practically discussing the small theoretical 8K advantage in the shadow of a much larger, self-inflicted delay.
If the theoretical USB advantage is only 0.4375 ms, then very little additional overhead elsewhere in the path is already enough to consume that advantage completely. And if a click lands unfavorably just behind an input window or a frame update, a single additional frame immediately costs 8.33 ms at 120 Hz, 4.17 ms at 240 Hz, or 2.78 ms at 360 Hz. All of these values are significantly larger than the maximum USB advantage.
From this alone it follows mathematically that 8K can certainly appear tied or worse in an end-to-end measurement, even though the mouse is technically operating faster and correctly on the USB bus. Mouse 1 benefits clearly from 8K, but precisely this large lead shows that the gain cannot come from polling rate alone. Mouse 2 now also shows a much more interesting picture in the new series. At 1 ms debounce, the advantage is small, at 0 ms it is significantly larger, and at the same time it becomes clear how sensitively the result reacts to the switch configuration. For an objective review, that is worth gold. Because one can now state very clearly that 8K as a bus feature is real, but its pure benefit remains small, while poor switches, conservative debouncing, or poor firmware tuning can destroy the entire advantage faster than any marketing slide can inflate it.
That is exactly why 8K as a marketing term is so convenient and, at the same time, so imprecise. Under the same headline there can be a genuine mode shift inside the device, an almost meaningless mini-effect, and even a misconfiguration hidden by unsuitable debounce values, all of which can outwardly be sold in the same way. In all cases the box then says 8K, but in practice the result may once be 2.5 ms, once 1.7 ms, once 0.6 ms, and in the worst case almost nothing at all. That is then not a miracle of technology, but merely the sum of firmware, switch quality, and system path.
Conclusion for the End User
For the current reader, in the end only one thing matters, does the function count in the game or only on the data sheet. The measurement series expanded today provides a much clearer answer to that than the original group of four alone. End-to-end is the only relevant perspective because only it captures the actual reaction on the screen. 8K can be measurable, but the pure USB effect is small and averages only 0.4375 ms. The new measurements of the second mouse simultaneously show that the debounce rate can have a much greater influence than the polling rate itself. Here, 1K with 0 ms is on average even minimally faster than 8K with 1 ms. That is the sentence one should remember.
This shifts the entire debate to the right place. Anyone using optical switches should not carry along an unnecessarily high debounce setting. Anyone using mechanical switches that bounce too much, are poorly selected, or become unstable over time, on the other hand, forces the firmware into higher debounce times and pays for it with latency. That is exactly where good peripherals are separated from poorly made ones. Not every sluggish impression is a USB bus problem, sometimes the switches or their tuning are simply not good enough. And in that case, 8K on the box does very little for you.
8K polling rate is technically very much real, but its guaranteed contribution to total latency is small. In the real system, frame timing, queueing, render path, scanout, panel behavior, and, as the four new measurements show very impressively, the quality of switch tuning dominate instead. Mouse 1 shows a visible gain, mouse 2, with correct debouncing, also gains in a clearly different way than initially assumed, and from that follows the sober classification. 8K is not nonsense, but as a blanket sales argument it is often more marketing with measurable, but usually manageable, practical benefit. Much more important is that the mouse does not carry unnecessary ballast at the front end of the chain. Whether one then wants or is able to accept the significant price premium, I will deliberately leave open at this point. In part 2 I will show you the development of monitors and the new requirements. Then 8K may indeed become relevant again, but only if the rest of the chain is right as well.
Further Articles and Sources
[1] NVIDIA Developer, Streamline / Reflex / LDAT: https://developer.nvidia.com/rtx/streamline/get-started
[2] Microsoft Learn, USB Interrupt Transfer: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/how-to-send-a-usb-interrupt-transfer–uwp-app-
[3] Microsoft Learn, Using Raw Input: https://learn.microsoft.com/en-us/windows/win32/inputdev/using-raw-input
[4] Microsoft Learn, Define the main game object: https://learn.microsoft.com/en-us/windows/uwp/gaming/tutorial–defining-the-main-game-loop
