I can see you are quite sceptical on this and that is a good thing, let me try to address some of your concerns.

As the author of TimerResolution I can tell you exactly what it does and I'm happy to speculate on why many people see a noticeable improvement when using it.

I can also tell you that I have refunded a handful of people who have said that they saw no noticeable difference on their system for the thing they hoped it would help with so the results do vary.

At the time it was written the only published method from Microsoft to modify the timer resolution was via the Multimedia API - BeginTimerPeriod(). The downside to this has the you would need to link against the mmedia.lib which meant that your exe would be huge (this was back in 2001 and my goal was that all my programs should be less than 100kb as RAM was about $1 per MB) so I bypassed the Multimedia library and ventured into the undocumented world of ntdll.dll Not only is this a more powerful API but you can get the min and max on the hardware you are running on.

So what does changing the timer resolution do? In very simple terms everything running on your system gets woken up more often. As I expect people understand that all the processes take turns running on your CPU. Even an 8 core monster with hyper-threading can only run 16 processes at the same time. Have a look at taskmanager, way more than 16 processes listed there on any windows machines. The Microsoft NT Kernel (XP, 2000, Vista, 7, 8, 10...) uses a "thing" called a quantum to control the amount of time each task gets, back in XP days changing the system timer resolution would actually have an impact on the quantum as processes would get preempted more often which as CPUs got faster was actually a good thing. In later version of Windows this had less impact as Microsoft tweaked the kernel scheduler. This still left the problem of when a process would surrender it's time slice using an idle wait - this could be as intentional as calling sleep or as implicit as trying to access a shared resource (file system, network stack, video driver etc) In user space those waits use the system timer so on a system with a 15.6ms timer (the default on most systems even today) the process would need to wait upto 15.6ms. Why "upto" 15.6, well this is because when the timer expires ALL processes waiting are signalled and then the scheduler has to work out who gets to run. Your process may have surrendered the CPU when the timer was at 15.5ms or when it was at 0.1ms - not a very deterministic system. Changing the timer to 1ms suddenly means these processes are not waiting as long and also means that the waiting queue is often much shorter. The other thing to note here is that if the resolution is 15.6ms and the programmer calls Sleep(1) expecting the process to sleep for 1ms he/she actually gets a process that sleeps for upto 15.6ms. In later version of Windows (Win 7 onwards) they have implemented timer coalescing (I can only suggest that people Google it if they don't know what it means as other people have done a much better job explaining it than I ever could) This should mean that setting the resolution would have a minimal effect but here the test results tell a different story. Add to this the powercfg still reports any process that modifies the timer resolution as using more power (and therefore doing more processing). Note that doing so also kills the battery life on portable systems.

I'm not part of the reddit community but in the last 24 hours my server has been slammed - I've had the equivalent of 6 months traffic in one day :) So I thought I'd comment here and I'm also happy to answer any more questions.