Windows timer resolution tool in form of system service

You said you already have v1 timer resolution service. You should unzip new source file there - to folder with v1 service, then stop and delete existing service, then delete exe-file of existing service and then build new exe-file and create new service.

 

Yeap he is clean after 10minutes or automatically max stand by memory list clean?sorry my english is little bad

 

Your new version should check every 10 minutes the amount of free memory, and if free memory is less than 500MB it cleans standby list.

Both - 10 minutes interval and 500MB value - can be changed, but I would not advise to change them.

 

THANKS A LOT

 

Big thanks for such minimized version. More simple than using ISLC.

 

Have you tested it? I have - on Win10, but there is a chance that it can fail on different OS (or even different version of Win10).

 

Yes, but I'm on Win10 aswell. Btw, found weird bug that for some reason my C# compiler was not in the PATH.

 

It should not be in PATH. "Install-STRService.ps1" script should determine the full path to csc.exe.

 

Could it be possible to use KeSetTimer instead of NtSetTimerResolution as a way around "The Great Rule Change" that happened in windows 2004?

 

Well, I guess you right, but even though after I hardcoded path to csc.exe - everything worked fine So maybe I just messed up a bit with my OS.

 

So called "The Great Rule Change" is about timeBeginPeriod function. We do not know whether this function calls NtSetTimerResolution.
KeSetTimer function is OS kernel function for device drivers, and it sets a timer object, not a system timer resolution.

Even if NtSetTimerResolution now gets the same results as described for timeBeginPeriod - no big deal. Expertly coded programs do not depend on system timer resolution. Since Win7 days I witnessed only one game with stutters cured by NtSetTimerResolution.

 

Are you sure you need stanby list cleaning?

 

More on subject:
https://docs.microsoft.com/en-us/wi...pi/nf-processthreadsapi-setprocessinformation
https://docs.microsoft.com/en-us/windows/win32/procthread/quality-of-service

According to that when applications are in the foreground and in focus, or audible they use standard high performance.

 

I think yes, because only 8gb ram. So every piece matters.

 

Actually the need for standby list clean was only on some of rigs with early Win10 builds because they showed glitched behaviour, and standby list cleaning solved it. Not because of 8GB of RAM.

 

Very interesting results I just got in perfmon.exe.
I discovered new performance counter - "Processor Information"\"Clock Interrupts/sec" with description:

I started session with that perf.counter and noticed two things:
- it was steady on one core but not on core "0";
- and sometimes small spikes appeared on some other cores.

And then I decided to apply a system timer resolution tweak, and look what I witnessed:

Code:

Processor Information\Clock Interrupts/sec

cores->      00 01 02 03 04 05 06 07 08 09 10 11
                                         
01:20:01      1, 3, 1, 1, 1, 0, 0, 0, 2, 0, 0,64
01:20:02      3,11, 0, 0, 1, 0, 0, 0, 1, 0, 0,64
01:20:03      1, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0,64
01:20:04      0, 0, 0, 0, 2, 0, 0, 0, 1, 0, 0,64
01:20:05      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,64
01:20:06      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,64
01:20:07      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,64
01:20:08      0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0,64
01:20:09      2, 0, 0, 0, 2, 0, 2, 0, 0, 0, 0,64
01:20:10      3, 4, 0, 1, 0, 2, 3, 0, 0, 1, 0,64
01:20:11      0, 2, 0, 0, 0, 2, 0, 0, 0, 0, 0,64
01:20:12      0, 2, 0, 0, 0, 0, 0, 0, 1, 0, 0,64
                                         
01:20:13     26,12, 1, 1,20, 8, 0, 0, 7, 0, 0,54
01:20:14     40,16, 2,20,33,13, 9, 1,14,13, 1,17
01:20:15      8,18, 3, 9,25,12,13, 1,12,25, 1,20
01:20:16     24,16, 0,18,31,11,21, 0,19,14, 0,12
01:20:17      8,22, 1,18,16,14,13, 1, 7,16, 1,16
01:20:18     22,11, 0,17,22, 3, 8, 1, 5,18, 0,15
01:20:19     13,29, 0,19,13, 9, 5, 1, 7,20, 1,13
01:20:20     22,22, 1,20, 6, 6, 6, 0,10,15, 9,16
01:20:21     13,40, 0,16, 8, 7, 7, 0, 6,17, 1,14
01:20:22     65,18, 1,18,38,19, 2, 0,19,11, 0,14
01:20:23      6, 7, 2,27,12, 8,12, 1,12,20, 1,24
01:20:24     51, 9, 1, 6,17, 9, 9, 1, 5,10, 1,19
01:20:25     36, 0, 0, 0, 0,28, 0, 0, 0, 0, 0, 0
01:20:26      0, 0, 0, 0, 0,57, 0, 0, 0, 7, 0, 0
                                         
01:20:27      0, 0, 0, 0, 0, 0, 0, 0, 0,64, 0, 0
01:20:28      0, 0, 0, 0, 0, 0, 0, 0, 0,64, 0, 0
01:20:29      0, 0, 0, 0, 0, 0, 0, 0, 0,64, 0, 0
01:20:30      0, 0, 0, 0, 0, 0, 0, 0, 0,64, 0, 0
01:20:31      0, 2, 0, 0, 1, 0, 0, 0, 0,64, 0, 3
01:20:32      4, 4, 0, 0, 3, 2, 0, 0, 1,64, 0, 1
01:20:33      3, 3, 0, 1, 1, 0, 1, 0, 2,64, 0, 1
01:20:34      0, 0, 0, 0, 0, 1, 0, 0, 0,64, 0, 2
01:20:35      1, 1, 0, 0, 2, 0, 0, 0, 1,64, 0, 1
01:20:36      2, 2, 0, 0, 0, 1, 0, 0, 1,64, 0, 0
01:20:37      1, 3, 0, 0, 0, 0, 0, 0, 0,64, 0, 1

For the first 12 seconds (with default timer resolution) core "11" was a dedicated handler of clock interrupts (with occasional interrupts on other cores).
Then I turned maximum timer resolution for 13 seconds - and suddenly clock interrupts started to spread over several cores (without dedicated handler).
And then I returned default timer resolution - and core "09" became the dedicated handler of the clock interrupts.

PS
Note that 64 interrupts per second corresponds to 15.6 ms of timer resolution.

 

@mbk1969 last question!!!!!!!!! Are you use on your primary gaming system Timer resolution 0.500?

 

No.

 

It got worse the less non-allocated memory was available, so it was less of an issue the more available total RAM you had.
Pretty sure it also wasn't just some rigs, but every rig with Geforce and later also Navi GPUs (but not Polaris and Vega). Could 100% reproduce it by accumulating standby list memory by simply copying files, which also enabled me to also reliably confirm it got fixed in later GeForce and Navi drivers. I even temporarily went back to the last known faulty drivers to be certain.

 

Speaking of program developers... Why is the maximum timer resolution 0.5ms in Windows if virtually no games or even microsoft's own tools and applications **never** call for 0.5ms?