Does the Timer Resolution also reduce input lag?
What about ACK intervals? 1 vs 2
TCP Delay?
Does HPET cause input lag?
Do these parameters help reduce, or cause more inconsistencies and input lag?
Timer Resolution, ACK, TCP Delay, etc
Re: Timer Resolution, ACK, TCP Delay, etc
Timer Resolution does not reduce input lag.
DPC latency corresponds with this behaviour - the program sets timer resolution to 1ms (1000 microseconds test interval) and schedules an indicator task, then it gets an update each tick how long the processor needed to address the task. If other tasks or operations occupy the processor, the task will take more time to be addressed, if it is fully occupied with other stuff the task may not be addressed in a single interrupt cycle and you get a spike. I. e. a long-lasting and ultimately noticeable halt on all tasks that are of lower priority than the one(s) currently occupying the processor.
When you manually set timer resolution to .5ms it changes the test interval to 500 microseconds because tasks can be scheduled or ended more frequently now, but it does not change how long the processor needs to address a task. You can however more frequently free up processor ressources or threads and so DPC latency can be reduced if some tasks would otherwise have run unncessarily long.
HPET enables the system hardware (IRQ) to interrupt the CPU more frequently as per a QueryPerformanceFrequency function. Windows uses other timers by default (TSC) but can synchronize the platform clock with the system clock for hardware interrupts. So if your mainboard and CPU support HPET, you should leave it enabled in your BIOS and let Windows do the rest.
If you force Windows to use the platform clock as the system clock (bcdedit /set useplatformclock true) it can affect DPC latency because hardware interrupts are now issued more frequently (QueryPerformanceFrequency increases) and the processor is more occupied with I/O tasks even though the hardware doesn't necessarily need that kind of precision. If hardware requires it (e. g. with audio equipment) Windows can call the HPET PerformanceFrequency even if you do not force it to be utilized as system clock yourself. So there should be no need to force platform clock manually.
Not sure how TCP settings could affect input latency. Games use UDP-based packet transfer. And also prediction - so even internet latency doesn't affect perceived input latency.
All of this is my practical understanding of the matters and I doubt it's extremely accurate on a non-superficial level, so people with more insight are welcome to clear things up.
What I can promise you is that neither of these things causes input lag, let alone noticeable amounts. Look at flood's test for certainty.
DPC latency spikes definitely cause lag in the system, it's as I said a mini-freeze of most operations and you notice that. If your DPC latency goes above 1 tick cycle regularly (1ms) you should find and eliminate the culprit.
Basically, the timer resolution is the tick rate of Windows and determines scheduling precision of thread activity in terms of software operations (driver tasks). That doesn't mean it affects the rate actions are performed at on a hardware-level, but how often Windows interrupts the hardware to check for the status of scheduled or periodic operations and either add new tasks or timeout others. Setting timer resolution lower than the default 15.6ms can help applications to perform more accurately because they are able to more frequently access drivers to have Windows create new or kill old tasks (any task the system may have delegated to the hardware and would potentially run for an unnecessary amount of time with a longer timer duration).download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx
DPC latency corresponds with this behaviour - the program sets timer resolution to 1ms (1000 microseconds test interval) and schedules an indicator task, then it gets an update each tick how long the processor needed to address the task. If other tasks or operations occupy the processor, the task will take more time to be addressed, if it is fully occupied with other stuff the task may not be addressed in a single interrupt cycle and you get a spike. I. e. a long-lasting and ultimately noticeable halt on all tasks that are of lower priority than the one(s) currently occupying the processor.
When you manually set timer resolution to .5ms it changes the test interval to 500 microseconds because tasks can be scheduled or ended more frequently now, but it does not change how long the processor needs to address a task. You can however more frequently free up processor ressources or threads and so DPC latency can be reduced if some tasks would otherwise have run unncessarily long.
HPET enables the system hardware (IRQ) to interrupt the CPU more frequently as per a QueryPerformanceFrequency function. Windows uses other timers by default (TSC) but can synchronize the platform clock with the system clock for hardware interrupts. So if your mainboard and CPU support HPET, you should leave it enabled in your BIOS and let Windows do the rest.
If you force Windows to use the platform clock as the system clock (bcdedit /set useplatformclock true) it can affect DPC latency because hardware interrupts are now issued more frequently (QueryPerformanceFrequency increases) and the processor is more occupied with I/O tasks even though the hardware doesn't necessarily need that kind of precision. If hardware requires it (e. g. with audio equipment) Windows can call the HPET PerformanceFrequency even if you do not force it to be utilized as system clock yourself. So there should be no need to force platform clock manually.
Not sure how TCP settings could affect input latency. Games use UDP-based packet transfer. And also prediction - so even internet latency doesn't affect perceived input latency.
All of this is my practical understanding of the matters and I doubt it's extremely accurate on a non-superficial level, so people with more insight are welcome to clear things up.
What I can promise you is that neither of these things causes input lag, let alone noticeable amounts. Look at flood's test for certainty.
DPC latency spikes definitely cause lag in the system, it's as I said a mini-freeze of most operations and you notice that. If your DPC latency goes above 1 tick cycle regularly (1ms) you should find and eliminate the culprit.
Re: Timer Resolution, ACK, TCP Delay, etc
i hypothesize that sleeping for 30min more every day will reduce the total-chain input lag (hand motion to brain perception) by more than any of these settings