So Windows on all modern variants, allows userland applications to reduce the "windows timer resolution".
The default timer resolution in windows is 15.6ms.
A good value for multimedia is probably 3.33ms which fits the boundaries of both 30fps and 60fps media.
The downside of a lower value is it is less energy efficient, and also more wasteful, e.g. context switch overheads skyrocket on lower timer resolution.
A problem that has happened is software developers have created a habit of pushing this to an aggressive value of 1ms. Once a "single" application does this, it affects the OS system wide.
Examples of software that does this.
Steam - the application itself would not benefit at all, its likely been done to benefit games launched from steam, as some people report it can remove stutter from games.
Telegram - no idea why its doing it.
Chrome - According to chrome developers, it prevents stutter on 60fps video content, on laptops after a lot of complaints, they made it less aggressive to a 2.5ms resolution, which was an odd choice indicating they dont understand what they doing.
None of these applications allow control of what they doing on timer resolution, they simply hard code the behaviour.
A chrome developer is working on it to be improved for desktop, but he hasnt told me what he is specifically doing. Of course that only affects chrome.
To me a proper fix is to do one of these two changes.
1 - Prevent any userland application able to adjust this value. This would probably not be without problems unless manually increasing the value via admin intervention, as the default timer resolution has been known to cause stutters in multimedia.
2 - Allow userland applications to increase the resolution, but add a blacklist registry key e.g. to blacklist chrome.exe.
To achieve this I want to proxy winmm.dll (where the call is been made), but it seems the process is to decompile winmm.dll (someone done this for me), amend the behaviour of 'timeBeginPeriod' call to ignore userland input, and then recompile winmm.dll.
Asking for assistance from modern developers has been an eye opener as many now see cpp/c as some kind of ancient dead language and seem to be only interested in .net language. The one's who have showed any kind of interest are mostly responding with things like "why do you want to do it", I respond with thats my problem to worry about not yours, and then I get met with silence. One developer made a program to generate whats known as proxy dll's many years ago. If I understand right a proxy dll, is something that would not replace the system dll but can be used to just override behaviour for specific functions (What I want), but I am not at the skill set required to use his application, I asked him for assistance, and was told his old program is considered abandoned/obsolete for various reasons, he asked me why I want it, I told him, then he responded with a proposed solution which of course was not a solution but was easier for him as it involved no cpp work.
This then reminded me of discussions I had seen around windows 10, as there has been discussions on reddit as to why Microsoft are reinventing the wheel (making an entire new UI). There is theories one of course been the UI is been redone to be touch friendly, that is "a" reason. But someone who works at Microsoft currently decided to respond, and he pointed out that almost the entire Windows team at Microsoft now no longer fully understands the original win32 code and its considered a "legacy" mess. Which is a big reason why things like the control panel are been phased out and replaced by the settings applet, and why the black theme added to windows 10 is such a mess. This phasing out started back when Windows 7 started been developed with feature removal after feature removal. Remember Microsoft actually wanted to remove win32 desktop, and go entirely to "metro" interface at one point, this was all related to that.
For the curious I have two motivations to fix the windows resolution timer.
My motherboard gets coil whine when C1E or higher cstates are enabled "and" when a timer resolution of 2ms or lower is used. At 2ms its very slightly audible over other noise, at 1ms, its annoying, at 0.5ms it can be heard through the door. At 3ms its inaudible. Coil whine is not typically considered a fault by hardware manufacturers. My workaround since getting this hardware is most of the time to only use C1 state when idle. There is still a very small amount of coil whine present under C1, but its not bad enough to be annoying, you basically have to specifically listen for it. Regardless of C state used tho, there is also coil whlne present when using either on board ethernet port on my board, and again goes away at 2ms or higher.
The overhead of context switches under load can be very significant. As 1ms is a very aggressive timer, in the days of older cpu's FreeBSD used to default to a 100hz timer (10ms) for this reason. But now they default to 1000ms (1ms) as they have took a sledgehammer approach like chrome and co. Although with FreeBSD one can simply adjust the timer in the kernel settings and no userland application can override it so not really a big deal. So some example data, note also that context switch load also increases with core sharing of single threaded workloads. There is one game I play where the userland load on the cpu core is about 30%, the context switch load is 50%, so the overheads are higher then the normal cpu load for the userland code itself. A timer resolution of 3.33ms would reduced that overhead by more than two thirds, so would be about 15% or there abouts. So the game would need about 45% cpu utilisation instead of about 80%, better than buying a new processor. AMD and Intel probably love this fact as no doubt context switch waste helps sell more processors. Windows task manager does "not" show kernel loads by default in cpu utilisation graphs.
In the attached pic, note how much of the overall cpu usage is used by the darker shade of colour (kernel load, most of it is context switches). What you seeing in that graph is the high userland cpu load on core 4, this load has a high context switch overhead which in itself has been spread over all 6 cores. The overall load of that userland process excluding context switches is 13%, system load including kernel load is 28% (variances around those figures of course). When the application is not running system is idling at around 3-4% (chrome in background). So 4% background load (mostly on chrome and system interrupts), 13% for the game, 11% context switch overheads (very high due to windows timer resolution).
For android and linux the default is 250hz which is 4ms. Dont know about apple OS.
