Overclock.net banner
Cancel
Create thread New Forums

MouseDataQueueSize Registry Tweak To Reduce Input Delay: Fact or Fiction?

6 reading
Jump to Latest
21 - 40 of 40 Posts
#25 ·
EastCoast said:
This is one of those old tweaks that hasn't been talked about much lately but never read any concrete evidence if it works or not.

For those that are interested...
Open Regedit
Goto: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mouclass\Parameters
Create Dword 32bit value called: MouseDataQueueSize
Most importantly you want to change the value using Decimal between 100 (highest) and 20 (lowest) increments of 10. Sweat spot is between 30-60. Some values show up differently in Hexadecimal.
Reboot PC
Start game and tab out to desktop. Cursor is squirrely? Click Not Registering in game? Increase the decimal value increments of 5 or 10.
Reboot PC

The gist is that this is placebo. However, some swear by it.
Click to expand...
i set it to 10 in decimals . shut down my system. reconnected my mouse and turned my system on. worked like a charm
 
#28 ·
I found that under the "Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mouclass\Parameters",
In addition to 'MouseQueueSize', there are two more key values: 'MouseQueueSizeLow' and 'MouseQueueSizeHigh'
 
#29 ·
SVSQUVSH said:
Questo è un vecchio post, ma posso confermare che Logitech Hero Sensor ha una dimensione della coda buffer di ~ 2576 byte (ho Logitech G Pro Wireless e ho configurato PoolMon tramite Visual Studio).

Calcoli:
2576 diviso 2 = 1288
Ora sappiamo che l'hardware interno memorizza 1288 byte di dati grezzi.

Calcola la dimensione perfetta per MouseDataQueueSize
1288 diviso per 24 = 53,6 (arrotondare a 54)


Pertanto, un decimale pari a 54 per il sensore wireless G Pro è perfetto se desideri applicare la modifica del registro MouseDataQueueSize!
Questo vale per qualsiasi mouse logitech che utilizza il sensore Hero 25k.
[/CITAZIONE]

My logitech g502 hero has 64 of MouseDataQueueSize
Click to expand...
 
Save
Reply Quote Rep+ Rep+
#30 ·
I would like to present bit different calculation, based on USB Controller PCI-e Payload size.

Payload size is the amount of data sent through PCI-E bus. For example one of my USB controllers has 512 bytes payload, the other has 256 bytes, and to this controller is connected Mouse.

Single 256 byte payload can transport up to 10,6 mouse requests of 24 byte size.

So MouseDataQueueSize of 11 is absolute minimum for proper functioning, and at 512 payload size it should be 22.

With buffer size of 11 however I already measured some data loss, at buffer size of 16 (1.5x multiplied) there was no longer such issue.

Also given a fact that my Rat 6+ has PWM 3360, queue size of 54 (1296 bytes) should be absolute maximum needed.


Now consider that data transported to the MouseQueue buffer dont idly sit there. They start to get processed immediatelly, and really fast. So even when PCI-E will deliver next payload, filled to the rim just with mouse requests, another 11 queues should be enough.

So I would recommend to use Queue of 22 for USB controllers with 256 byte payload, 44 queue size for 512 byte size payload, and up to 54 if you want to base the queue size on mouse buffer.
 
Save
Reply Quote Rep+ Rep+
#33 ·
itry2079 said:
I found "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mouclass" is used to operate PS/2 type mice and keyboards
(Microsoft officials say this: Configuration of keyboard and mouse class drivers - Windows drivers | Microsoft Learn ),
while "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mouhid" is the way to operate HID devices.
Does newer mice now use the HID protocol?
For example, Razer DeathAdder v2pro, which I use now, disables a HID protocol in the Device Manager of Windows10, which will cause the mouse to be invalid.
So I doubt if modifying the registry key in mouclass would be helpful for HID devices.
Click to expand...
Hi,
Yes, the system is still using mouclass service.
 
#34 ·
ajolly said:
How were you measuring this?
Click to expand...
Sorry for late reply. Tool is called Mouse Tester.

It captures data sent by the mouse and put them in the graph. Once the graph shows latency jumping to higher values than 4 miliseconds (my preferred polling rate), usually the double value, it was clear that some of the mouse requests were discarded or delayed.

In typical fashion people seek highest possible polling rate available to their mouse, as they expect it will decrease latency. This is however incorrect.

Lets say you have 120Hz refresh rate on your display, then 250Hz polling rate is more than sufficient as system gets updated about mouse 2x per display refresh rate. 1000Hz polling rate would take 4x more resources from CPU and require larger buffer, or there will be instance of buffer overflow, where system just throws away some of the mouse data.

Lower polling rate with properly sized buffer will do for internal system latency more, than high polling rate.
 
Save
Reply Quote Rep+ Rep+
#39 · (Edited)
Here's what an actual values works for me personally:
Laptop: Acer Predator Triton 500 SE (RTX 3080, i7-11800H)
Using stock Wooting 60HE connected with ****ty 5$ USB-C to USB-C cable (tachyon mode enabled, 70% of locked brightness and rapid trigger on all keys) & Logitech GPX 2
Superlight at 8000HZ connected with just wireless dongle.

So for MouseDataQueueSize it's - 16 Decimal (anything lower than that causes stuttering, demonic activity with cursor etc)

For KeyboardDataQueueSize it's - 3 Decimal, working extremely fine somehow.

Played Apex Legends for a significant amount of time (2h+) to establish that all working fine, all background apps was running - like Chrome with a bunch of tabs (30+), Discord, Telegram, Spotify desktop playing.
There's was issues with alt+tabbing when u go with wrong values of mnk queue size, but after applying "correct" ones for my setup - all of them disappeared.
I was curious how far i can go with all these values, so u don't have to, I'm gonna be updating if something goes wrong after further testing at current settings.

UPD: KeyboardDataQueueSize - 1 Decimal isn't working stable when starting streaming with Streamlabs, keyboard getting stutters + effect of sticky keys that's keep pressing buttons when you unpressed them after, you need to double click everytime for resolved it back to normal.
But if you're running all what I'm talked about above without stream - fine.
Right now testing KeyboardDataQueueSize - 3 Decimal - no issues so far.
MouseDataQueueSize - 16 Decimal - without any significant problems (1-3 cases when cursor skipping frames at desktop or teleporting, but it could be dust that's got into the censor, pretty often case for my environment)
 
#40 ·
SVSQUVSH said:
This is a old post, but I can confirm that the Logitech Hero Sensor has ~2576 bytes of buffer queue size, (I have the Logitech G Pro Wireless and setup PoolMon trough Visual Studio).

Calculations:
2576 devided by 2 = 1288
Now we know the internal hardware stores 1288 bytes of raw data.

Calculate perfect size for MouseDataQueueSize
1288 devided by 24 = 53,6 (round it up to 54)


So, a Decimal of 54 for the G Pro Wireless Sensor is perfect if you want to apply the MouseDataQueueSize Registry Tweak!
This applies for any logitech mouse that uses the Hero 25k Sensor.
Click to expand...
this value is applicable for g304 hero ?
 
21 - 40 of 40 Posts
About this Discussion
39 Replies
21 Participants
Last post:
imHeisen
Overclock.net
posts
28M
members
562K
Since
2004
The premier forum for overclocking experts and enthusiasts. Discuss hardware optimization, custom builds, benchmarking, cooling solutions, and pushing the boundaries of computing performance. From beginner guides to extreme overclocking, join our technical community to master system tuning.
Full Forum Listing
Explore Our Forums
Intel CPUs Hardware News NVIDIA PC Gaming Water Cooling