Reduce Input Delay (Mouse & Keyboard Buffer Size)

[Ferr0]

The most significant inconsistency people are feeling is caused by the C-State messing things up. Windows don’t respect the Bios flag for some models. Also the PowerPlans are not fully optimised to use “C1 only”, not even the Ultimate and the Bitsum.

How to check:

You can check the amount of time in every step with cmd -> perfmon and then adding the counters for C1, c2, c3 and Idle. The C1 and Idle counters should be the same (for C1 max) or both zero (in case of real c0). Anything different is bad. The frequency graph in MouseTest is a good benchmark since it’s very sensitive to latency. Just check the variance. It should be much more precise in C0 or “C1 only” an more spread in deeper states. Variance is caused mostly by the cpu delaying the Interrupt Processing (making the counter lower than frequency) and then processing it in batches (making higher than the frequency of the mouse).

How to fix

Use Power Saver Explorer and choose one of the following:

A: Processor -> Disable Idle and chave to disable idle. This will force C0, the faster state but will generate MUCH more heat.

Disclaimer: It will not work well for systems with HT enabled. HT needs the idle thread to work efficiently and with idle disabled the Windows keep the C0 by doing an endless loop. With HT off it should be the fastest possible, but check your temps!

B: Under processor put both PROMOTE and DEMOTE state threshold to 100. It is trick because in one they use the Busy counter and in the other the Idle. It will force C1 State Max, in perfmon it should be equal to the idle graph as a idle is in C1. Probability the best, since Disable Idle They have diminished returns, and C1 is Already too powerful. It works well with HT.

After check MouseTester again. You don't need to reboot, so you can easily do A/B testing.

Doing this does add input lag though

What creates input lag between those two choices?

For me, memory latency increases when only using Disable idle. That's with my 5800X. However it was the opposite with my 3800X.

So my personal anecdote is that when I first used that tweak I did feel like it was worse then idle enabled. However, now that we have some latency monitoring tools someone has actually tested it. This is the only actual data point we have regarding this tweak as far as I'm aware. https://youtu.be/sVK96m9I_U8

[thizito]

THIS IS NOT LATENCY MEASUREMENT
NOT LATENCY


N O T

L A T E N CY


UNDERSTAND THE [email protected]%$ TEST.

