In general terms, polling rate can be described as the rate at which the data generated by the mouse is transmitted from the mouse to the PC via USB. Polling rate is measured in Hz; i.e., the number of times per second. The higher the polling rate—the lower the polling interval—the more frequently are the cursor position and any other input events (button inputs) updated, resulting in improved positional accuracy and generally reduced latency. At 1000 Hz, the polling interval is 1 ms, which means the PC receives a new update every 1 ms. At 2000 Hz, the interval is 0.5 ms, at 4000 Hz, the interval is 0.250 ms, and at 8000 Hz, the interval is 0.125 ms.
8000 Hz: The Technology and How to Use It
In the past, multiple mice claimed to be capable of 2000 or even 3000 Hz polling have been released. However, each and every time, these claims turned out to be inaccurate. All of these mice had one thing in common: They were full-speed devices typically incapable of running at polling rates higher than 1000 Hz without modified USB drivers. The Sabre RGB Pro, on the other hand, is a high-speed device and thus natively capable of polling rates higher than 1000 Hz. Furthermore, it is equipped with a sensor (PMW3392) capable of running at a sufficiently high framerate, which ensures it's not just identical data being sent more frequently. That having been said, from what I can tell, the 3392 in the Sabre RGB Pro runs at the default 3389 framerates, unlike the EVGA X17.
Setting the Sabre RGB Pro to 8000 Hz has to be done in its software, as the Sabre RGB Pro is set to 1000 Hz polling by default. Upon setting the Sabre RGB Pro to 8000 Hz, one is greeted by the message shown above. Curiously, it's not displayed at 2000 Hz or 4000 Hz, the latter of which in particular is just slightly less taxing on the CPU. The Sabre RGB Pro can be set to 125, 250, 500, 1000, 2000, 4000, or 8000 Hz within iCUE. However, it is important to note that those values merely denote the maximum applicable polling rate. If the mouse isn't physically moved enough to generate a sufficient number of motion events (for 8000 Hz at least 8000 pixels worth of motion per second), less updates will be transmitted, resulting in a lower effective polling rate. Accordingly, using a sufficiently high CPI step on the Sabre RGB Pro is highly recommended. I would advise using at least 1600 CPI, and possibly even higher depending on one's effective in-game sensitivity (turn circumference). The higher the turn circumference, the more physical motion is typically generated, and lower CPI is thus required to saturate the polling rate. Conversely, the lower the turn circumference, the less physical motion is generated, and higher CPI is thus required to saturate the polling rate. It should be noted that on the Sabre RGB Pro, click and sensor motion data aren't detached internally. As such, a lower polling rate will increase the click latency compared to 8000 Hz.
In order to get the full benefit out of 8000 Hz polling, certain conditions need to be met. First, it is recommended to have a sufficiently powerful CPU; i.e., one with six physical cores and appropriately high IPC to match. Second, the OS has to be capable of 125 μs or lower interrupt moderation. This is true of Windows 8 or higher, where interrupt moderation on XHCI will typically be 50 μs, but not of Windows 7 and lower, where interrupt moderation is never below 1 ms unless changed manually, which isn't easily done. On EHCI, interrupt moderation can be expected to be 125 μs on Windows 8 or higher, which is sufficient but not optimal. Third, plugging the Sabre RGB Pro into a USB 3.x port in XHCI mode is therefore recommended. Any USB 3.x ports forced into EHCI will be equivalent to a native USB 2.x port. As a general rule of thumb, one should use a USB port native to the CPU and not connect any other high-polling devices to a port of the same hub. Even if all of these conditions are met, actual polling stability during higher workloads will further depend on general system and OS health. As such, it is recommended to use a reasonably optimized OS installation that is light on bloat in conjunction with the Sabre RGB Pro.
Performance Testing
I'll be testing general tracking, polling stability, and motion delay for 2000, 4000, and 8000 Hz each. All testing is performed at 1600 CPI.
2000 Hz:
Count distribution isn't as tight as on the Razer Viper 8K, but better than on the EVGA X17. Keeping the motion delay differential established at 1000 Hz in mind, the Sabre RGB Pro is ahead of the G403 by roughly 0.5 ms.
4000 Hz:
Count distribution hasn't changed much compared to 2000 Hz. The Sabre RGB Pro is now ahead by roughly 0.7 ms.
8000 Hz:
Surprisingly enough, count distribution is much tighter at 8000 Hz compared to 2000 or 4000 Hz. I had to move the mouse significantly more to fully saturate the polling rate, yet it only averages 0.145 ms instead of the targeted 0.125 ms. The motion delay differential is around 0.8 ms.
8000 Hz (EHCI):
Lastly, for the sake of comparison, here are the results for running the Sabre RGB Pro at 8000 Hz in a USB 2.x port (EHCI). General tracking suffers greatly, no more than 0.190 ms is averaged, and the motion delay advantage over the G403 ends up accordingly smaller.
Subjective Evaluation
Of course, the performance metrics obtained through empirical testing are just one side of the coin. The more pressing question is whether 8000 Hz is at all noticeable in games, and if so, to which degree.
To properly answer this question, note that someone being unable to notice something does not mean it isn't there objectively, or does not provide an objective advantage. The latter is most definitely true of 8000 Hz polling on the Sabre RGB Pro, so the matter shifts towards whether said advantage is meaningful and thus noticeable one way or another. That said, playing on a 165 Hz monitor at typically 200 FPS or more, I indeed struggled to notice a difference in terms of latency. As explained above, saturating the full 8000 Hz polling rate takes quite a bit of mouse movement and thus isn't typically reached all the time anyway, so most of the time, the benefit in terms of latency compared to 1000 Hz is around 0.5 ms, which is well below the sensory capabilities of the average human. The greatest effect of 8000 Hz may indeed not be observed in terms of absolute latency, but rather smoother cursor feel and general positional accuracy, more specifically in games requiring high precision in regards to click timing. Particularly games supporting sub-frame input will benefit to a greater degree from 8000 Hz, such as Overwatch or Diabotical with their respective settings enabled. Generally, in order to get any use out of 8000 Hz, I'd recommend using a strong CPU and a 240 Hz or even 360 Hz display. Slower panels will inevitably struggle to even display the granularity afforded by 8000 Hz polling. Those with weaker CPUs may experience worse input response simply due to the higher CPU cost, which means any advantage gained by 8000 Hz immediately cancels itself out.
When choosing between 2000, 4000, and 8000 Hz, I would advise picking either 4000 Hz or 8000 Hz, with the latter being the preferred option. Though effective responsiveness at 4000 Hz is virtually on par with 8000 Hz due to being easier to saturate, 8000 Hz displays significantly better tracking. Furthermore, as polling rate affects click latency, choosing a higher polling rate will lower click latency.
Appendix: List of Tested Games
As there is little reason to use the Corsair Sabre RGB Pro at polling rates higher than 1000 Hz in non-competitive games, I'll exclusively list games that are typically considered competitive. Please note that a game running fine for me won't necessarily run fine for everyone, as it merely means it generally works well with 8000 Hz polling. Conversely, a game not working well at 8000 Hz on a specific system isn't generally incompatible with 8000 Hz polling. In general, it should be noted that polling performance at 2000 Hz and above is a function of one's system, not of the mouse. Unfortunately, iCUE doesn't support application-specific profiles, so one would have to manually lower the polling rate in games that don't work well with polling rates higher than 1000 Hz.