The default timer resolution on Windows is 15.6 ms – a timer interrupt 64 times a second. When programs increase the timer frequency they increase power consumption and harm battery life. They also waste more compute power than I would ever have expected – they make your computer run slower! Because of these problems Microsoft has been telling developers to not increase the timer frequency for years.
So how come almost every time I notice that my timer frequency has been raised it’s been done by a Microsoft program (or Chrome), that is not doing anything to justify requesting a high-frequency timer?
This article was updated July 13, 2013, based on feedback from readers. See the bottom for the new material.
Update July 15, 2014. Google has locked the Chrome bug to further editing. The last comment from Google says that Chrome doesn’t always raise the timer resolution, and besides, other programs also raise it.
Update March 2015: Chrome now avoids raising the timer frequency unnecessarily, and as of summer 2020 Chrome will not raise the timer frequency above 125 Hz when on battery power, making it a non-issue for battery life.
Update June 2015: UIforETW, my handy tool for recording ETW traces for performance analysis, now records the current timer frequency to the traces, in addition to the batch file for extremely detailed recording and analysis of timer frequency changes.
Update October 2020: Microsoft has updated the Windows Kernel (Windows 10 and above) so that if one process raises the timer interrupt frequency it has less effect on other processes. This should reduce both the power and CPU wastage concerns, although it does not completely eliminate them. Details here.
Update November 2020: Microsoft’s tools for measuring and investigating the timer interrupt frequency (clockres and powercfg) are insufficient and clunky. Among other things they just sample the timer interrupt frequency at a point in time, when many programs adjust the timer interrupt frequency many times per second. To get a better report run trace_timer_intervals.bat – it summarizes all changes by all processes over the time period recorded.
Seeing the current timer frequency is easy – just run the clockres tool by sysinternals.
ClockRes v2.0 – View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals – http://www.sysinternals.comMaximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.000 ms
However this just gives you a snapshot, which is useless if Chrome or the Go runtime or other programs are constantly changing the timer interrupt frequency. This batch file gives a much better perspective over time.
Update: September 1, 2018. With the latest version of Windows 10 I see that clockres claims that the timer interrupt frequency goes up to 1 kHz when I unplug my laptop. TimerTool.exe says the same thing. ETW tracing and looking at the Microsoft-Windows-Kernel-Power provider shows that the OS itself is modifying the timer interrupt frequency (SystemTimeResolutionKernelChange events) about 30 times a second. I have been told that there are no power implications to kernel timer interrupt frequency changes, but even if that is true they make clockres and TimerTool useless. What a shame.
For maximum battery life the current timer interval (which can be changed with timeBeginPeriod, or NtSetTimerResolution) should be 15.6 ms. but as you can see above some program had set it to 1.0 ms. That means the timer interrupt is firing an extra 936 times per second, which should only be done if the benefits justify the costs.
Finding the culprit – WPF
Finding out who raised the timer frequency is non-obvious, but still fairly easy. Just open an administrator command prompt and run “powercfg -energy duration 5”. Part of the resulting HTML report will look like this:
The stack of modules responsible for the lowest platform timer setting in this process.
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 its use of WPF, requested a 1.0 ms timer interval, confusingly displayed as 10,000 with the units being 100 ns. This is a known problem with WPF. All versions of Visual Studio trigger this behavior sometimes, and presumably most WPF programs can also trigger it. While increasing the timer frequency might make sense for an application that is trying to maintain a steady frame rate it does not make sense for WPF to leave the timer frequency raised even when there is no animation going on (discussion on a WPF issue is here).
Finding the culprit – SQL Server
Another common culprit on my machine is sqlservr.exe. I think this was installed by Visual Studio but I’m not sure. I’m not sure if it is being used or not. Either way, SQL Server should not be raising the timer frequency. If doing so is needed to improve performance then that sounds like a design flaw. And, as with WPF, if raising the frequency is needed then it should only be done when SQL Server is busy, instead of leaving it permanently raised.
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 2384
Requesting Process Path \Device\HarddiskVolume1\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\sqlservr.exe
Finding the culprit – quartz.dll
I don’t have the powercfg output for it but C:\Windows\System32\quartz.dll is another cause of an increased timer frequency. I’m not even sure what Quartz is (Expression Web Designer?) but I know it is sometimes wasting energy.
Finding the culprit – Chrome
Microsoft is the usual culprit on my machine, but Google’s Chrome is also an offender. If I run Chrome then it instantly raises the timer frequency to 1,000 Hz, even when I’m on battery power and just displaying a raw HTML page.
To the right we can see Chrome displaying a harsh indictment of Chrome.
Finding the culprit – svchost.exe
Sometimes svchost.exe raises the timer frequency to 100 Hz. That’s nowhere near as bad as 1,000 Hz, but still annoying. It’s particularly frustrating because I can’t tell which service is doing it.
Alternate techniques to find the culprit
If you record an ETW trace with Microsoft-Windows-Kernel-Power provider (UIforETW does this by default) then the Generic Events table will contain events with Task Names like SystemTimeResolutionChange (user-mode timer resolution changes?) and SystemTimeResolutionKernelChange (kernel-mode timer resolution changes?) and you can see what value they set the timer interval to (in typical inscrutable units, in hex just to make them more friendly). zero means reset to default. Unfortunately the SystemTimeResolutionKernelChange seem to get set in the context of whatever process is running so the Process field is useless, but at least the SystemTimeResolutionChange events will tell you what processes are changing the timer frequency, recorded over the tracing interval.
Tragedy of the commons – highest frequency wins
The Windows timer interrupt is a global resource and it ticks at one rate for the entire system. That means that a single program that raises the timer frequency affects the behavior of the entire system.
When a process calls timeBeginPeriod this frequency request is in force until it is explicitly cancelled with timeEndPeriod or until the process terminates. Most programs (including my own test program below) never call timeEndPeriod, relying instead on Windows process cleanup. This works, and is reasonable for any application that needs the timer frequency high for its entire lifetime, but for any process whose lifetime may outlast its need for a high frequency timer, it’s time to start calling timeEndPeriod. As Microsoft recommends, this includes movie players that are paused, and games that are minimized. It also includes web browsers that do not currently need high-resolution timers, or are running on battery power.
(see Sleep Variation Investigated for what the timer frequency affects)
(note that as of Windows 11 and beyond one process no longer affects other processes as much)
Does it matter?
My main home computer is a laptop. I use it on the bus every day and I like to save my battery power for useful things rather than having it wasted on waking up the CPU 1,000 times a second.
Microsoft says that it matters. In this article they say “We are committed to continuously improving the energy efficiency of Windows PCs” and yet, four years later, they don’t seem to be following their own guidelines or heading their own warnings which say “Some applications reduce this to 1 ms, which reduces the battery run time on mobile systems by as much as 25 percent.”
One handy way of estimating the power cost is to use the Intel Power Gadget tool. On supported Intel processors this shows you the power drawn by the CPU package in real-time with a claimed precision of 0.01 W. Power Gadget is handy because it works equally well whether on battery power or plugged in. On my Windows 7 Sandybridge laptop it consistently shows a .3 W increase in power draw from having the timer frequency increased. That’s almost 10% of the idle CPU package power draw, although a lower percentage of total system power draw.
An increase of 0.3 W may not seem like much but there are a couple of reasons to take it seriously. One is that if your software is on average running on 33 million machines (a conservative bet for something like Chrome) then increasing the timer frequency could be wasting about ten MW of power. A check-in that fixes such a bug gives you enough carbon-offset-karma to last a lifetime.
Update: probably the reason why power consumption increased by 0.3 W was that I had several processes on my laptop that were spinning in Sleep(1) loops but had not called timeBeginPeriod. On older versions of Windows they would start doing more work (consuming more CPU time and more electricity) when some other process called timeBeginPeriod(1). On recent versions of Windows this is no longer true so the power consumption increase is probably reduced, and the power consumption increase was always highly sensitive to what other processes were running, but unfortunately I didn’t investigate this enough at the time.
Another reason to take this issue seriously is that I have been told that the importance of this issue is only increasing over time. With newer CPUs and with better timer coalescing the frenetic interrupts are likely to consume a greater percentage of total compute power.
Fast timers waste performance
Executing interrupts also uses some execution resources so having more interrupts per second should make your computer run a little bit slower. I tested this theory by writing a program that spins in a busy loop and reports every second on how quickly it’s getting work done. While this program was running I would change the timer resolution and see whether its throughput was affected.
It was affected. A lot.
I just did some quick tests on two machines, so the exact values shouldn’t be taken too seriously, and results will certainly vary depending on machine type, load, etc. But the results clearly indicate a performance cost to having high-frequency interrupts enabled. The overhead that I measured varied from 2.5% to 5%. That’s about an order of magnitude more than I expected. This level of slowdown is significant enough that it makes the common practice of raising the timer frequency in high-performance animation software seem counter-productive.
Raising the Windows timer frequency is bad. It wastes power and makes your computer slower. Routinely doing this in all sorts of programs that end up sitting idle for hours really needs to stop.
Here are some raw results:
4.03904e+006 iterations/s
4.08690e+006 iterations/s
4.09211e+006 iterations/s
4.09437e+006 iterations/s
4.05934e+006 iterations/s
4.00926e+006 iterations/s
4.07723e+006 iterations/s
4.10709e+006 iterations/s
4.02196e+006 iterations/s
4.10028e+006 iterations/s
4.10170e+006 iterations/s
4.10272e+006 iterations/s
4.10708e+006 iterations/s
4.10137e+006 iterations/s
3.95200e+006 iterations/s
3.90879e+006 iterations/s
3.92327e+006 iterations/s
3.91697e+006 iterations/s
3.92326e+006 iterations/s
3.91740e+006 iterations/s
3.92221e+006 iterations/s
3.91711e+006 iterations/s
3.91795e+006 iterations/s
3.92029e+006 iterations/s
3.92204e+006 iterations/s
3.92487e+006 iterations/s
3.91863e+006 iterations/s
3.92451e+006 iterations/s
3.92307e+006 iterations/s
3.92017e+006 iterations/s
3.91865e+006 iterations/s
3.91699e+006 iterations/s
3.92120e+006 iterations/s
3.90531e+006 iterations/s
3.98594e+006 iterations/s
4.10586e+006 iterations/s
4.10674e+006 iterations/s
4.11726e+006 iterations/s
4.11836e+006 iterations/s
4.11177e+006 iterations/s
4.10970e+006 iterations/s
The 20 second period in the middle where performance suddenly drops is exactly when the timer resolution increase happened, and I got similar results every time I tried. I tested this both on my laptop on battery power and my workstation on wall power and the results were always similar.
Source code
It’s not science without disclosing the source code, so my performance measuring program is available on github.
And my program that raises the timer frequency for 20 s is also available on github.
Don’t forget to check the system timer resolution using clockres before running the test. Make sure the timer interval is at least 10 ms before doing the test or else you won’t see dramatic changes.
And fix your code. Everybody.
Update, July 13, 2013
I’ve added some clarifications based on reader confusion, and some new information that I learned from reader comments. Enjoy.
Some of the cost of raising the timer interrupt frequency has gone away on Windows 10 and above, as discussed here.
Tickless kernels can change some of this – see this ArsTechnica article about Windows 8 and this article about the tickless Linux kernel explains some of the issues and challenges. Note that even with a tickless kernel a regular interrupt is still required so that timeGetTime will have its increased precision.
There are two reasons for raising the timer frequency. One is that it improves the resolution of Sleep(n) and of timeouts on WaitForSingleObject. For instance, some games have a power saving mode that throttles the game to 30 fps and this can only be done accurately if Sleep(1) returns in one millisecond, rather than 15-16 milliseconds. By enabling a lower frame rate without requiring busy waiting the higher timer frequency actually saves energy, in this case. For details on Sleep(n) and timer frequency read Sleep Variation Investigated. Multi-media playback often raises the timer frequency for variants of this reason, but these programs should reset the frequency when they are no longer animating.
Another reason for raising the timer frequency is so that timeGetTime will be more accurate. This is used, for instance, by SQL Server to more accurately measure query times. This behavior can be controlled using trace flag T8038, and is discussed more in KB931279. For details on the difference between timeGetTime and GetTickCount see timeGetTime versus GetTickCount.
The Chrome developers realized years ago that raising the timer frequency on battery power was a bad idea, as documented in Chrome: Cranking Up The Clock. However their mitigation of not raising the frequency when on battery power regressed. It should work now, and Chrome on battery power should not raise the timer interrupt frequency above 125 Hz (8 ms interval).
Using QueryPerformanceCounter gives even more accurate time results, but QPC has a history of being buggy. More timing discussions can be found here and here.
The Windows timer frequency is set to the highest frequency requested by a running program. Timer frequency requests can be cancelled by calling timeEndPeriod, but this is rarely done. Timer frequency requests are automatically cancelled when a process ends. If powercfg -energy duration 5 shows that a process has raised the timer frequency you can solve this by killing that process.
Preventing the timer frequency from being raised on your machine is simple. All you have to do is inject code into every process which shims timeBeginPeriod before it is called so that calls to it are a NOP. However, despite this being an obviously trivial task that could be put together in mere seconds, nobody has yet offered up anything more than code snippets and links to references.
Timer Queues were suggested as being a better timer mechanism, but the advantages of this better timer mechanism were not described.
An unexpected side effect of this article is that many developers said “Cool – now I know how to increase the timer frequency!” That makes me nervous, but as long as those developers raise the timer frequency for good reasons, and reset it with timeEndPeriod when they no longer need it, then all will be well.
Reddit discussion is here.
OSNews discussion is here.
A comment on some random forum suggested that this article was misguided because on a busy server the wasted energy is swamped by the energy used for real work. That is true, but that hardly makes my claims irrelevant: On a busy computer the issue is the wasted performance. On an idle laptop the issue is the wasted electricity. I continue to believe that (on Windows 7 and below at least) a raised timer frequency is harmful. And if you don’t believe my test results, feel free to generate your own.
Raising the timer frequency isn’t (despite everything I’ve said) universally bad. It can be necessary. Many games (including those that I work on) raise the timer frequency in order to allow high frame rates (100+ fps). Having a high timer frequency means we can call Sleep(1) while waiting for the next frame, which means that we save power compared to busy waiting for the next frame! My complaint is with programs that raise the timer frequency and then leave it raised for days at a time, even when the program is just sitting idle in the background. That is what bothers me.
Random ASCII - tech blog of Bruce Dawson 
mmm… I’m going to be a smart engineer and sell an app that periodically switches the timer back to a reasonable value and claim huge battery life savings!
Jokes aside, I remember a Windows developer detailing that Win XP was full of timeBeginPeriod(1) calls and they had to get rid them all for Vista and 7, since they found out major battery savings.
Too bad the MSVC team didn’t get the memo. That’s another strike for them. Lately I’ve been increasingly annoyed by the msvc team since VC 2010 for some design choices
As for SQL, it is needed by some msvc components, mostly MS 2010 Visual Web Developer and some optional C# components
A gem I just found about Chrome.
I was actually googling “force timeBeginPeriod system wide” (Windows is ignoring my requests to decrease the timer frequecy while Chrome is running because it asked a higher freq; and my timeEndPeriod(1) are being rejected because my process is not Chrome’s)
I don’t understand what’s their fuss about the QPC API, yes it’s really broken, but the AMD cpus do have a fix (I happen to own one of those buggy processors) and the problem goes away if the thread issuing the qpc is locked to a single processor.
Thanks for the link to the Chrome article. I have two complaints about it (are you listening Google?) One is it says that they only increase the timer frequency when on battery power, and on recent version of Chrome that is not true. That appears to be a regression.
Second, they should only raise the timer frequency when needed. If everybody does it all the time because everybody else is doing it then, well, chaos.
That said, it would be nice if Windows offered ways to wake up at a precise time without having to globally change the timer interrupt frequency. Tickless kernels (scheduling exactly the interrupts that you need) are one way of doing that.
The cost is real, and people pay the cost even when they are not reaping the benefits.
FYI, quartz.dll is a (the ?) major component of DirectShow. At least that one might has some business bumping the timer frequency. It’s most likely the renderer, which does need frame-accurate timings and needs accurate waitable timers or Sleep() in order to “play nice” and not spin.
Quartz (and Flash, and Chrome, and WPF) should only raise the frequency when needed. All of these systems seem to raise the frequency at startup and then leave it raised until process destruction. Sloppy. I think it’s time to rethink that behavior. A sure sign that Quartz and DirectShow are not appropriately balancing power consumption with their frame-accurate timing needs is that Visual Studio so often ends up raising the timer frequency because of these things — and Visual Studio is not a timing critical animation program.
I agree 100%. It’s criminal that in order to get accurate timers, one has to do this system-hogging 1ms timer “trick”. With as multimedia-centric as Microsoft is trying to be with Windows, you’d think they would have addressed this by now.
As to quartz.dll showing up under Visual Studio, I can only guess that VS is hosting some web page with Flash on it. When I ran your tests to check the timer resolution, I only ever saw quartz.dll show up while a DirectShow-using application was actively running.
Hello Bruce,
i’m a martin’s colleague and actualy i have a lot to do with windows timer. There are more potential issues with windows timer or with poor pc hardware and third party drivers. Just take a look at this paper “The Problems You’re Having May Not Be the Problems You Think You’re Having: Results from a Latency Study of Windows NT”
http://research.microsoft.com/apps/pubs/default.aspx?id=68734
Best regards!
Robert
Thanks for the link. The article looks interesting, but I’m not sure how carefully I should read it given that it a lot may have changed from 1999. I’ll read it, but they should update it so we know what still applies.
This article (Timer-Resolution.docx, from Microsoft) is also good:
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463266.aspx
It talks about Intelligent Timer Tick Distribution (ITTD) that avoids firing timer interrupts on all processors. That may explain one users report of a lower impact from high-resolution timers on Windows 8 compared to Windows 7.
Page two of this article talks about the Windows 8 tickless kernel:
http://arstechnica.com/information-technology/2012/10/better-on-the-inside-under-the-hood-of-windows-8/2/
Isn’t this what is reported in https://code.google.com/p/chromium/issues/detail?id=153139
Yep, that’s the bug. Reported seven months ago. I just added a comment and linked back to here. Vote on the bug if you want it fixed I guess. Thanks for posting the link.
Noticed your not calling timeEndPeriod at the end of your sample. The documentation doesn’t mention it, do you know if there is an assumed call to timeEndPeriod at process termination or have you just left the timer in limbo?
There is an assumed timeEndPeriod at process termination. Process cleanup is quite thorough and I count on that.
Unfortunately most users of timeBeginPeriod assume that but then leave their process running for days, even when the higher timer resolution isn’t needed. 😦
If timer resolution is a system-wide, global property, how would you know if you could safely reduce the resolution again without disrupting other processes that also need the higher resolution? Or better yet, how would you feel if Microsoft had decided to make all their programs reset the resolution to the default on process exit, when your program is relying on having the higher resolution?
I agree that something has to be done, i.e. the global timer resolution should be the maximum of all processes that requested a higher resolution, so when all programs that requested the higher resolution have exited, the resolution could fall back, and you could reset the resolution mid-execution without actually affecting it or other programs.
I believe that is the way it’s designed to work.
The call to timeBeginPeriod shows your desire to have the higher resolution. And the timeEndPeriod releases that desire. Not sure though if there is an implicit timeEndPeriod on process termination though.
You are describing exactly the current behavior. The global timer frequency is the maximum of all processes requesting a higher frequency. When processes exit their request is cancelled. I probably should have made that clearer in the post.
So then the problem remains that we don’t know why those applications require higher timer frequency. For quartz.dll it’s clear: a DirectShow graph needs a high precision master clock, and although it is usually provided by the audio renderer, that renderer itself samples usually at about 48 kHz, so even the higher precision contains much uncertainty. The questions is whether the high resolution needs to be turned while the graph is paused or not running at all.
It might be interesting to see how disrupting changing the timer frequency would be to an application. Maybe they stick with the higher frequency because accelerating and slowing down the frequency would cause problems in the application itself.
Unfortunately, .NET doesn’t call SetSystemTimeAdjustment directly, so I could not do a call trace on why it did that and if it has any methods that undo that change.
I think we know why WPF and DirectShow need (or think they need) a high timer frequency. However they clearly leave that high frequency enabled when they no longer need it. If it is important to not unnecessarily leave the timer running at high frequency (and Microsoft has said that it is, and my testing confirms that) then Microsoft should make the effort to lower the frequency when it is not strictly needed.
This is especially true when running on battery power. WPF and DirectShow should probably default to lowering the timer frequency when on battery power, and they should also cancel their high-frequency request whenever they are not currently using it, which on my machine in devenv.exe is most of the time.
It is plainly obvious to anyone looking at the static and non-animating Visual Studio process that it is often raising my timer frequency unnecessarily.
Just stop using Windows, and the problems are gone.
Well, these problems anyway…
Linux and OSX have their own challenges with timers, I’m just not qualified to speak authoritatively about them.
In Linux land we have our fair share of these issues already. The tool typically used for monitoring this is Powertop https://01.org/powertop/ .
There’s a way to find out which service is to be blamed. You can split service groups, so less services will be started in the same process. Then you have the processID to be blamed, and Process Explorer can show the service contents of each process.
At some point you mention games but I don’t get why a game would use the standard timer. They’re more likely to use the query performance one, which is counter-based rather than interrupt-based (and thereby much more power management friendly as it won’t take the CPU’s attention all the time). In fact, that timer is probably better for things like animations and such due to its better accuracy (I guess some non-game programs may still want to use standard timers so they don’t have something going on alongside the message loop, but even then 1000Hz seems overkill in that sense).
That said, I know the query performance timers did have bugs on some systems at some point (but that should be gone by now), so maybe that’s why some programs are resorting to the standard timers. There shouldn’t be much of a need for that anymore, though.
The main reason games would increase the timer frequency is so that they can get scheduled every ms instead of every 15.6 ms. For instance, when we want to frame-limit a game to, say, 300 fps we do that by calling Sleep(1) the necessary number of times, and that only works if the timer frequency is 1,000 Hz.
If we didn’t set the timer frequency to 1,000 Hz then we would have to busy wait, which would actually waste even more power. So, in that context the faster timer actually saves power.
Reblogged this on ITFRESH.
Until there is some other way to make Sleep(1), or really WaitForSingleObject(h, 1), actually only sleep for 1 ms (even with timeBeginPeriod(1) they sleep for closer to 1.98 ms on Win7+), I think you’ll just have to suck it up and buy a second battery. 1 millisecond is an eon in computing time… that the most responsive my program can be with a single thread in the case of timeout is 64 Hz, unless I make that call, is ridiculous. On a machine with /billions/ of hertz to go around.
I do agree that absent of high-level access to genuine timer facilities (whatever happened to HPET anyway?– should we be able to use that by now?), it’s silly that applications have to resort to global calls that affect the whole system.
As a developer I absolutely want to call timeBeginPeriod(1). As a consumer I don’t want anyone calling it. There is significant tension there. I hope Windows 8 has resolved this — it sounds like it may have.
Regarding Sleep(1), my tests show that on Windows 7+ it typically sleeps for no more than 1 ms. On Vista it had the annoying behavior of rounding up, and on Windows 7 it rounds down. I blogged about this in April:
I do agree with You, however there is absolutely no need to have any periodic interrupt at all to handle timings with as exact as possible accuracy. One just need to learn how to use the timer hardware right. This is what is done on microcontrollers at bare metal level.
I can’t stop being pissed off to see how my 8MHz microcontroller can act at tens of microseconds delays while my 3GHz 8 core PC can’t fit within 0,05[s].
It is true that is not “needed” to have a periodic interrupt, but it can be very beneficial. If you have a hundred processes that all want to wake up ten times a second then on average your CPU will wake up 1,000 times a second and you will get poor power efficiency. If all of the wakeups use a periodic timer then they will necessarily be coalesced. By default on Windows the CPU will wake up 64 times a second and power efficiency will be greatly improved.
I assume that there is also some overhead to programming the timer hardware for each interrupt, but I don’t really know anything about that.
So, power efficiency. That is the reason.
As for why microcontrollers behave differently I can only speculate but it might be that because they are simpler and slower they have a lower cost to wake from sleep, and therefore long naps are less important to them.
Raising the timer frequency to 1000Hz inside a VM (with VirtualBox at least) can also drastically increase idle CPU usage. Instead of the system hanging out close to 0% CPU usage, it can end up as high as 10-20% even when nothing’s going on. I got the author of one of my favorite pieces of software to stop calling timeBeginPeriod and it completely solved the issue when running that software in a VM.
TBH, one of the reasons people pick on windows for being ‘slow’, is the fact that the timer isn’t always at max rate, and it results in lower responsiveness.
Those 1ms time slices help make things feel ‘snappy’.
But this isn’t even salient, as high time resolution applications should make use of the HPET or RTC to achieve timeliness.
You can do this in Linux with timerfd() and read(), if you’re after a ~fixed schedule.
If you want simply accurate sleeps, the newer kernels already implement the usleep() function via HPET, falling back onto RTC, falling back onto soft clock.
In Windows, you have to write HPET or RTC specific code to use either one for timing or sleeping, and the built in Sleep() function is always a soft clock.
However, using the hardware interrupt timers, both Windows and Linux can give you resolution on the order of N microseconds – effectively eliminating any meaningful [scheduler] speed differences between either O.S..
[IIRC. I wrote this stuff a while ago and reuse the same code. Haven’t had to look at it in a while.]
Video drivers and compositing are a separate issue, but that will affect the perception of responsiveness when given a chance.
-scheherazade
Why, on God’s green earth, do they even have such a function available that will change the behavior of EVERY SINGLE THING? The function call that sets this absolutely should be hacked to a NOOP, and it should be completely forgotten about.
Reblogged this on .
Title should be: “Moronic game developers: Lots of Energy Wasted” I mean if you wanted to have a title which has something to do with the content….
Hmmm. I disagree. Some of our games increase the timer frequency so that we can clamp the frame rate to a maximum 30 fps without busy waiting. Thus, we use the increased timer resolution to *save* energy. Most game developers raise it and then run at as high a frame rate as they can, in which case the timer resolution is not relevant to energy consumption.
Chrome, WPF, and Quartz, on the other hand, leave the timer frequency raised when they aren’t using it. Aren’t they the wasteful ones?
It’s easy to figure out what is being run by svchost.exe because the request stack includes the process id. In the former SysInternals now Microsoft tool Process Explorer (procexp.exe), find the process id, then right-click, properties. The “command line” textbox will show the startup. In my case it was “C:\Windows\system32\svchost.exe -k netsvcs”. As best I can tell, all I have to do to reduce my timer is not run on a network. I wish I’d known sooner that that was all it took.
That technique only works reliably if you reconfigure svchost so that it puts one service in each process – by default it puts many in each process, and that is what makes attributing blame trickier. Note that you don’t need to use Process Explorer to see what services are running in each svchost instane — just use the Services tab in Task Manager.
netsvcs does not normally raise the timer frequency (or else everybody would be running at high frequency) so there must be something else going on.
When using Windows 8 and above, the native Task Manager already implements this feature (the “Processes” tab allows to expand “Service Host” and other service containers; similarly, the “Details” tab allows right-clicking an “svchost” and other service containers and select “Go to service(s)).
In the meantime, for Windows XP+, if one doesn’t have Process Explorer handy or simply prefers using command-line tools, simply type “tasklist /SVC”, which lists “Image name” together with “PID” and “Services” hosted.
Interesting article. I only began researching the system timer resolution calls because I heard a lower one would fix my Crysis 3 problems. After writing a tiny program to maximise the resolution (5ms on my system), the occasional stuttering I was experiencing has gone and I’m seeing a significant fps increase. I wasn’t expecting it to be so effective.
I figured I shouldn’t force it to 5ms all the time because it’s clearly making the CPU work harder… so I’m grateful having stumbled across all this info. Thanks. 🙂
Erm, I meant 0.5ms.
What was the timer resolution before? And what did the framerate change from/to?
If Crysis needs a higher timer resolution then they should be raising it. That’s fine. It’s only tragic when programs leave the resolution raised for long periods of time when they don’t need it, especially on battery power.
I’m talking to you Chrome.
Sorry, I only just noticed your reply.
Crysis 3 doesn’t touch the timer resolution. It stays at 15.625ms. In areas with lots of NPCs, particularly outdoors, the framerate would frequently dip below 30fps and there was occasional stuttering. After setting it to 0.500ms, the stuttering vanished and the frame rate never dropped below 45fps. I played the game through a second time and was amazed at the difference.
Fascinating. You might want to pass that information along to the Crytek team.
Crysis 2 in DX9 seems to be capped at 64 fps with the 15ms default timer. I think it is capped at 100 fps in DX11, as is Crysis 3. The caps disappear when timer resolution is lowered. Crysis 3 has serious CPU related performance issues without the timer alteration, it used to run better with chrome, and also origin itself must’ve alter the timer too! (don’t know whether it still does)
Is it a good idea to use 0.5ms timer with all games on a desktop computer? can it hurt? Crysis 2 and 3 are the only games I come across which had frame rate caps they shouldn’t have had. But the fact Crysis 3 had performance issues as well without it makes my head hurt. To make things more complicated, other games that use cryengine 3 didn’t even have the same issues, it’s strange…
Very strange. You’d think the developers would notice these issues and fix them.
I don’t think there is any harm in setting the timer to 0.5 ms when playing games. The worst-case cost is pretty minor, and clearly there is some upside.
Leaving the timer resolution lowered all the time will waste a bit of energy, but that is less critical on a desktop machine, especially in the winter.
Pingback: Bugs I Got Other Companies to Fix in 2013 | Random ASCII
Just for your interest: I’ve made a little tool which gets and sets the windows system timer, the code and download is here: https://github.com/tebjan/TimerTool
Cool! I assume that it can’t lower the frequency if another process has raised it, correct?
You might want to tweak the display. It looks like it says “Current: 1 min” (i.e.; current is one minute). Separate lines for Current/Min/Max would avoid that.
Right, you can only decrease the timer values. I’ve googled a bit, but there seems to be no was to overwrite the timer resolution if another process has set it.
But i have improved the GUI as you suggested and it can now also set 0.5 ms as timer resolution.
the tool was downloaded almost 4k times and no complains so far :). maybe you want to link it instead of the PS tools, or additionally? as its more convenient to use…
Thanks for the tool. I suddenly had need of it and it has been useful.
Do you know why Windows 8 would report 5003 as maxres when you try to set to 5000? Or 10007 when you try and set to 10000? This happens on mulitple laptops I have (Asus/HP) 4th gen i7/i5. However in windows 7 it sets fine to 5000/10000 respectively. In windows 8 Sleep(1) is timed at ~1.49998ms and in Windows 7 Sleep(1) ~.99997ms…this boggles my mind! Have you seen the same issue when using ntSetTimerResolution?
Sorry, I don’t know. I’ve never actually used ntSetTimerResolution. Maybe post a link to a project that shows the problem and see if anybody knows the answer?
Inspired by the flurry of “activity” (i.e. noise) on the Chrome bug thread today, I decided to have a look.
It seems Spotify does the same thing. Even when paused. And I’m not entirely sure it needs it at all (16ms is a little long, but it doesn’t strike me as a completely unreasonable amount to buffer).
Audio apps need to buffer dozens of ms to avoid dropouts because, 1ms timer or not, they may end up not being scheduled for a while. I emphatically agree that there is no reason for Spotify to be changing the timer precision. Playing background music needn’t harm your battery life. From a power draw perspective, the Zune software is the worst that I have measured.
When Valve found that Steam was accidentally raising the timer frequency the bug got fixed quickly. The change in power draw was quite measurable so a quick fix was obviously correct.
Just to let you know, Chrome now decided to fix this timer issue to improve power usage.
Pingback: Browser Chrome leert Notebook-Akkus | virtualfiles.net
Yeah, are trying to fix it. Chrome its a platform, not a plain app, so things on top of us can force our hand, most notably web pages. We have a few patches in flight, but after a few years at 1ms who knows what has grown to depend on that. This will take some time to be fully sorted out.
Regarding win8 tickless kernel, I have no empirical evidence of that. All my tests indicates it behaves the same, that is timeBeginPeriod causes everybody in the system to wake up faster. If somebody has user mode code that shows how win8 improves anything let me know on the chromium bug.
My understanding is that Windows 8 maintains the same behavior but does it in a more power efficient way. So, the cost of raising the timer frequency is apparently reduced on Windows 8. But I haven’t measured that myself.
It is impossible to comment on the chromium bug because it has been locked — a pity.
I hope that Chrome is able to fix this. I understand the concerns about being a platform. The problem would have been much easier to fix initially but now it is possible that web pages depend on it. But probably not, given the necessity of being portable to other browsers. So fix it.
Steam is also a platform. When Steam realized they had accidentally raised the timer frequency they fixed it promptly. No problem.
I also have been drawn in from the Google links today, and here’s what I’ve found:
I was hitting the 1ms resolution on every trace. Generally I found some background programs that always run but are not listed as startup programs, most egregiously the National Instruments software support suite that had timers which I’m sure are necessary for high-resolution measurement, but NOT WHEN THE PROGRAM ISN’T OPEN.
Firefox was giving me a 1ms resolution timer as well, just from the start page, but I didn’t check on my extensions.
iTunes was giving me 1ms. Last.FM was giving me 5ms, which is sad given that I only use it for scrobbling and never playing (and that was with iTunes turned off for that trace, so it should be completely idle…)
Seems like this is a pretty egregious problem in a number of programs.
Also, this was all running Windows 8.1, on a Sony S15 laptop in battery-saver mode on battery power.
In addition, I also found audiodg.exe (the standard windows audio driver?) increasing the resolution as well…
Once I finally forced closed all of these things and reran powercfg, the rate was finally back to the default.
It seems very odd that audiodg.exe would increase the timer resolution. That program runs on all Windows computers and I have never seen it doing that. Did you verify that with powercfg? If so, what was the call stack? Maybe there is an audiodg add-in that does it.
All of my traces were using powercfg, but I am betting it’s one of those add-ons that Sony includes on laptops… but at least none of their checkup software was doing it, so that gives some points at least. If I see it again, I’ll double check.
On one of my work machines (Windows 8.1) audiodg.exe is requesting a 1 KHz timer. The stack of requesting modules is shown below – no third-party code. So, any application that plays audio gets a 1 KHz timer? Seriously?
Platform Timer Resolution:Timer Request Stack
The stack of modules responsible for the lowest platform timer setting in this process.
Requested Period 10000
Requesting Process ID 12332
Requesting Process Path \Device\HarddiskVolume4\Windows\System32\audiodg.exe
Calling Module Stack \Device\HarddiskVolume4\Windows\System32\ntdll.dll
\Device\HarddiskVolume4\Windows\System32\AudioEng.dll
\Device\HarddiskVolume4\Windows\System32\audiodg.exe
\Device\HarddiskVolume4\Windows\System32\rpcrt4.dll
\Device\HarddiskVolume4\Windows\System32\combase.dll
\Device\HarddiskVolume4\Windows\System32\rpcrt4.dll
\Device\HarddiskVolume4\Windows\System32\ntdll.dll
\Device\HarddiskVolume4\Windows\System32\kernel32.dll
\Device\HarddiskVolume4\Windows\System32\ntdll.dll
I had the same issue on my PC – audiodg.exe was increasing timer resolution whenever something played audio (didn’t matter which process, and it was stuck with highest resolution until that process was terminated).
I learned that audiodg.exe is in fact some kind of host process for third-party code. It is meant for sound card drivers and other processes injecting code into the audio stack, including stuff like DRM.
I am using a Creative USB sound card (Sound Blaster x7) with Creatives own driver and noticed, that when I switch default output to another USB sound card which is just using the generic USB audio class driver from Microsoft, the problem with audiodg is gone.
So what I did now: I forced the Creative sound card to also using the MS generic USB audio driver. That was a bit tricky because Windows always prefers the device-specific driver and the Creative drivers are on Windows Update. I had to block driver updates for that device using group policies, otherwise Windows was always replacing the generic driver after a couple of seconds. And now… the problem is gone! I can play any audio now without increased platform timer resolution.
An update: seems like even Firefox will run at the lower timer now, right off the bat. As of Firefox 34.
Sloppy…
To clarify… what do you mean by the lower timer? The lower frequency (good) or the lower interval (bad)?
It seems like it is running at the lower interval, i.e. bad.
Hello Bruce. Thanks for the article. Recently someone sent us an email at the company linking here and claiming our code (well, a particular program in our software) to be “the culprit” when it comes to raising the frequency. Reported by the powercfg line you gave. This is the first time I come across this recommendation on MS’s part, btw.
Let me ask the obvious question: how does an unprivileged process affect the system-wide timer frequency? Excuse my ignorance, but shouldn’t in such a case the coalescing be more “aggressive” for unprivileged processes – introducing possible delays but not affecting system-wide behavior? I guess it’s easier to put the blame on developers, though.
But really: which functions will affect the frequency as a side-effect? I cannot see any user mode code calling any kernel function that might be able to affect it and I haven’t found a function that would lend itself as the _obvious_ culprit, is callable from user mode and is documented in the topic of “Windows Timers”.
So I set out to see what could be the reason. I checked for all kinds of timer-related functions. We use GetTickCount and SetTimer. SetTimer might seem obvious, but our requested intervals are 250 (249.6 == 16 x 15.6 ms, but a bit off) and 500 ms (499.2 == 32 x 15.6 ms). Not quite what you’d expect to influence the timer frequency at all. We don’t even use QueryPerformanceCounter or QueryPerformanceFrequency (and then their name and description suggest that they are read-only functions); nor do we use SetWaitableTimer(Ex). Oh yeah, and we don’t use the relatively new function SetCoalescableTimer either (although it seems like a remedy for the issue on newer systems).
The above cited values of 250 and 500 ms are the lowest used in any functions that are strictly related to “Windows Timers” as described on MSDN. None of them fits the bill as their values are close enough to 16 x 15.6 ms and 32 x 15.6 ms respectively and would therefore likely be coalesced. We don’t use the high frequency performance counters either.
However, I stumbled over the less obvious WaitForSingleObject with timeout values of 20 and 50 ms respectively in our code. Now _that_ makes sense, although it’s highly unexpected. While 3 x 15.6 ms is perhaps close enough to 50 ms with coalescing at 16 ms (1.2 ms off), I guess that 20 ms (4.0 ms off) results in the behavior described in this article? But are really the developers to blame for this? Why can MS not enforce a minimum timeout on waitable objects when called from unprivileged processes if this is so important? It does for SetTimer, doesn’t it (USER_TIMER_MINIMUM)? So why not for the wait functions?
While the discussion in Timer-Resolution.docx sheds some light on things, it leaves many open questions. All the described functions are kernel functions and as such not exactly the first reading when reading docs for a user mode program. Not the first time MS seems to have missed an opportunity of documenting stuff at the right place (i.e. where timers are documented).
I also checked for Sleep after reading some more of the comments. Some Boost code we use has a Sleep(1), but that Boost code isn’t used in the component that was blamed.
And I found one more instance of WaitForSingleObject at 1 ms. All other values could be coalesced as they would cause less than 1 ms of delay. Everybody knows Windows Timers to be not too acurate, so this is expected.
Also one correction: the .docx does mention user mode functions, but the document is made available on a page dedicated to driver developers.
Oliver, it is pretty much harmless to call Sleep(1) or WaitForSingleObject with a timeout of 1. That just tells the system to wake you up as soon as possible, but if the scheduler is running at its default frequency of every 15.6 ms then your wakeup will be delayed. All is good.
The function that can raise the timer frequency is called timeBeginPeriod. This lets you request a higher timer frequency. Yes, unprivileged processes can call this function and they can affect the behavior of all programs running on that machine. You’d have to ask Microsoft as to why this is allowed, but the basic problem is that some programs need to be woken up with finer granularity, and unless you have a tickless kernel the only way to do this is to raise the global timer frequency.
The powercfg line should give a full call stack to where in your process the timer frequency is being raised which should let you find the code that is doing it. Perhaps WPF? Or perhaps some library that you are using such as SDL?
Hi Bruce,
I’ll check again, but I didn’t see a call stack. I reckon it must be a library, but we aren’t using the function you says performs the change in our code. So I’ll have to dig deeper. I’ll get back to you when I have more information.
If you use “powercfg -energy -duration 5” and look at the resulting energy-report.html then it will show “The stack of modules responsible for the lowest platform timer setting in this process.” It’s not a full call stack, but it shows you calls timeBeginPeriod. If it is your module that does this then just set a breakpoint on that function and debug your process — it should be fairly easy.
Hi Bruce,
I cannot respond another time due to limitations of the nesting depth, it seems. Anyway, the reason I didn’t see it as a stack is because it pointed out but one item. In this case straight said program. Unfortunately the given piece of code is part of a library, namely the VLC (used in C++ Builder and Delphi). I’d have to see how to patch that behavior out. But it’s certainly possible.
I meant to write VCL, not VLC above.
Hi Bruce,
Not sure if im barkin up the wrong tree here. I found this site while troubleshooting GPo Screensaver not working properly on some machines. I came across this site: http://superuser.com/questions/387627/any-way-to-detect-what-is-disabling-the-screensaver
This pointed me to powercfg -energy trace. I got two specific event ID that stood out:
First Event ID 63: The application or service 0x0 is attempting to update the system timer resolution to a value of 0x0.
The details of this Evetn point to Internet Explorer as the process.
Then the Second Event ID 95 : The system timer resolution has changed to a value of 0x61A8.
They point to the System timer resolution, which somehow got me to you. I ran the powercfg -energy duration 5 and it gave me:
Platform Timer Resolution:Timer Request Stack
The stack of modules responsible for the lowest platform timer setting in this process.
Requested Period 10000
Requesting Process ID 1032
Requesting Process Path \Device\HarddiskVolume2\Windows\System32\svchost.exe
Calling Module Stack \Device\HarddiskVolume2\Windows\System32\ntdll.dll
\Device\HarddiskVolume2\Windows\System32\TSChannel.dll
\Device\HarddiskVolume2\Windows\System32\ntdll.dll
\Device\HarddiskVolume2\Windows\System32\TSChannel.dll
\Device\HarddiskVolume2\Windows\System32\svchost.exe
\Device\HarddiskVolume2\Windows\System32\sechost.dll
\Device\HarddiskVolume2\Windows\System32\kernel32.dll
\Device\HarddiskVolume2\Windows\System32\ntdll.dll
Im not sure how the svchost and IE are working together..
I guess im asking is can “system timer resolution has change” cause screensaver to never start?
Any help to direction would be appreciated.
Thanks
I am not aware of any correlation between the system timer frequency and screen savers. It seems unlikely that they would be related at all.
thanks I appreciate the response.. its driving me nuts..and I need to troubleshoot this remotely as to not draw attention..
I’ve been working with these timers since WindowsXP was released but yours is one of the better write-ups that I’ve seen.
The performance hit that you see in your test can be explained by the global nature of the timer resolution. Some of the early documentation from Microsoft detailed how changing this also had and impact on the scheduler and how the process quantums. In desktop versions of windows foreground tasks are given a boost by both dynamic task priority and also quanta. Not sure how this has evolved since Vista as I haven’t looked too closely. It also has an effect on system services.
The other reason is that there is a huge amount of code with sleeps, timers, WaitSingleObject etc with timeout values less than 15ms – it is common to see Sleep(1) or WaitSingleObject(…,10)
When you increase the resolution this code now starts running as programmed instead of at the 15ms interval. All these executable now start waking up more frequently and stealing your CPU cycles – which is why you also see and increase in power consumption.
The benefit as you described is if your application needs to do something periodically or you either need some responsive or pseudo-realtime behavior at the user space level modifying the timer resolution really becomes your easiest option to achieve this.
I developed a very simple tool years ago that I made available here http://www.lucashale.com/timer-resolution/
It has been downloaded well over 100,000 times and the more “advanced” paid version pays for my website hosting. It is clearly a popular topic that is not well understood by the vast majority of developers – based on the feedback I get, many applications that should be requesting high resolution timers are not and that is where my simple tool helps.
My assumption is that the reduced performance when the time frequency is increased is due to the overhead of the interrupts themselves rather than the user-mode code that runs. But, I did not do detailed profiling to measure where the additional cost is coming from.
Most applications can be designed to not require a raised timer frequency. As a laptop user who relies on long battery life I certainly prefer it when software doesn’t rely on a fast timer to run well. I wish Microsoft would give developers better ways of handling this.
Just ran a “powercfg /energy” on my system … interesting info.
Platform Timer Resolution:Platform Timer Resolution
The default platform timer resolution is 15.6ms (15625000ns) and should be used whenever the system is idle. If the timer resolution is increased, processor power management technologies may not be effective. The timer resolution may be increased due to multimedia playback or graphical animations.
Current Timer Resolution (100ns units) 10000
Maximum Timer Period (100ns units) 156250
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 6420
Requesting Process Path \Device\HarddiskVolume1\carbonpoker\client.exe
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 5856
Requesting Process Path \Device\HarddiskVolume4\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 6088
Requesting Process Path \Device\HarddiskVolume4\Program Files\Logitech Gaming Software\LCore.exe
… so Chrome and Opera in their latest revisions don’t seem to trigger it. I’m going to see if I can take Logitech, Carbon Poker, and Microsoft to task for their violations here, though.
If you look at the stacks then you’ll see that WPF is responsible for raising the timer frequency in Visual Studio. This is a long-standing problem that Microsoft seems to have no interest in correcting. I don’t understand why they ignore their own advice, in programs where the increased timer frequency has no benefit.
Good luck.
Since I have read this (very insightful) blog post, I tend to run ClockRes.exe to make sure some program is not setting the timer too low (1ms).
So I made this little program that shows the current resolution timer as an icon in the notification area.
Very useful when using a laptop!
Contributions are welcome.
https://github.com/florentchauveau/ClockResIcon
Cool idea. I’d recommend updating it more frequently however — perhaps once a second instead of every ten seconds? If the frequency hasn’t changed then no need to render anything, so the power cost should be inconsequential, and it would make it easier to correlate changes with what programs are doing.
Flashing the icon or making it bright red whenever the frequency changes would also be useful I think.
Awesome! Thanks for this. 🙂
You’re welcome 🙂
I’ve made the changes recommended by Bruce:
– it checks the frequency every second – very useful to detect app behavior,
– you can change the update to 10s or 30s,
– the color changes from black (15ms) to orange (10ms) to red (< 5ms).
Contributions are welcome 🙂
https://www.ethicalhacker.net/columns/heffner/intercepted-windows-hacking-via-dll-redirection
should not be too difficult to create stub winmm.dll and NOOP/disable TimeBeginPeriod and TimeEndPeriod calls from user space completely. Or add some reg key list to allow only specific .exe processes to set resolution.
It works. Using this :
http://www.codeproject.com/Articles/16541/Create-your-Proxy-DLLs-automatically
creates .cpp file ( has to be edited according to the tool specs before compilation ) to TimeBeginPeriod/TimeEndPeriod to simply “return 0” instead of making call into winmm.
1. Rename system32\winmm.dll into winmm1.dll ( when you create proxy, you specify “original-renamed” dll name.
2. copy created/compiled winmm.dll into system32.
3. reboot
Any application – Chrome/Firefox/VLC and so on, who will call winmm.dll, will NOT change TimerResolution.
NTSetTimerResolution still would work the same way, obviously.
Cheers.
Care to share it?
http://expirebox.com/download/7c5b5c3123f964054323a13a81fd92c9.html
rename originial to winmm1.dll
probably best way to do in recovery cmd.
What about sharing the source?
http://www.codeproject.com/Articles/16541/Create-your-Proxy-DLLs-automatically
WRAPPIT
it will create source for you. rtfm. if you can’t walk through instructions – get binary.
// timeBeginPeriod
//extern “C” __declspec(naked) void __stdcall __E__144__()
// {
// __asm
// {
// jmp p[144*4];
// }
// }
extern “C” int __stdcall __E__144__(UINT uPeriod)
{
return 0;
}
do this in the generated source, before compilation.
Wow this looks perfect, however your original download is now 404, can anyone compile this for me?
The Go language runtime also raises the Windows timer frequency to 1 KHz. This was reported last year and there is no sign that it will be fixed. This means that if your system has any program written in Go running on it then the timer frequency will be raised.
I encountered this when, after closing all programs on my work machine, the timer frequency according to clockres was still 1 KHz. I eventually traced it to a *service* written in Go that my IT department had installed, thus ensuring that my timer would *always* be running at 1 KHz.
It is clearly unacceptable to have a language that always raises the system timer frequency.
https://github.com/golang/go/issues/8687
Hi Bruce! Your post was a great guide to better understand Windows power consumption and get better battery life from my laptop!
Since I’ve just installed Windows 10, I’ve noticed it sets a 1 ms timer resolution when playing media (both with MediaFoundation and DirectShow); both in my laptop (Realtek HD Audio drivers) and in a VM (VMware, MS HD audio drivers).
Hopefully during future updates this should be fixed; it appears to be an issue in the audio stack (I guess) – Energy Report does not pin it to a particular application, but a kernel driver.
Windows 10 still has some maturing to do regarding power consumption; it can get to Windows 8.1 levels, but media playing is definitely an issue.
I’ll watch for that. Thanks for the heads up.
(I found this thread by googling for my issue.) I’ve seen this issue as well. In my case, the 1 ms resolution gets set when 1) Skype starts at boot (strangely not if I start it later), and 2) if the computer (a Surface Pro 3) is charging and then is unplugged WHILE it’s hibernating.
What is strange that I can “reset” the clock resolution back to 15.625 by just playing some media. Exiting the app (like Groove, Plex or Netflix) sets the clock back to 15.625.
So yeah, I too think Windows 10 has some issues with battery drain related to the clock resolution. I’ll keep an eye on it.
Noone cares about your stupid megawats.
Noone want play game with 15.6ms resolution, i am using timer resolutioner and have 0.488ms 😛
Noone will use crappy 15.6ms, like eco modes and similar crap, stop cry dude LOL.
Your argument is compelling. However you might better understand the importance of energy efficiency once you move out of your parent’s basement and have to pay the power bill yourself. Or, you might care about battery life once you can afford your own laptop.
By the way, “Noone” is two words, and “megawats” has two ‘t’s.
As well, 16ms is enough to fire that timer every frame of a 60fps video game. I really can’t think of any reason whatsoever that most consumer programs of any kind need to bump this.
It turns out that for video games it is often necessary to run the timers at a higher speed. Either you need to be entirely driven by the refresh (letting your Present calls throttle your frame rate) or you need to fire off a few delayed tasks. Those delayed tasks may need to complete within the frame which means they need sub-16 ms resolution.
It should be possible to manage without those sub-frame delayed tasks, but most games rely on them. And, raising the timer frequency while playing games is not going to harm battery life — it’s already toast because of the game. It’s raising the timer frequency when the system is *idle* that is wasteful. That’s what I was really railing against.
I suppose that could be. Looks like a major effect of this, though, is that it also increases the frequency with which Windows task scheduler switches tasks, which could be pretty harmful, too.
LAL you live in past.
60 fps ROFL 😀
Today times we use 144hz monitors, which means 6.9ms resolution.
And still timer 0.488 matters, i can notice big difference between 0.488 and 0.988.
I am starcraft 2 master and i need fluid game.
60 fps and 15.6ms resolution is unplayable for me.
Brucedawson are you gramar nazi or wut ?
English is not my nature language and i have more important things to do, than learn grammar.
Btw this make you glad pals to hear, otherwise i have disabled all c states, so my cpu and gpu runs all time on 100%.
Still tdp is very low, for example gpu, when doesn’t do anything 27% only.
I have Geforce780.
So you don’t rage to much guys, i tell you, i have psu with 90% efficiency 620w.
It might make you calmer.
You have a GF780, but are a starcraft 2 master and need a fluid game? Yeah. You’re just a troll.
Hi Bruce,
Thank you for your brilliant article. Recently I’ve faced some problems with timers that I thought
maybe you can address me to solve them.
I’m coding in windows XP with delphi7 and I’m using timers in my code to run a stepper motor via PCI board.
Whenever a multimedia software or SQL runs in parallel with my application. The stepper motor steps faster and sometimes irregular. Thanks to your article I found out that they are changing the timer frequency, but how can I make my timer safe from these changes?
Just raise the frequency yourself, that way nobody else can raise it further. Make sure your Sleep/Wait calls are for the appropriate length of time and you should be fine. Well, as fine as you can be since Windows is not a real-time OS.
Thank you for your help. I followed you and the result for each combination is:
1- Without timeBeginPeriod(1), with delphi(VCL) timer, and no running media: stepper motor runs fine.
2- Without timeBeginPeriod(1), with delphi(VCL) timer, and running media: stepper motor runs with different precision.
3- Without timeBeginPeriod(1), with directX timer, and no running media: stepper motor runs fine.
4- Without timeBeginPeriod(1), with directX timer, and running media: stepper motor runs very fast.
5- With timeBeginPeriod(1), with delphi(VCL) timer, and no running media: stepper motor runs same as case 2.
6- With timeBeginPeriod(1), with delphi(VCL) timer, and running media: stepper motor runs same as case 2.
7- With timeBeginPeriod(1), with directX timer, and no running media: stepper motor runs fine.
8- With timeBeginPeriod(1), with directX timer, and running media: stepper motor runs same as case 4.
Sorry for being too lengthy, why cases for directX timer are so strange?
I’m sorry, There is the corrected result:
The effect of raising the frequency on the VCL timer is just changing the precision, while on directX timer it changes the speed!
I’m not sure what the delphi(VCL) and DirectX timers are. Knowing what directX timer API is behaving differently, and knowing what function is used to implemented the delphi(VCL) timer might be helpful.
The ideal situation would be an isolated repro that is just a few hundred lines of C++ code, although that can be a hassle to create.
Thanks for all the info and links in this article. I am having an issue on a server with two Xeon E5-2648L V3 processors. I am loosing data very rarely when my driver DPC has a latency issue of nearly the duration of a timer tick of 15 msec (Server 2008 R2). When my ISR schedules the DPC, almost always, the DPC happens within a millisecond. But sometimes it takes several milliseconds. I used TimerTool to set the windows Timer to 1 millisecond and my problem seems to have gone away. Note that I have a firmware FIFO on my capture board that holds only 5 millisecond of data that is continually streaming into server RAM, so if my DPC latency is more than about 4 milliseconds, I lose data because setup of the next DMA chunk is delayed.
I am trying to understand why the data loss happens and why the Timer change fixes it. In an older server with a different Xeon processor, I did not see this. Could this be a problem on the processor?
That sounds odd. If a thread is signaled then it should start running immediately, if there is a CPU available. Waiting until a timer tick should only happen for wait timeouts and for sleep.
DPCs in particular should be scheduled immediately, so that’s very weird. Sorry – no ideas.
maybe good on a laptop to save power , on a workstation or gaming pc though i would always set the timer to 0.5 because your system just runs faster with more power , this is easily measurable in dpc latency, framerates, the interrupts go up 1% cpu but thats it .. the realtime performance and snappiness of the system becomes much better with lower timer resolution and modern hardware ( intel + nvidia ) doeesn´t eat much energy anyways …
well, the Forums are full with people having Microstutters, when Playing CS GO or Dota 2 on Windows 10, even with constant 140fps and more. Reducing the timer to 1ms or 0.5ms solved for many of them the Issue. Win 7 had not this kind of Problem though.
If a game is coded such that it requires a high timer frequency then the game should raise the timer frequency. If CS:GO and Dota 2 fail to do this and they need it then that is a bug in those games. If I still worked there I would fix it, but I quit several years ago.
Hi Bruce! Thanks for this post. I learned a lot.
However I’d like to mention that Chrome (latest x64 version on Windows 10) still sets the timer interval down to 1.000 ms (from clockres) as soon as a page is displayed (no video, webgl or anything fancy) and never resets it (maybe it’s a custom setting?). Edge for example behaves differently: a small test showed that it sets the timer to 0.500 ms (so lower than Chrome) when a video is shown but reverts back to the default 15.625 ms once the video is off.
The 0.5 ms that Edge sets is actually from the Windows 10 audio subsystem. This is a Windows 10 design defect, in my opinion, which I hope they fix. Among other things it makes it difficult to tell what timer resolution the running applications have actually requested.
Chrome should not be setting the timer to 1.0 ms all the time, but on pages that request constant animation callbacks or constant timer callbacks it does. We’re working on improving this, but it would also help if web pages didn’t ask to be woken up dozens of times per second.
I’m just doing a simple test w/o audio involved. 1) Clockres reports 15.625ms. 2) I run a blank Chrome (latest v62, Windows 10), clockres still 15.625ms. 3) I navigate to chrome://version/ (or basically to almost any page with “something” in it, including http://www.google.com, or when I click on the upper right “Google Application”s icon) clockres is now 1.0ms. Edge does not seem to exhibit this behavior, even on its “news” start page.
Thanks for the report. That certainly sounds serious, however I cannot reproduce it. I went to chrome://version and google.com and the timer resolution stayed at 15.625 ms. I wonder if you have some extension or ??? that could be causing this.
“powercfg /energy /duration 5” records a power trace that might give more information, but it is likely that it will just say that it is Chrome without saying why. However this would at least indicate which chrome process was requesting the higher timer frequency, and maybe that can be attributed to a particular extension.
An ETW trace might also help (UIforETW should have appropriate defaults). Or it might not. Unfortunately these problems can be difficult to understand, especially when they only happen on some machines.
Ok, what I did is disabled all extensions and re-enabled it one by one, check clock. Now, it doesn’t behave the same as 5 minutes ago with all extensions back… Now when I start chrome and go to http://www.google.com, clocks stays at 15.625. But as soon as I type something in the adress bar, clock is set to 1.0. I also tested this with private navigation where no extension is active. In this mode, I start with no page, but if I navigate to http://www.google.com, clock is set to 1.0. This doesn’t make sense. Tweaking config forth and back changed behaviour. Sorry, I don’t want to bother you, I was just trying to understand
Chrome has a habit of raising the timer frequency when it needs to which is based on some complex heuristics regarding how many tasks are due and when. And, this fluctuates frequently. This makes clockres an insufficient choice for monitoring this because it will miss lots of fluctuations. You might want to try TimerTool as it repeatedly polls the timer frequency and displays it:
https://vvvv.org/contribution/windows-system-timer-tool
With that running I found that Chrome was occasionally raising the timer frequency, very briefly. If I went to the omnibox/address-bar and held down a key then the auto-repeat would cause the timer frequency to be continuously raised, due to the processing and rendering of the keystrokes. This doesn’t seem to serious and I don’t think that is what you are seeing. Maybe you just have bad luck and you happened to run clockres in the brief times when the timer frequency was raised.
An ETW trace can show you exactly when the timer frequency is changed, but I’m not sure if it matters enough to justify that.
Hey BruceDawson nice to meet you this topic is clearly amazing, and i was wondering how can I increase the timer resolution of a Game? it seems that my Windows 10 for a strange reason is putting my timer resolution to 0.5 ms in games such Counter Strike 1.6, and when doing the tracert:
Powercfg -energy duration 5
It says:
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 5796
Requesting Process Path \Device\HarddiskVolume4\Program Files (x86)\Steam\steamapps\common\Half-Life\hl.exe
How can i stop that from going to 0.5 while it clearly use 100ns 1.0 ms
I guess this is the culprit of my poor performance or un-sync even at 100 fps, on my Ryzen cpu 5 1600 😦
This is the file of energy-report that i upload to mediafire in case you can help me a little be, i’m really facing this issue since 2010 and i think every day i’m a step forward by diagnosing the problem, hope you can help me thanks bro!
fileÑ
https://www.mediafire.com/file/2k6d2sekdi7ml5b/energy-report.html
Windows 10, right? Playing audio, yes? Well, guess what, the Windows 10 audio subsystem sets the timer interrupt interval to 0.5 ms on most laptops. Yay! No worries that this violates their own guidelines.
I doubt this is the cause of poor performance, but it might be wasting power, or at least obscuring apps that are wasting power.
Bad Microsoft.
Oh i see but i’m running a desktop PC with
Ryzen cpu 5 1600 3.2
EVGA GTX 1060
Windows 10 pro 64 1607 anniversary
But yeah on chrome it doesn’t changes it reminds 15ms and i can changes chrome to 0.5 ms, but games like cs 1.6 are forced to 0.5ms and contact Steam support, but i’m waiting for their answer
So is there no way to force Applications or by-pass the Subsystem 0.5ms on audio games? Thanks so much
If you don’t want the timer resolution set to 0.5 ms when audio is playing then you will need to talk to Microsoft – it’s their design flaw. Maybe Fall Creators Update will improve this but I don’t know. I would recommend not worrying about it, especially on a desktop PC, since there isn’t anything you can do about it.
“A check-in that fixes such a bug gives you enough carbon-offset-karma to last a lifetime.”
Its not carbon, C. You meant to say CO2.
And as there is a tiny amount 0,04% co2 in the total atmosphere of which 0,0012% is from human activity.
I agree with the wasted energy issue, but co2 is not anyone’s problem, its plant food.
Yes, CO2 is the problematic gas, not C. However the phrase “carbon offsets” is more commonly used, is shorter, and is totally reasonable because one C atom released almost inevitably becomes CO2.
Your figure of 0.04% is ambiguous because it isn’t clear whether it refers to mass or particle count. That’s why scientists usually use the less ambiguous ppm (parts-per-million) nomenclature. 0.04% is equivalent to 400 ppm (today’s measurement at Maunua Kea is 403.84 ppm) so I assume that is what you meant, so 0.04% CO2 is correct.
However 0.0012%, or 12 ppm, is wrong.You are off by an order of magnitude. It is 0.012% or 120 ppm. That is, since the start of the industrial revolution CO2 levels have gone from about 280 ppm to about 400 ppm. This is settled science.
I think you are suggesting that a “tiny amount” of 400 ppm couldn’t possibly be significant. That idea is irrational. Many trace elements are vital and significant. Arsenic or plutonium in the body, for instance. And, a ~43% increase in the greenhouse gas CO2 changes how our planet retains heat, and is already having effects. I would love to see a world-wide carbon tax to encourage all people to at least *try* to be efficient.
“its plant food.” -> “it’s plant food” – it’s is a contraction for “it is”.
I found that with latest windows 10 1803 clock resolution says that after a restart is 0,500 ms but if i truck with windows power cfg it says 15,625ms
I have also a picture there:
-http://tinypic.com/r/2vb0ina/9
clockres detects either kernel or non-kernel timer interrupts. powercfg only detects non-kernel timer interrupts. If you record an ETW trace and know how to analyze it then you can see both, as well as how frequently they are changing.
In short, it is a known problem that clockres and powercfg contradict each other. I have been told that the powercfg information is more indicative of power efficiency, but ???
This mean that after a pc restart when the clock resolution tool always says 0.500 ms is meaning that it reads the kernel timer interrupts wrongly or that the kernel interrupts stuck in 0.500 ms resolution?
As i understand and i saw that you wrote an Update: September 1, 2018 it means that kernel interrupts change so quickly that the tool cant calculate them?
Timer frequency changes in general can change too frequently for clockres to display accurately. In addition to that the kernel timer settings may not be relevant. So, everything is broken and we should probably ignore the timer frequency until Microsoft fixes things and updates their guidance. Sorry!
thanks you for your time!
Basically i write it there. After a lot of time and reading i fixed the windows clock resolution that stuck on 0.500 ms.
The culprit is this uefi option:
Boot performance mode from turbo to max-non turbo performance.
Hi! Thank you for writing this very informative article! I found out about these problems with platform timer resolution when I looked at the package C state usage of my CPU using ThrottleStop. All the time I had an application running in the background that was using Chromium or WPF, I noticed the percentage of the CPU spending in lowest C7 state was decreasing significantly (from ~95% to 86%). Then I checked powercfg /energy to find out this is purely connected to the current platform timer resolution (actual CPU usage of these background apps ~0%, they are idling!). Thus, the estimated package power consumption which ThrottleStop is showing increases from ~1.1W to ~1.5W, just due to lower C state usage because the timer resolution is increased far beyond it’s default values.
I reported this issue to the developers of these programs, all of them recognized the problem and some of them even released an update fixing it! But of course they can only fix it, when they are responsible for the timeBeginPeriod call by themselves. Unfortunately one of the programs which I absolutely need to run in the background all the time is relying on wpfgfx_v0400.dll, which seems to be changing the timer resolution.
So I think what is needed would be some kind of blacklist on the system side, where you can add single processes that are excluded from changing platform time resolution, either by itself or by any dependency. So you could look up powercfg /energy to find the culprit, try to put it on that list and check if it’s still working as intended, and if it’s fine keep it. But I think we will never get something like that
Good job on your investigations and on reporting the problems. I like your idea of having a system blacklist, but I agree that it will probably never happen.
I recently reported a problem with wpfgfx_v0400.dll being used by a Visual Studio 2019 component – Microsoft suggested that they would probably fix it, probably by not having VS 2019 loading that component.
I like the blacklist idea, or failing that they should adopt how linux and freebsd works, both those operating systems do it the proper way, and they make timer resolution system admin controlled, no single application can control it which is how it should be, they configured on boot via a variable and then it is static.
On my own system, I get coil whine when c-states are enabled due to the rapid switching of c-states, I then noticed the whine is gone in safe mode and linux. I looked into a bit more and found out that all of the following are forcing my system to 1000hz timer.
Chrome (they only fixed this when battery detected, not desktop).
Audiodg sound card driver.
Steam
Telegram – I have no idea why a text chat app is forcing this value.
Default windows value is 15ms resolution, I consider anything down to about 3ms or 4ms reasonable.
I hired a dev to try and fix it with a dll to overide the behaviour to block any app from hijacking the value, but he gave up.
I’m making some progress on fixing Chrome, which may fix some Electron apps as well. A soon-to-land change will add a switch to make Chrome on AC act like Chrome on DC.
That said, if you get coil whine from c-state or timer changes then you might want to fix your hardware – that shouldn’t happen.
I agree there is hardware issue with the coil whine but fixing it means replacing it and hence expensive, also 1000hz is simply not efficient. For multimedia that uses 30 or 60fps then 300hz is an optimum value (3.33ms).
Fixing just chrome doesnt really fix everything because “any” application can increase the timer, and applications that do is also include steam and telegram. But of course a chrome fix is welcomed. Chrome if you have any influence should just set to 300hz on desktop instead of 1000hz, the timer boundaries match up with 60fps and shouldnt cause any stutters. Also chrome only needs to do this when a video overlay is open, right now on my system it sets 1000hz just by opening a blank page.
I consider the proper solution to preventing winmm.dll from allowing userland applications from controlling the value, alongside with 300hz been a default value so 30 and 60fps applications work.
Someone on freelancer did decompile winmm.dll for me, and presented a modded winmm.cpp, he didnt do exactly as I asked, but I can sort of see where he was going and its progress, but he seems to have given up, as most people seem to want to work on .net instead of cpp.
Finally manufacturers typically dont accept coil whine as a fault, its not ideal, but they dont consider it a fault. I did confirm coil whine only happens at 1ms or below. 2ms or higher silences it completely. At 0.5ms its about double the noise.
Also higher resolution can actually decrease performance, as the cpu has to interrupt whats doing every timer interval. These software developers setting 1000hz are doing so without understanding what they doing, which is one reason why that setting should be locked to system admin control only.
It’s odd that the interrupt frequency would affect coil whine, since there are so many other parts of the system running at far higher frequencies. The only noise I ever hear from my computers is fan noise. But, I’m not an EE type.
I agree with pretty much everything you say. Fixing Chrome must be done carefully because so many websites depend on it, but I’ll do my best. And working on Chrome is my day job now (it wasn’t when I wrote the original post).
Changing the behavior of winmm.dll is something I’m going to leave to Microsoft – but I don’t think they will change it.
I understand, I look forward to the result of your work 🙂 If I ever do finish up on winmm.dll modifications I will post my result here.
This is now implemented in Microsoft Edge (the chromium version), go to the edge flags config screen, and right near the bottom is an option to reduce the timer resolution for devices under battery, but it can be forced enabled on desktops using this option. So it seems Microsoft disagree with Google, and decided to implement this in the browser at least, its a shame though there is still no OS side to control this stuff.
I believe the underlying setting that Edge lets you control was added to Chromium by my team at Google.
The just-landed change below suggests the direction Chrome is moving in:
https://chromium-review.googlesource.com/c/chromium/src/+/2145761
You can use chrome://flags or –enable-features=SlowDCTimerInterruptsWin (M81 and above) to opt-in to this experiment. You can use –disable-highres-timer to opt-in to the behavior when on AC. With those two settings Chrome never lowers the timer interrupt interval below 8 ms.
Note that chrome://flags and these command-line options should be used for experimental purposes only.
Thanks I have applied and will let you know how I get on.
Were these flags recently removed from Chromium? I’m using the latest Edge (Chromium) dev build (88.x) and noticed that I am back to 1ms platform timer. The SlowDCTimerInterruptsWin is no longer present and the –disable-highres-timer parameter does not change anything, not even reducing the timer resolution to 4ms which I think was the former behavior when on AC (before the 8ms experiment started).
Did the decreased timer resolution turn out to cause problems? Or were the flags and launch options removed in order to prepare rolling it out as default behavior?
I just checked on my machine and –disable-highres-timer works. Probably some other program is raising the timer interrupt frequency. Try using trace_timer_intervals.bat to find the culprit (clockres and powercfg are insufficient). It could also be non-Chrome code within Chrome, such as D3D in some cases.
DirectSound defaults to 10 ms resolution.
Many thanks for the discussion here! It contains the same considerations that I already had. I was extremely annoyed that the Dropbox app keeps the timer permanently at 1 ms. So I don’t use this app anymore. Corresponding requests and comments in the Dropbox forums are also ignored.
A solution with a modified winmm.dll, which can be controlled via a blacklist and denies access to timeBeginPeriod for certain programs, would be really perfect! But Microsoft will probably never implement something like that.
Hey Volker, I’m not so sure Microsoft won’t be willing/able to fix it.
The compatibility shims are one way Microsoft has been known to fix misbehaving applications. One such example are applications that don’t know of (because they’re old) or don’t care about (when they’re new) “cloud files” (not just OneDrive, any of the various providers). This means (in Microsoft jargon) that files/folders get hydrated (partially or fully, i.e. from filling in the metadata on the local client for just the folder to the files and eventually the file contents). Hydrating files is of course wasteful and so shims exist to counter that behavior.
Which makes me wonder if it wouldn’t be possible even for a third-party to implement something like that (haven’t investigated in-depth, but it seems doable). Even if not possible to implement this as a third-party I imagine Microsoft would be willing to listen to users (via its Feedback Hub) and implement such a shim (or shims).
Just saying that there is already a mechanism which doesn’t outright affect everything and so could be well-dosed in scenarios where it matters. Of course wasted megawatts are an issue everywhere, but on a server probably less so than on a laptop.
Microsoft definitely could put in mitigations to stop apps from leaving the timer frequency raised forever. They have done many compatibility shims in the past. However, if they haven’t done it yet I’m not sure that they ever will.
Pity.
I don’t think that a third-party solution would be practical, but I’m happy to be proven wrong. My main concern would be that any third-party modification or shimming of winmm.dll would be indistinguishable from malware.
Yes, it really is dreary. After two years now, nothing has changed in the dilemma. I just tested the Dropbox app again and found that it still keeps the timer endlessly at 1 ms. Even when it does NOTHING at all! I’m not surprised, since Dropbox is an Amazon product and Amazon is anything but known for sustainable business and the protection of the environment.
thank so considerably for your web site it helps a whole lot.
From the documentation:
Starting with Windows 11, if a window-owning process becomes fully occluded, minimized, or otherwise invisible or inaudible to the end user, Windows does not guarantee a higher resolution than the default system resolution. See SetProcessInformation for more information on this behavior.
https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
Huh. Good find. I’ll have to ponder the implications of that. Maybe Visual Studio will finally stop leaving the timer raised all the time on my machines.
These are Good news for Windows users: lots of applications, including most WPF-based and audio/video require this feature sometimes for brief periods but then “abuse” by not disabling such high accuracy timers. Should enable a battery lifetime boost and apparently a reason to upgrade by itself. Thanks for sharing! 😉
The bad thing is that not only tasks that need this high resolution request them, but also tasks that don’t need it at all. Such as the Dropbox synchronization app. This keeps the system permanently at 1 ms, even if it does nothing at all. This behavior is completely unacceptable. Although this misconduct has been reported to the manufacturer endlessly in the last years, the manufacturer has not responded to this day.
Thank you for this, it’s very informative and really helpful!
I found this article today, in 2022 when there’s a wide spread fear of rolling blackouts throughout Europe and I want to do my smallest bit to conserve electricity so that we don’t have to start cutting power here in Finland as well.
This is really eye opening… this needs to be more widely known and it should be almost MANDATED that apps can’t unnecessarily use high resolution timers if they don’t need them.
This wastes EASILY several megawatts, if not gigawatt of power throughout the world.
This is really something.
The good news is that recent changes in Windows have probably reduced the impact of applications that carelessly raise the interrupt frequency. See this blog post for details:
I would like to point out that you can now control Timer Resolution globally and per application too + you can prevent an application messing with Timer Resolution or prevent from raising it or even keep it at 15.6ms all the time.
It is open sourced and completely free. You can use it on Windhawk.
Windhawk link – https://windhawk.net/
Mod that you can use on Windhawk or even download it directly from Winhawk – https://github.com/m417z/my-windhawk-mods/blob/main/mods/timer-resolution-control.wh.cpp
https://windhawk.net/mods/timer-resolution-control
Thank you so so so much for such great and useful information!