Why you should not overclock the timer Windows or megawatts wasted

The default Windows timer period is 15.6 ms - it ticks 64 times per second. When the program increases the frequency of the timer, energy consumption increases, which affects battery consumption. It also consumes the computing power of the computer, and even more than I thought - that is, the computer starts to work slower! That is why for many years Microsoft has strongly discouraged developers from raising the timer frequency.
Why, then, almost every time I see the overclocking of a timer, is it caused by a program from Microsoft?

Finding out the current Windows timer frequency is quite simple using the clockres utility from sysinternals.

ClockRes v2.0 - View the system clock resolution
Copyright 2009 Mark Russinovich
SysInternals - www.sysinternals.com

Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms
')
To increase the battery life of the computer, the current period of the timer (which can be changed by the timeBeginPeriod function) should be 15.6 ms; but, as you can see above, some program changed it to 1 ms, which is equivalent to an additional 936 ticks per second.

Guilty Looking - WPF

The process of finding the culprit in increasing the frequency is not so obvious, but still quite simple. In the admin command line, type

powercfg -energy duration 5

and the energy-report.html file will appear in the current directory, in which we, in particular, will read:

This is the case.
Requested Period 10000
Requesting Process ID 3932
Requesting Process Path
C: \ Program Files (x86) \ Microsoft Visual Studio 11.0 \ Common7 \ IDE \ devenv.exe
Calling Module Stack
C: \ Windows \ SysWOW64 \ ntdll.dll
C: \ Windows \ SysWOW64 \ winmm.dll
C: \ Windows \ Microsoft .NET \ Framework \ v4.0.30319 \ WPF \ wpfgfx_v0400.dll
C: \ Windows \ SysWOW64 \ kernel32.dll
C: \ Windows \ SysWOW64 \ ntdll.dll

So, Visual Studio 11, through the use of WPF , requested an interval of 1 ms, which is indicated in the report by means of a somewhat confusing unit of measurement equal to 100 ns. This is a known WPF issue ; All versions of Visual Studio behave this way from time to time and, apparently, any application using WPF can be a source of problems. Increasing the frequency may make sense when the program tries to maintain a constant frame rate output, but this does not justify WPF, because it keeps the timer high frequency even if no animation occurs.

Finding culprit - SQL Server

Another process often guilty of increasing the frequency on my computer is sqlservr.exe. I think that it was installed by Visual Studio, but I’m not sure about it, as I’m not sure if it is being used or not. In any case, the SQL server should not increase the frequency of the timer; if it is thus intended to improve the performance of the application, then it is more like a crutch. And, as in the case of WPF, increasing the frequency is needed only when the server is busy processing data, and not constantly.

Platform Timer Resolution: Outstanding Timer Request
A program timer or service has been requested.
Requested Period 10000
Requesting Process ID 2384
Requesting Process Path \ Device \ HarddiskVolume1 \ Program Files \ Microsoft SQL Server \ MSSQL10.MSSQLSERVER \ MSSQL \ Binn \ sqlservr.exe

Search guilty - quartz.dll

I do not have a corresponding entry from the powercfg report, but C: \ Windows \ System32 \ quartz.dll is another source of problems with the frequency of the timer. I don’t even really know what this Quarts is (well, we know that this is nothing but Microsoft DirectShow - note of the translator ), but I noticed that sometimes it spends energy in vain.

Find Guilty - Chrome

Microsoft products are usually the culprit, but I’m adding Google Chrome to them. When I launch Chrome, it constantly increases the timer frequency of 1000 Hz, even when the computer is running on battery, and I look at a simple HTML page. I bring a screenshot fixing the crime of Chrome.

Search guilty - svchost.exe

Sometimes svchost.exe increases the frequency of the timer to 100 Hz. This, of course, is not as scary as 1000 Hz, but still annoying. It is especially sad that I cannot determine what kind of service it does.

General tragedy - the maximum frequency wins

