I haven't seen anyone provide evidence it improves anything such as in mouse graphs etc. It is interesting though that if you set it to 1 (one) after a certain amount of time clicks stop working all together and the OS doesn't seem to recover.

From one of my github research pages. GamingPCSetup/README.md at master · djdallmann/GamingPCSetup

Q: What are the default non-paged pool allocations for mouclass.sys and kbdclass.sys *dataqueuesize parameters indicated by the mouclass and kbdclass event providers?
The default non-page pool allocation for keyboarddataqueuesize is 1200 bytes and mousedataqueuesize 2400 bytes. The value of mousedataqueuesize is the value specified in the registry multiplied by the size of the structure MOUSE_INPUT_DATA (24 bytes) defined in NTDDMOU.H, 100 x 24 = 2400. Similarly for the keyboarddataqueue size it is the value specified in the registry multiplied by the size of the structure KEYBOARD_INPUT_DATA (12 bytes) defined in NTDDKBD.H, 100 x 12 = 1200.

Findings and Analysis


Registry Paths:

• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\kbdclass\Parameters\KeyboardDataQueueSize
  • Default Value: 100 (0x64)
• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\mouclass\Parameters\MouseDataQueueSize
  • Default Value: 100 (0x64)
  • This setting is not present in registry by default on Windows 10

References:

• Keyboard and mouse HID client drivers - Windows drivers
• Keyboard and mouse class drivers - Windows drivers
• PS/2 (i8042prt) driver - Windows drivers
• MOUSE_INPUT_DATA (ntddmou.h) - Win32 apps
• KEYBOARD_INPUT_DATA (ntddkbd.h) - Win32 apps

Q: How do the values in keyboarddataqueuesize and mousedataqueuesize affect the non-page pool memory allocation? How can you tell?
These values specify the driver's internal buffer size in nonpaged memory pool for each device object registered to the system, these buffers are dynamically allocated and removed when you connect/disconnect USB devices. Microsoft provides a tool called poolmon as part of the Windows Driver Kit (WDK) which let's you see the page and non-paged pool driver memory allocations as they are used and processed, you could also see similar changes with a Windows Performance Analyzer and Recorder capture. See findings and analysis for more information.
Findings and Analysis

Using poolmon you can view the total allocated buffer space by each driver for the connected devices, in the image below there is one physical Mouse connected and one physical Keyboard using the default values.

In this case there are two keyboard devices registered (HID Keyboard Device in device management), one that is part of the mouse and the keyboard itself which results in a value that is rougly 2400 bytes (1200 x 2) buffer space allocation and the remaining space likely allocated to some regular device object structure.
Then we see similar behavior for the mouse, again there is one Mice and other pointing devices registered (HID-compliant mouse) which results in a value that is rougly 2400 bytes (2400 x 1) and another set of bytes related to some other data structures.



Q: Are there any paged or non-paged pool buffer allocations or frees when you move the mouse?
Yes, when you move the mouse the usb drivers hidusb.sys and usbhub3.sys dynamically allocate and free bytes associated with the amount of data processed, the more you move the mouse the more bytes seen allocated and freed. This may be different depending on the type of device and supported driver such as USB3 vs USB2.

Findings and Analysis
Rows highlighted below represent byte allocation and frees since the last update cycle. The values displayed appear to be a total count of bytes allocated and freed perhaps since the PC was first booted as the numbers remain present after closing and re-opening poolmon.

Screenshot of byte allocations during mouse movement via poolmon

 

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\mouclass\Parameters\MouseDataQueueSize

• Default Value: 100 (0x64)
• This setting is not present in registry by default on Windows 10

how to get it to show up?

 

So the gist of this is to: reducing the mouse events buffered by the mouse driver so that you reduce mouse driver's internal buffer in nonpaged memory pool The assumed outcome would be a reduced latency as the buffer itself is smaller. However, a value to low could cause overflow errors to show up in the system event log.
IE:
"The ring buffer that stores incoming mouse data has overflowed (buffer size is configurable via the Registry)." Or something like that.

Otherwise, could result in the mouse itself malfunctioning. IE: Clicks not registering, etc.

The whole point of this is that, for whatever reason, some believe that the default buffer is to large. It's not to say that's correct. But it was something never addressed by MS since Win95.

How be it if true or not. I've not read anything concrete to suggest that lower it did anything favorable or not. However, a value too low does in fact cause a negative reaction. As timecard suggested.

Another thing caveate is that once the buffer is reduced what specific traits do we need to examine? Clicks, movement, both?

Another question is if you play some random First Person Shooter...lets say COD...without and with this tweak (lets say at 50) does one notice any difference however so slight? Be it good or otherwise?

 

Based on my observation it likely only affects the buffer for mouse clicks and not movement if the cursor still moves but clicks don't register at some point with really low values?

 

Ah, I see...it's just clicks.

 

Been a while since I tested but that's what I recall.

 

