MouseDataQueueSize Registry Tweak – Placebo or an Actual Improvement?
In trying to improve the way our PCs and peripherals behave multiple settings need to be tested. You can mess with the Windows clock and tick, you can micro-adjust your timer resolution for higher precision, you can use custom power plans, and you can even tune in-game settings that affect things like your render queue and inputs.
While testing any of these settings you can document clear changes in either render latency (PresentMon or in-game graphs), mouse polling rate graphs, sleep delays, etc. One specific change that has been on my mind for a long time is the MouseDataQueueSize regedit value that supposedly improves your input latency.
The reason I have been stuck on this setting is because there is very little information online about what exactly are the positive consequences of tuning the value for MouseDataQueueSize (same for the keyboard queue size) and whether it is worth messing with it. Here are my conclusions.
What Is the MouseDataQueueSize Registry Tweak
To access and modify the setting I am referencing you need to open your Registry and navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mouclass\Parameters and create a Dword 32bit value called MouseDataQueueSize.
Important: To change the values properly you need to use a decimal value, not a hexadecimal one!
What this value changes are the mouse events buffered by the mouse driver and the reason you would want to reduce it from 100 to a lower value is to create a smaller buffer which in theory would reduce latency.
Objective Testing
The reason why this value change is considered an improvement in theory only is because no matter what tool or utility I used (polling graphs, real-time polling, etc) I could see no change when tuning the values.
However, the value change does affect your mouse inputs since if you use a value too low you will start noticing skips, weird clicking issues, and overall erratic movement making it impossible to use your mouse in Windows properly.
Because of this observation, people are speculating that this value only affects the buffer for mouse clicks and not movement but once again, I have yet to find a way to prove or test this specifically.
Subjective Testing
I have used tuned values for MouseDataQueueSize and KeyboardDataQueueSize for a long time (1 year+) and to me subjectively the lower buffer size feels better with my inputs feeling snappier while higher values make them feel smoothened out (similar to G-Sync removing tearing).
Most people can run a value of 30-60 safely while lower values need more testing (no mouse skips, missed clicks, etc). Whether this lower mouse buffer value provides me and other people who use tuned values (lower than 100 decimal) with an advantage is still unclear to me, but subjectively speaking I do like the feel of my mouse more.
A Possible Theory
An interesting theory relating to this tweaked MouseDataQueueSize value is that you get the actual benefits if you manage to match the raw data frame size of your mouse sensor with the Windows mouse buffer value.
As explained in the post, using a PMW3360 sensor data sheet we can identify the raw data frame size as 1296. Using 54 for the MouseDataQueueSize value multiplied by the 24 bytes from NTDDMOU.H, gives us the exact value of the PMW 3360.
I have tried to apply this method of calculation to modern mice but since all data is strictly controlled (PMW 3395, PMW 3950, etc) it is impossible for me to figure out their raw data frame size and to try and match it with the Windows mouse buffer value.
TL;DR
Objectively there is little information about the benefits of a tuned MouseDataQueueSize registry value but you can conduct subjective tests by editing the value and focusing on whether your mouse inputs improve or not (can run scenarios in aim trainers and document scores).
As long as the value you use is not too low there seems to be no obvious downside so there should be no reason for you not to try tweaking the default value (although there might also be no upside to a tuned value).
This really does seem to make a big difference. Subjectively I’d say I’d say it makes a way bigger latency impact then the difference between 1khz and 8khz mouse polling and a slightly bigger latency impact than the difference between 144hz and 240hz monitor refresh rate. So it probably improves latency by a couple ms. I play aimlab every day and when I changed the queue size to 50 decimal all my average scores instantly went up and after a few days i beat most of my high scores after weeks of plateauing. But be careful to not set the… Read more »