the tests are as usefull as fr33thy as human being.
`Click to photon doesn't CONTINUOUSLY measure latency, it it only capable of measuring the latency of a certain event (eg, click.) This is a problem because latency is not stable, latency spikes exists. Which may go COMPLETELY unnoticed by this method of testing. You can slave alot of trials (like 100+) to minimize this, but its still entirely possible that all latency spikes would dodge the capture.`
By MaxTendency on this forum, just grabbed a quick search.`

To make a plus, fr33thy is terrible at tech. he burn people hardware and his own motherboards more then two times because he copied a XOCer timing settings... He is the guy who recommends Hardware Accel in programs to be off cause have 0 understanding of the setting, this is the level.

Plus v2. I would bet my pc that his shit is unstable linpack + poorly configurated and with alot RNG

[Ferr0]

THIS IS NOT LATENCY MEASUREMENT
NOT LATENCY


N O T

L A T E N CY


UNDERSTAND THE [email protected]%$ TEST.

the tests are as usefull as fr33thy as human being.
`Click to photon doesn't CONTINUOUSLY measure latency, it it only capable of measuring the latency of a certain event (eg, click.) This is a problem because latency is not stable, latency spikes exists. Which may go COMPLETELY unnoticed by this method of testing. You can slave alot of trials (like 100+) to minimize this, but its still entirely possible that all latency spikes would dodge the capture.`
By MaxTendency on this forum, just grabbed a quick search.`

To make a plus, fr33thy is terrible at tech. he burn people hardware and his own motherboards more then two times because he copied a XOCer timing settings... He is the guy who recommends Hardware Accel in programs to be off cause have 0 understanding of the setting, this is the level.

Plus v2. I would bet my pc that his shit is unstable linpack + poorly configurated and with alot RNG

Its entirely possible that latency spikes go ignored by a test with even 100 samples but using a hypothetical to dismiss data that does exist is a big misstep imo.

No offense but fr33thy has about as much credibility as anyone else in the pc tweaking community. There are a lot of missteps as people try to find the right answer. Arguing that fr33thy is terrible at tech is completely irrelevant and misses the point entirely. I really don't care if someone has said something wrong in the past, the point is he did click to photon tests in each game after showing the exact changes mentioned in the post above and showed that the latency slightly increased. On top of that a lot of the other benchmark categories got worse as well.

To me, this makes sense with what I've noticed but obviously it could be entirely different for someone else depending on their setup. For now, I won't be using idle disabled.

[Brainlet]

DO NOT disable idle when using Hyperthreading. His test is meaningless since he only tested it with HT on... In general I'd take his "testing" with as much scepticism as e.g. r0ach's list. Both make claims without proof. No, writing down some numbers in a spreadsheet with 0 context or how they've been measured is not "proof". Just because he has a tool it doesn't mean his data or testing methodology is correct nor do his settings and general setup match everyone else's. As usual, test things on YOUR OWN system and be aware of dependencies like these.

[Ferr0]

DO NOT disable idle when using Hyperthreading. His test is meaningless since he only tested it with HT on... In general I'd take his "testing" with as much scepticism as e.g. r0ach's list. Both make claims without proof. No, writing down some numbers in a spreadsheet with 0 context or how they've been measured is not "proof". Just because he has a tool it doesn't mean his data or testing methodology is correct nor do his settings and general setup match everyone else's. As usual, test things on YOUR OWN system and be aware of dependencies like these.

I completely agree with you about testing on your own system and views on general skepticism regarding this stuff, and perhaps the way I phrased my initial comment regarding disabling idle was too matter-of-fact. It was meant to be taken as a possible alternative to what was proposed earlier in the thread. Ultimately what seems better to you on your own system is going to be best. I would like to point out though, he did actually disable HT in his tests. He was on a 10900k and had 10 cores in task manager. He has also provided context as to how he does his measurements, the videos are on his channel. Obviously no singular "experiment" should be taken as fact but it does offer something to take into possible consideration.

One last thing though is that character attacks are not helpful in any manner. Things like, "the tests are as usefull as fr33thy as human being" really only serve the purpose of being childish.

[Brainlet]

DO NOT disable idle when using Hyperthreading. His test is meaningless since he only tested it with HT on... In general I'd take his "testing" with as much scepticism as e.g. r0ach's list. Both make claims without proof. No, writing down some numbers in a spreadsheet with 0 context or how they've been measured is not "proof". Just because he has a tool it doesn't mean his data or testing methodology is correct nor do his settings and general setup match everyone else's. As usual, test things on YOUR OWN system and be aware of dependencies like these.

I completely agree with you about testing on your own system, ultimately what feels better to you is going to be best. I would like to point out though, he did actually disable HT in his tests. He was on a 10900k and had 10 cores in task manager.

Got a link to where he tested idle with HT off? The single thread performance results and the fact that he specified "HT OFF" in #53 and #55 suggest he has been testing everything with HT on.

[Brainlet]

Alright, I skimmed through the hour-long videos to find it. Let's break it down into a TLDR of the things I gathered:
- He's running 5.2 GHz which suggests he hasn't properly stress tested for stability (likely the same applies to RAM).
- He turned off HT in BIOS.
- He changed two more settings at once besides "disable idle".
- The CPU-Z single threaded benchmark is, even according to him, "the same" proving that #19 in the spread sheet was tested with HT on. Very misleading.
- Rebooting rerolls the "ideal processor" selection (check with Process Explorer) of threads which makes testing things in general very tiresome due to inconsistencies across reboots.

All in all, I'd be VERY careful with blindly following his advice (anyone's advice in general). If you're determined to tweak your system, be aware that it will be a long process of information gathering and testing on your own system. Guides show you WHAT can impact your system, even if it's not always clear HOW it will impact it.

One last thing though is that character attacks are not helpful in any manner. Things like, "the tests are as usefull as fr33thy as human being" really only serve the purpose of being childish.

If you're referring to me, I didn't post this comment.

[Ferr0]

Alright, I skimmed through the hour-long videos to find it. Let's break it down into a TLDR of the things I gathered:
- He's running 5.2 GHz which suggests he hasn't properly stress tested for stability (likely the same applies to RAM).
- He turned off HT in BIOS.
- He changed two more settings at once besides "disable idle".
- The CPU-Z single threaded benchmark is, even according to him, "the same" proving that #19 in the spread sheet was tested with HT on. Very misleading.
- Rebooting rerolls the "ideal processor" selection (check with Process Explorer) of threads which makes testing things in general very tiresome due to inconsistencies across reboots.

All in all, I'd be VERY careful with blindly following his advice (anyone's advice in general). If you're determined to tweak your system, be aware that it will be a long process of information gathering and testing on your own system. Guides show you WHAT can impact your system, even if it's not always clear HOW it will impact it.

One last thing though is that character attacks are not helpful in any manner. Things like, "the tests are as usefull as fr33thy as human being" really only serve the purpose of being childish.

If you're referring to me, I didn't post this comment.

Again, I'm not saying anyone should blindly follow his advice. People should definitely take what he says with a big grain of salt, and that goes for any tweak or anything people read about.

It's very possible that he hasn't properly stress tested but its also possible he has, it's not impossible to hit a stable 5.2ghz on a 10900k. That just reinforces the idea that people should take what they read with a lot of skepticism but I don't think that means this should be flat dismissed or ignored based on conjecture, it should hold as much wait as any other tweak until individuals test it on their system and decide what's best. I'm also not saying there aren't inherent problems with his testing methodology, I'm just saying he did disable hyper threading and his methodology is actually documented.

Again though, I'm not saying you should take his test results as fact. I'm saying there's a possibility that the advice from earlier in this thread is actually wrong and you should test the values yourself.

That last comment about childish behavior wasn't aimed at you, I should have quoted the guy that did.

[thizito]

It's very possible that he hasn't properly stress tested but its also possible he has, it's not impossible to hit a stable 5.2ghz on a 10900k.

he cant drop 37ns in ram timing with the most money in the planet world. he is clearly not capable of cooling 20 threads for 5.2 linpack

he is not high end enthuasist at all

[howiec]

I wouldn't bash his suggestion for disabling CPU idle because in theory it can have merits.

I've been running with latency optimized BIOS and Windows power plan settings for a very long time now (C-states disabled in BIOS, disable core parking, adjusting various promote/demote thresholds, etc.).

He is technically correct that properly disabling CPU idle should put your CPU in C0 100% of the time and will significantly increase minimum CPU temps/power consumption even without actually loading the CPU with something like Prime95.

Now in practice the latency penalty from transitioning to C0 from C1 should be on the order of single digit or lower microseconds in modern Intel CPUs. I'm not sure how Zen 3 fares but I'm willing to bet that they're similar now.

Whether or not you will see a noticeable benefit depends on many factors including your sensitivities and your use-case, so you'll have to test it yourself. Some programs, if not written to handle the possibility of C1 being disabled, may mistakenly view the CPU as fully loaded and resource constrained, and thus respond inappropriately but I haven't run into this myself.

The obvious tradeoff here is a large jump in "idle" CPU temps and power draw for a relatively small latency improvement in most cases.

So, you could choose to selectively disable CPU idle during periods of specific program/gaming sessions assuming you see a latency/performance benefit at the expense of power/heat, instead of just leaving idle disabled all the time.

Oh and btw, MouseDataQueueSize does make a difference.