next 👀
Enable Network Card OnBoard Processor to finally fix wierd latency

 

Kinda posted about it here, not all onboard nics show indirection table when taskoffload is enabled. A few people I know said it populates inconsistently between restarts.

Registry Setting DisableTaskOffload, RSS and indirection...

Figured I drop this here, relates to DisableTaskOffload registry key, RSS function and the Indirection Table. You might find that this was disabled by chance which happened to me with some different intel drivers I was testing, I don't recall which at this point but just something else to be...

www.overclock.net

 

It works on intel based pci-e network adapters (related to my screenshot/post)

 

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

One possible theory for this might be because you set the OS buffer to match the raw-data framesize in your mouse's hardware buffer.

For example - if you use a mouse containing a pixart PMW3360 sensor, the internal hardware stores 1296 bytes of raw data per frame
(source: product datasheet - https://d3s5r33r268y59.cloudfront.n...017-05-07-18-19-11/PMS0058-PMW3360DM-T2QU-DS-R1.50-26092016._20161202173741.pdf)

Using a value of 54, multiplied by the 24 bytes from NTDDMOU.H, gives you exactly 1296. This matches the mouse hardware exactly, avoiding the risk of having too small a queue to handle an entire frame at once, and by minimizing the buffer size you possibly could avoid having any extra added latency from OS buffered data.

Does this actually work and/or result in a performance increase? I have no idea, but I thought it might be worth mentioning if you wanted to test it.

 

One possible theory for this might be because you set the OS buffer to match the raw-data framesize in your mouse's hardware buffer.

For example - if you use a mouse containing a pixart PMW3360 sensor, the internal hardware stores 1296 bytes of raw data per frame
(source: product datasheet - https://d3s5r33r268y59.cloudfront.n...017-05-07-18-19-11/PMS0058-PMW3360DM-T2QU-DS-R1.50-26092016._20161202173741.pdf)

Using a value of 54, multiplied by the 24 bytes from NTDDMOU.H, gives you exactly 1296. This matches the mouse hardware exactly, avoiding the risk of having too small a queue to handle an entire frame at once, and by minimizing the buffer size you possibly could avoid having any extra added latency from OS buffered data.

Does this actually work and/or result in a performance increase? I have no idea, but I thought it might be worth mentioning if you wanted to test it.

Excellent information. This is very insightful that can explain what range one can use. Do you know the data per frame on the newer sensors?

 

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.

 

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.

Sorry, I don't understand why should 2576 devided by 2

 

Now we need frame queue size for the PAW3399 (Razer 8k / Focus+) sensor.

 

Razer Viper 8K?

 

Esta es una publicación anterior, pero puedo confirmar que Logitech Hero Sensor tiene ~ 2576 bytes de tamaño de cola de búfer (tengo Logitech G Pro Wireless y configuré PoolMon a través de Visual Studio). Cálculos: 2576 dividido por 2 = 1288 Ahora sabemos que el hardware interno almacena 1288 bytes de datos sin procesar. Calcule el tamaño perfecto para MouseDataQueueSize 1288 dividido por 24 = 53,6 (redondearlo a 54) Por lo tanto, un decimal de 54 para el sensor inalámbrico G Pro es perfecto si desea aplicar el ajuste de registro MouseDataQueueSize. Esto se aplica a cualquier mouse logitech que use el sensor Hero 25k. [/CITA]

vine buscando cobre y encontré oro, gracias amigo <3

 

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.

 

So I doubt if modifying the registry key in mouclass would be helpful for HID devices.

Developing Keyboard and Mouse HID Client Drivers - Windows drivers

Keyboard and mouse HID client drivers are implemented in the form of HID mapper drivers.

learn.microsoft.com

 

I asked PixArt for the hardware buffer size of the PWM3399 sensor, which is 1296 bytes, same as PWM3360.
The Foucs+ sensor of Razer is an adjusted PWM3399, and I guess it may also be 1296 bytes.

 

Make the Key "Parameters" under mouclass and DWORD (32bit) MouseDataQueueSize in it with Value 100.

 

would there happen to be a way to make the computer use the most of queue area before sending the mouse data forward?
i am trying to purposefully delay the mouse reaction time as a joke to my friend.

 

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.

i set it to 10 in decimals . shut down my system. reconnected my mouse and turned my system on. worked like a charm

 

What type of sensor is built into the mouse you are using?

 

i wonder if he got banned for roach-posting

 

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'

 

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

 

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.

 

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.

How were you measuring this?

 

FYI, if I set this too low my mouse will stop responding, and ill need to unplug/plug it back in. This is only on mice with extremely long usb extensions though, so take that for what its worth.

 

Anyone have the decimal code for this sensor ?
Sensor Model PixArt PAW3395 MouseDataQueueSize = ????

 

@reticulex is always 1296 bytes raw data for the 3395. So use 54 as a value

 

what value to use for PixArt PAW3349

 

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)