Windows timer is a global resource, it ticks with the same frequency for the entire system. It turns out that if some program increases the frequency of the timer, then this affects the behavior of the entire system.
When a process calls the timeBeginPeriod function, this frequency request remains in effect until it is forcibly canceled using timeEndPeriod or until the end of the application. Most programs (including my test programs below) never call timeEndPeriod, relying on Windows system cleaning tools. This works and is quite reasonable for applications that need an increased timer frequency throughout the execution. Otherwise, a good idea would be to use timeEndPeriod. As recommended by Microsoft, video players in pause mode and games minimized are included in the second type of applications. You can also enable web browsers that currently do not require a high frequency timer or when running on battery power.

Is this important?

My main computer is a laptop. Every day I use it on the bus and prefer to spend the battery on something useful, rather than on unnecessary calls to the processor 1000 times per second.
Microsoft believes this is important. They say : “our position remains a consistent improvement in the energy efficiency of Windows PCs” and yet, even 4 years later, they themselves do not seem to follow their own instructions and do not pay attention to their warnings: “some applications reduce the timer period to 1 ms , which leads to a reduction in the operating time of the mobile system by 25%. "
A convenient way to measure energy consumption is the Intel Power Gadget utility. On supported Intel processors, it will show the power consumed by the processor packaging in real time with an accuracy of 0.01 watts. On my laptop on the Sandy Bridge platform, the utility shows an increase of 0.3 W with an increase in the timer frequency, which is almost 10% of the standard consumption of the processor package; for the entire system, the percentage will of course be less.
An increase of 0.3 watts may not look so big, but there are a couple of moments that make you take it seriously. Firstly, if your program runs, say, on 33 million computers (for Chrome, this is probably even a low estimate), increasing the timer frequency will result in a loss of about 10 megawatts of energy. Secondly, the importance of the problem over time will only increase. New processors with an improved combined timer will spend on more frequent calls even more computing power.

Fast timers degrade performance

Execution of interruptions takes up some of the computer resources, so an increase in their number per unit of time should slow down its speed somewhat. I tested this theory by writing a test program, twisting activity cycles and reporting the speed of my performance every second. While the program was running, I changed the frequency of the timer to see its effect on performance.
The impact was substantial.
I did quick tests on two computers, so the exact numbers should not be taken too seriously. In addition, they probably strongly depend on the hardware platform, load, etc. However, the results clearly showed the effect of the acceleration of the timer on performance, it is 2.5-5% - this is more than I expected. The degree of slowing down is large enough to suspect the traditional approach — increasing the frequency of the timer to increase application performance — of counter-productivity.
Increasing the frequency of the Windows timer does not lead to anything good. At the same time, energy is wasted and the computer slows down. The practice of using it in all indiscriminately programs hanging for hours without activity should be discontinued.
Here are the results of my test program in graphic format.



The 20-second period in the middle, where performance drops unexpectedly, coincides with an increase in the timer frequency. I got similar results in all my tests, both with battery power and mains

Source

Since science is not done without disclosing the source code, I cite the code of my test program.

#include “stdafx.h” #include <stdio.h> #include <Windows.h> LARGE_INTEGER g_frequency; const double kDelayTime = 1.0; double GetTime() { LARGE_INTEGER counter; QueryPerformanceCounter(&counter); return counter.QuadPart / double(g_frequency.QuadPart); } int g_array[1024]; int offset; int g_sum; void SpinABit() { for (int i = 0; i < ARRAYSIZE(g_array); ++i) { g_sum += g_array[i + offset]; } } void Stall() { double start = GetTime(); int iterations = 0; for (;;) { ++iterations; SpinABit(); double elapsed = GetTime() – start; if (elapsed >= kDelayTime) { printf(“%1.5e iterations/s\n”, iterations / elapsed); return; } } } int main(int argc, char* argv[]) { QueryPerformanceFrequency(&g_frequency); for (;;) Stall(); return 0; } 

But the program increases the frequency of the timer for 20 seconds.

 #include <stdio.h> #include <Windows.h> #pragma comment(lib, “winmm.lib”) int main(int argc, char* argv[]) { timeBeginPeriod(1); printf(“Frequency raised.\n”); Sleep(20000); printf(“Frequency lowered.\n”); // timeEndPeriod call is omitted because process // cleanup will do that. return 0; } 

Do not forget to check the frequency of the system timer before running the test, otherwise you may not see the difference.

And then correct the code of your programs. All as one.