​

​

​

​

​

​

​

​

​

It's an old topic really, but from what I gathered it has been mostly misunderstood and never thoroughly been touched upon.While mice themselves are only rarely to blame for polling imprecision, I still think the topic deserves a dedicated thread here as it greatly impacts mousing and is an improvable issue.The whole thing ended up longer than I wanted it to, mostly because I went into probably unnecessary lengths with my explanations, but whatever - told some people I would post this here. If anything is hard to understand or inaccurate, please don't hesitate to point it out.Movement and other input data created within your mouse is grabbed by your PC periodically and made available for the general system and use in applications.The rate at which data is transferred from your mouse's internal buffer to your PC is called polling rate. The higher the polling rate, i. e. the lower the polling interval, the less potential delay between movement or other input activity (buttons, wheel) being registered on your mouse and that input being translated into events on your desktop or in an application.The polling rate reduces input latency, where the set poll interval is the maximum latency. Maximum latency because regardless of the poll interval, data can enter the mouse buffer at any point in time according to your physical actions, andregardless of the endpoint's buffer activity. That means you can physically actuate the mouse, it will fill its buffer with according data at point X after that action and the next poll from the host will grab that data at X + 0-polling interval.The timing relation between your physical action and the consecutive poll will determine the latency added by polling. That can be mere microseconds or up to one whole polling interval. Optimally you would want to set your mouse to be polled at a rate of 1000Hz - once every millisecond. That way you ensure not only that polling latency is 1 millisecond at most, but you also increase the likeliness of polling latency being only fractions of that since more polls per time increase the likeliness of a poll process happening just after your mouse buffer is filled.Note that this only goes for "single" events where the buffer is written to at an arbitrary time. If the buffer filling rate of your mouse exceeds the polling rate, i. e. if you move your mouse reasonably fast, the maximum polling latency will be met throughout that movement.On the left side you see single events entering the buffer at an arbitrary point in time. Looking at the individual input events, you can see that the first enters the buffer just after the last USB poll. So that one will experience nearly maximum poll latency of 1ms before the next poll grabs it. The second event enters the buffer nearly towards the very end of the polling interval, just before the next poll is initiated. For that second input polling latency would be a few microseconds. The third input falls inbetween two poll processes, so roughly 500 microseconds of polling-induced latency for that.On the right side you are moving the mouse around or scrolling the wheel fast and data enters the buffer at a rate beyond 1ms. So you will get a sum of those inputs delivered to the PC constantly each 1ms with an average latency of 500us.Using the same depiction of poll processes, this is what imprecise poll times would look like:The time inbetween polls is not consistent; polls are not evenly distributed throughout time. Normally when the CPU cannot address a poll process timely and you thus get an off-timed poll, the system will try to compensate and to handle the next poll process as much faster as the previous one was slower or vice-versa.By the way, that also means that with higher polling rates (and lower CPI respectively) you additionally increase the speed at which you have to move the mouse before average polling latency occurs on every poll. For example at 400cpi @ 500Hz you hit 1ms average latency on your inputs at 500 / 400 = 1.25inch/s, whereas at 1kHz the average of 500us latency on your inputs is met only at 2.5inch/s.Polling precision does not affect input latency, or that at least is not the primary reason why you would want to improve polling precision.. You can think of it like framerate vs. frametime. You get 100 frames per second, but not every frame will be finished exactly 10 milliseconds after the last; some take longer to be rendered and others are rendered more quickly to compensate. Analogously you get 1000 polls per second, but some poll processes take longer and are compensated for with more quickly triggered or addressed consecutive polls.Polling variance even on unoptimized systems is in the range of a couple hundred microseconds to a few thousand microseconds in flawed systems.These are latencies you will not perceive, especially because they are compensated for and more severely mistimed polls are rare and happen amidst thousands of other polls.What I argue you will perceive however is "stuttering". Going back to the frametime analogy, you can have framerates as high as 500fps, there will still be noticable microstuttering if frametimes are not consistent.I personally think the threshold is somewhere in the ~500us range from my time playing around with this. I. e.. Any improvements beyond that still serve a purpuse though: For the PC, even 100us are a very significant time span, and getting mouse events processed as quickly as possible will make everything regarding input run more precisely. Especially considering that the games themselves add a lot of strain on the system, so any improvement to polling precision in a desktop environment may be necessary to get in-game polling precision to acceptable levels.Polling precision can also be used as an indicator of how crisp your system is in general.As you can see, I have optimized my system to be precise up to a maximum polling variance of 5us, the vast majority of polls being processed correctly timed in the nanosecond range - even hitting a maximum possible precision that may be determined by the host controller's ability to trigger ISRs, maximum hardware interrupt frequency as per line-based interrupt and TSC frequency that my host controller operates at or simply the maximum precision of the measurement program used itself.These measurements are taken with the MouseTester by microe. Log Start -> circle your mouse fast enough to where you hit USB polling rate, but not fast enough to where malfunction could happen -> Log Stop. Look at the Interval vs. Time graph. Dismiss noise at the beginning and end of the motion with Data Point Start and Data Point End. You really don't have to move the mouse faster than 1m/s. If even that. Even with 400cpi you hit buffer filling rates of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings and go through all entries, setting "Attributes" DWORD entries you find to "2". This will reveal power settings in the advanced power plan settings otherwise unavailable.For the high performance power plan you want to disable every power saving feature available, especially PCI power management and USB selective suspend. Reading will help. CPU power management will have a ton of entries. Ignore those; parking is disabled already and minimal CPU frequency will already be at 100%.[*]The timer resolution of Windows. To my knowledge, basically the tick rate of Windows and determines scheduling precision of thread activity. That doesn't mean it affects the rate actions are performed at on a hardware-level, but how often Windows itself interrupts the hardware to check for the status of scheduled or periodic operations and either add new tasks or timeout others. Setting timer resolution lower than the default 15.6ms can help applications (not hardware) perform more accurately in that they are able to more frequently access drivers to have Windows create new or kill old tasks (any task the system may have delegated to the hardware and would potentially run for an unnecessary amount of time with a longer timer duration). TimerTool allows you to increase the tick to 500 microseconds instead of 15600 microseconds, helping software execution but also keeping the CPU more efficient by killing tasks more timely should they happen to be scheduled beyond their needs.Task priorites. If you want certain tasks to be addressed more time-sensitively, setting IRQ priorities is a possibility to tell the CPU which interrupts are more important than others.msinfo32.exe will tell you which IRQ# is assigned to which hardware component. For hardware that you want to have the CPU prioritize, create a IRQ#Priority DWORD entry in your registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl, where # corresponds to the actual number attached to the desired component. Set the value of that entry to 1.Another potentially viable way to improve handling of interrupts is to resolve IRQ conflicts. In msinfo32.exe, look for components that share IRQ# under conflicts and see whether you can disable any, change IRQs from your BIOS, get your mouse registered on a host controller that doesn't share an IRQ# or try to see if any components support MSI mode. For that, head to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI and create for every entry that possesses an "Interrupt Management" folder within the Device Parameters a new folder called "MessageSignaledInterruptProperties". In that context, create a DWORD entry called MSISupported and set that to 1. After you have done that with all devices under PCI, reboot and open your device manager. Hit view -> Resources by connection. Expand interrupt requests and scroll to the bottom. Every component that supports MSI mode will be at the very bottom with negative values. Take note of their hardware IDs and set the MSISupported entry to 0 for every component that is not one of those that support it.Or use a little application called "MSI_util" that will spare you from having to adventure through your registry yourself.Note that unstable overclocks or unmatching RAM timings affect work efficiency. As do multi- and hyperthreading techniques. People have seen improvements with disabling Intel's CPU hyperthreading feature. Disabling cores completely from the BIOS could be experimented with.Another thing to think about is core affinity. The handling of resource-heavy components that regularly are not known for multithreaded performance can be assigned to a single core, preferably for this topic's purposes assigned of course to one that does not deal with your USB activity (look at DispatchMon).For the audio handling specifically, go to your task manager's service tab and locate AudioSrv and AudioEndpointBuilder. Right-click, "Go to Process(es)". It will guide you to the corresponding svchost.exe process containing activity of the audio service, maintaining threads and scheduling tasks. Right-click on that process, "Set Affinity...". You can do this with processes from other drivers, services, or software as well.Managing process priorities can in theory help ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms685100%28v=vs.85%29.aspx ). These determine the scheduling pattern for your running software. Software should only compete with essential hardware-sided threads such as mouse input when set to real-time priority, so heed Microsoft's warning not to ever do that. You can experiment with setting other hardware-sided processes to lower priority levels though (such as the audio svchost.exe mentioned above).You can now see why disconnecting and disabling as much hardware and uninstalling as much software as possible is beneficial: less interrupts and tasks the CPU has to deal with, more cycles dedicated earlier to stuff you truly use. So apply this logic as far as you deem worth it. I argue, if you have a dedicated gaming PC, why not go all the way? And in the rare case you do need things like your USB 3 ports, printers or CD drive, Internet Explorer or Windows features, etc. - you can just enable them. Even stuff that requires reboots should not be bothersome to enable with fast boot times that come with SSDs. Obviously if you do all of your things on your main sole PC it's for you to decide just how far you want to go.You will also have to go through drivers and test yourself what kind of effect they have on DPC latencies and polling precision. As I mentioned, for chipsets the latest should be the best because with those manufacturers have no real obligation to release drivers regularly - they only ever do when they see major possible improvements or fixes.With graphic, network and sound cards and other addon hardware that's a different story. LatencyMon will give you a pretty good idea if drivers are bad in regards to DPC latency and how healthy your USB activity is (look at driver execution times, especially USBPORT.SYS).Sound components are complex and resource-heavy. I use an onboard chip with generic Windows drivers, but you will have to check yourself what the least heavy implementation is. Maybe external (TOSLINK, coax, USB) or internal (PCI) alternatives perform better than onboard solutions. USB sound cards likely wreck polling precision, but if you use one (or any USB device other than the mouse for that matter), try to get them to be hosted on a different controller than the mouse. If you use your keyboard on USB, consider reducing the keyboard polling rate with hidusbf.sys. Although, preferably plug your keyboard into PS/2 which as an asynchronous interface requires no periodic polling and thus leaves the CPU alone at times an USB-interfaced keyboard wouldn't.Other external sound solutions (TOSLINK, coax) still need an active playback device in your PC. I use my onboard chip to optically feed an external amplifier. But since the onboard chip doesn't have to apply digital-to-analog conversion or amplify the signal, I can imagine it operates less demandingly than when using the line-out.Disable any playback or recording devices you are not using, including any High Definition Audio Controllers in the device manager that come with your GPU.Maybe PCI add-on USB cards perform even better than those implemented onboard. I haven't tested that. Doubt it, but something you can look at if you have such an extension card.Disable your antivirus while you are gaming. Or consider not using one to begin with.Remember that running a game is very resource-heavy and will affect polling precision significantly. Another reason why frame caps and low-quality;high-performance settings in games you are looking to improve the experience of can be useful.Switch to 500Hz if you can't at all get 1000Hz stable on your system.TimerTool has some interesting effects on polling behaviour. After manually triggering it, this is what different settings look like. I won't make any assumptions as to why this happens.15.6ms/10ms/5ms/2.5ms/1.25ms:As you can see, basically anything above 0.5/1ms leads to my specific setup jumping between two discrete points of poll address timings. +30;-30us to be exact. I always set timer resolution to 0.5ms when I'm gaming.Here is what totally messed up polling behaviour looks like (my laptop):It feels horrible. Naturally lesser basic component performance, more strict thermal and power saving features, the built-in screen and so on play a role as well, but mousing instantly feels way better and controlled when switching to 500Hz instead of 1000Hz. The improvements just from reducing the polling rate on that laptop: