I tried that exact keyboard (cosair k65 mini) and it wasn't near as fast as the Steelseries Apex ProEonds wrote: ↑17 Sep 2021, 02:21
Tried what? A better mouse and keyboard doesn't make your pc worse, yes the polling rate is more "taxing" on cpu resources but if you have a properly optimized os then it's not an issue.
Reduce Input Delay (Mouse & Keyboard Buffer Size)
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
You have to manually set the corsair k65 mini (Silver Speed switches) to 8khz + update the firmware for it. The only thing that the Apex has better is actuation distance which is relatively important.Rallaz wrote: ↑17 Sep 2021, 07:27I tried that exact keyboard (cosair k65 mini) and it wasn't near as fast as the Steelseries Apex Pro
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
I did all that, within the software and tried modding it. Ended up returning it since it was much worse on my end.Eonds wrote: ↑17 Sep 2021, 07:32You have to manually set the corsair k65 mini (Silver Speed switches) to 8khz + update the firmware for it. The only thing that the Apex has better is actuation distance which is relatively important.Rallaz wrote: ↑17 Sep 2021, 07:27I tried that exact keyboard (cosair k65 mini) and it wasn't near as fast as the Steelseries Apex Pro
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
A buffer is a buffer. There needs to be a reason for the buffer to be 'full' to make reducing a buffer have any effect.
So the real question is, assuming this 'works' for some, why the buffer becomes 'full' in the first place.
Underlying issues or bad optimization somewhere, or just a matter of 'default' behavior in combination with a less powerful system.
Since most things OS gets controlled on core 0 traditionally (For the most part), just removing any game from the first core significantly improves a vast amount of OS related mechanics and subsequently the behavior of certain games.
Much better option than to screw around with tools like IRQ affinity which is almost not really supported for most hardware or has side effects (Exception being some storage drivers and network adapters with RSS support).
Unloading Core 0 fixes a bunch of contention.
So the real question is, assuming this 'works' for some, why the buffer becomes 'full' in the first place.
Underlying issues or bad optimization somewhere, or just a matter of 'default' behavior in combination with a less powerful system.
Since most things OS gets controlled on core 0 traditionally (For the most part), just removing any game from the first core significantly improves a vast amount of OS related mechanics and subsequently the behavior of certain games.
Much better option than to screw around with tools like IRQ affinity which is almost not really supported for most hardware or has side effects (Exception being some storage drivers and network adapters with RSS support).
Unloading Core 0 fixes a bunch of contention.
LTSC 21H2 Post-install Script
https://github.com/Marctraider/LiveScript-LTSC-21H2
System: MSI Z390 MEG Ace - 2080 Super (300W mod) - 9900K 5GHz Fixed Core (De-lid) - 32GB DDR3-3733-CL18 - Xonar Essence STX II
https://github.com/Marctraider/LiveScript-LTSC-21H2
System: MSI Z390 MEG Ace - 2080 Super (300W mod) - 9900K 5GHz Fixed Core (De-lid) - 32GB DDR3-3733-CL18 - Xonar Essence STX II
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
Can you man explain me how to remove any game from core0 then unloading some stuff from it? Thanks in advanceMT_ wrote: ↑22 Sep 2021, 09:00A buffer is a buffer. There needs to be a reason for the buffer to be 'full' to make reducing a buffer have any effect.
So the real question is, assuming this 'works' for some, why the buffer becomes 'full' in the first place.
Underlying issues or bad optimization somewhere, or just a matter of 'default' behavior in combination with a less powerful system.
Since most things OS gets controlled on core 0 traditionally (For the most part), just removing any game from the first core significantly improves a vast amount of OS related mechanics and subsequently the behavior of certain games.
Much better option than to screw around with tools like IRQ affinity which is almost not really supported for most hardware or has side effects (Exception being some storage drivers and network adapters with RSS support).
Unloading Core 0 fixes a bunch of contention.
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
Use Process Lasso, it has an option for selecting CPU affinity for a process.skkiNN wrote: ↑22 Sep 2021, 09:50Can you man explain me how to remove any game from core0 then unloading some stuff from it? Thanks in advanceMT_ wrote: ↑22 Sep 2021, 09:00A buffer is a buffer. There needs to be a reason for the buffer to be 'full' to make reducing a buffer have any effect.
So the real question is, assuming this 'works' for some, why the buffer becomes 'full' in the first place.
Underlying issues or bad optimization somewhere, or just a matter of 'default' behavior in combination with a less powerful system.
Since most things OS gets controlled on core 0 traditionally (For the most part), just removing any game from the first core significantly improves a vast amount of OS related mechanics and subsequently the behavior of certain games.
Much better option than to screw around with tools like IRQ affinity which is almost not really supported for most hardware or has side effects (Exception being some storage drivers and network adapters with RSS support).
Unloading Core 0 fixes a bunch of contention.
-
- Posts: 208
- Joined: 01 Dec 2020, 14:41
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
So I ran some tests with three different values for MouseDataQueueSize. It does in fact seem like 0 sets it at the default value. The non-paged memory pool for both no registry value and 0 is 9872. With 16, however, it is only 1744.
It looks like the default value is 100 and setting it to 0 just goes to default.
It looks like the default value is 100 and setting it to 0 just goes to default.
i9 9900k | RTX 2080 Ti | 32 GB 4x8GB B-Die 3600 MT/s CL16 | XV252QF 390 Hz 1080p | AW2518H 240 Hz 1080p | PG279Q 144 Hz 1440p
Razer Viper 8K | Artisan Zero Mid XL | Apex Pro TKL | 1 gbps FiOS (Fiber)
Razer Viper 8K | Artisan Zero Mid XL | Apex Pro TKL | 1 gbps FiOS (Fiber)
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
i tried 200000 hex and 10 hex on keyboarddataqueuesize and couldn't find any difference when playing osu.
i played the same map at least 5 times with different values and every time i got very similar results (i.e. average hit error 6,7,8ms late)
i also disabled all cores on the cpu except core 0 (to be 100% cpu bound) and the only difference that was that the game slowed down (longer loading times, freezes)
upd: tested with arduino and light sensor (cpu bound but only on one core) with rtss and gpu test triangle and there is no difference
i played the same map at least 5 times with different values and every time i got very similar results (i.e. average hit error 6,7,8ms late)
i also disabled all cores on the cpu except core 0 (to be 100% cpu bound) and the only difference that was that the game slowed down (longer loading times, freezes)
upd: tested with arduino and light sensor (cpu bound but only on one core) with rtss and gpu test triangle and there is no difference
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
You need to use decimal (assuming those translate from hex to normal decimal values). You also need to reboot between changes.
This 100% does do something. You can set it to 0 and basically brick your mouse. Closer you get to 0 the better, but also start generating errors if you go too far, have to find the sweet spot.
This 100% does do something. You can set it to 0 and basically brick your mouse. Closer you get to 0 the better, but also start generating errors if you go too far, have to find the sweet spot.
Re: Reduce Input Delay (Mouse & Keyboard Buffer Size)
almost any value will work, you can check by yourself with poolmon. take the log file with "poolmon -n C:\log.txt" and search for kbdc/mouc, values will change if queue size changed (delete log.txt before taking the log again) source
values like ffffffff will not work (it will default to 64 hex) because it exceeds the amount of free RAM
ofc
0 is invalid and = default value of 64 hex
would you agree to do a blind test?