# Timer frequency fun

**URL:** <https://discourse.libsdl.org/t/timer-frequency-fun/19730>\
**Category:** SDL Development\
**Created:** [July 10, 2013, 11:00am UTC](https://discourse.libsdl.org/t/timer-frequency-fun/19730 "2013-07-10T11:00:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vittorio\_Giovara](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/v/57b2e6/32.png) [@Vittorio\_Giovara](https://discourse.libsdl.org/u/Vittorio_Giovara)\
**Post date:** [July 10, 2013, 11:00am UTC](https://discourse.libsdl.org/t/timer-frequency-fun/19730/1 "2013-07-10T11:00:45Z")

</div>

So I was on IRC and got this interesting link

> **[Windows Timer Resolution: Megawatts Wasted](https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/)**
>
> 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…

In a nutshell it warns the developers that setting windows system timer to  
a low resolution and then leave it like that even when the application  
doesn’t need it harms performance and battery life. Apparently, osx and  
linux are not affected by this problem.

So I took a glance at the windows timers in SDL just for fun and noticed a  
few things:

- it’s possible to use GetTickCount by setting USE\_GETTICKCOUNT, but as its  
resolution is too low (10-16ms) it is disabled
- by default, the high resolution timer is in use
- only when the high resolution timer is not available (when? it’s not  
clear to me) then the the timeBeginPeriod() is set.

However this affects the Sleep behaviour (in SDL\_Delay) as  
[http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspxreport:](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspxreport:)  
when timeBeginPeriod is not set Sleep may last 15.6 ms more or less.  
So I prepped this patch that uses WaitForObject() on the current thread,  
which according to the docs  
[http://msdn.microsoft.com/en-us/library/ms687036(v=vs.85).aspx](http://msdn.microsoft.com/en-us/library/ms687036%28v=vs.85%29.aspx) should  
not suffer from precision skew.

I’m not sure how this affects existing behaviour of games and tests out  
there so testing and review would be welcome.

Vittorio  
-------------- next part --------------  
A non-text attachment was scrubbed…  
Name: sdldelay.patch  
Type: application/octet-stream  
Size: 656 bytes  
Desc: not available  
URL: [http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130710/06ac103c/attachment.obj](http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130710/06ac103c/attachment.obj)

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [July 10, 2013, 5:56pm UTC](https://discourse.libsdl.org/t/timer-frequency-fun/19730/2 "2013-07-10T17:56:57Z")

</div>

> From Bruce Dawson:

WaitForSingleObjectEx is affected by the timer precision so switching from  
Sleep(n) to WaitForSingleObjectEx(n) will not help things. At the default  
timer precision of 15.6 ms the scheduler only runs every 15.6 ms, so no  
timeouts can be serviced at higher than that resolution.\*\*\*\*

* * *

When a process readies another process (SetEvent, ReleaseSemaphore, etc.)  
then the scheduler is invoked for that, but timeouts are not processed  
until the timer interrupt.\*\*\*\*

* * *

As I recommend in my blog post, be sure to put in a paired call to  
timeEndPeriod() when you don?t need the higher resolution.—

What I’ll probably do is put the timeBeginPeriod() back in, with a hint so  
applications that don’t need that resolution can specify a lower resolution  
to save power.

Thanks!

On Wed, Jul 10, 2013 at 4:00 AM, Vittorio Giovara \< vittorio.giovara at [gmail.com](http://gmail.com)\> wrote:

> So I was on IRC and got this interesting link
> 
> [Windows Timer Resolution: Megawatts Wasted | Random ASCII – tech blog of Bruce Dawson](https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/)
> 
> In a nutshell it warns the developers that setting windows system timer to  
> a low resolution and then leave it like that even when the application  
> doesn’t need it harms performance and battery life. Apparently, osx and  
> linux are not affected by this problem.
> 
> So I took a glance at the windows timers in SDL just for fun and noticed a  
> few things:
> 
> - it’s possible to use GetTickCount by setting USE\_GETTICKCOUNT, but as  
> its resolution is too low (10-16ms) it is disabled
> - by default, the high resolution timer is in use
> - only when the high resolution timer is not available (when? it’s not  
> clear to me) then the the timeBeginPeriod() is set.
> 
> However this affects the Sleep behaviour (in SDL\_Delay) as  
> [Microsoft Learn: Build skills that open doors in your career](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspxreport:) when timeBeginPeriod is not set Sleep may last 15.6 ms more or less.  
> So I prepped this patch that uses WaitForObject() on the current thread,  
> which according to the docs  
> [WaitForSingleObjectEx function (synchapi.h) - Win32 apps | Microsoft Learn](http://msdn.microsoft.com/en-us/library/ms687036%28v=vs.85%29.aspx) should  
> not suffer from precision skew.
> 
> I’m not sure how this affects existing behaviour of games and tests out  
> there so testing and review would be welcome.
> 
> Vittorio
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

---

<div class="post-metadata">

**Author:** ![Sik\_the\_hedgehog](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/db5fbb/32.png) [@Sik\_the\_hedgehog](https://discourse.libsdl.org/u/Sik_the_hedgehog)\
**Post date:** [July 10, 2013, 6:51pm UTC](https://discourse.libsdl.org/t/timer-frequency-fun/19730/3 "2013-07-10T18:51:08Z")

</div>

Sleep is not very predictable anyway, it really wasn’t meant to be  
used for small amounts of time. The only reason it specifies time in  
milliseconds is probably to provide an easy way to specify non-integer  
amounts of seconds (e.g. pass 500 to delay half a second).

One thing to take into account is that if I understand correctly the  
QueryPerformance timers should _not_ be affected by this, since they  
work in a completely different way (they’re counter based rather than  
interrupt driven). When you just want to query the elapsed time, this  
should be probably the best option in this sense (and as a bonus you  
get extra accuracy!). The big downside is that they can’t be used for  
idle delays (e.g. what SDL\_Delay would do), since you have to poll  
constantly and thereby it ends up being a busy loop.

Correct me if I’m wrong, but only the standard timer (i.e. the one  
used in window messages and GetTickCount) should be affected.

---

<div class="post-metadata">

**Author:** ![Vittorio\_Giovara](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/v/57b2e6/32.png) [@Vittorio\_Giovara](https://discourse.libsdl.org/u/Vittorio_Giovara)\
**Post date:** [July 10, 2013, 9:41pm UTC](https://discourse.libsdl.org/t/timer-frequency-fun/19730/4 "2013-07-10T21:41:47Z")

</div>

> From Bruce Dawson:
> 
> WaitForSingleObjectEx is affected by the timer precision so switching from  
> Sleep(n) to WaitForSingleObjectEx(n) will not help things. At the default  
> timer precision of 15.6 ms the scheduler only runs every 15.6 ms, so no  
> timeouts can be serviced at higher than that resolution.

Ack, sorry for the wrong patch, re-reading documentation for  
WaitForSingleObjectEx mentions that too.

> * * *
> 
> What I’ll probably do is put the timeBeginPeriod() back in, with a hint so  
> applications that don’t need that resolution can specify a lower resolution  
> to save power.
> 
> That’s great, but do you think there could be some hooks to reset the  
> timer too? For example when the game is paused there is no need to leave  
> the high precision on.

> Thanks!

Thank you for doublecheking ^^  
VittorioOn Wed, Jul 10, 2013 at 7:56 PM, Sam Lantinga wrote:

---

<div class="post-metadata">

**Author:** ![Vittorio\_Giovara](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/v/57b2e6/32.png) [@Vittorio\_Giovara](https://discourse.libsdl.org/u/Vittorio_Giovara)\
**Post date:** [July 11, 2013, 6:43pm UTC](https://discourse.libsdl.org/t/timer-frequency-fun/19730/5 "2013-07-11T18:43:11Z")

</div>

Also would it make sense to have something like

timeBeginPeriod(1);  
Sleep(ms);  
timeEndPeriod(1);

In this way the high precision timer would be on only for the duration of  
the Sleep.  
I tried to see if this made sense but I found no useful info…

VittorioOn Wed, Jul 10, 2013 at 7:56 PM, Sam Lantinga wrote:

> From Bruce Dawson:
> 
> WaitForSingleObjectEx is affected by the timer precision so switching from  
> Sleep(n) to WaitForSingleObjectEx(n) will not help things. At the default  
> timer precision of 15.6 ms the scheduler only runs every 15.6 ms, so no  
> timeouts can be serviced at higher than that resolution.\*\*\*\*
> 
> * * *
> 
> When a process readies another process (SetEvent, ReleaseSemaphore, etc.)  
> then the scheduler is invoked for that, but timeouts are not processed  
> until the timer interrupt.\*\*\*\*
> 
> * * *
> 
> As I recommend in my blog post, be sure to put in a paired call to  
> timeEndPeriod() when you don?t need the higher resolution.
> 
> * * *
> 
> What I’ll probably do is put the timeBeginPeriod() back in, with a hint so  
> applications that don’t need that resolution can specify a lower resolution  
> to save power.
> 
> Thanks!
> 
> On Wed, Jul 10, 2013 at 4:00 AM, Vittorio Giovara \< @Vittorio\_Giovara\> wrote:
> 
> > So I was on IRC and got this interesting link
> > 
> > [Windows Timer Resolution: Megawatts Wasted | Random ASCII – tech blog of Bruce Dawson](https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/)
> > 
> > In a nutshell it warns the developers that setting windows system timer  
> > to a low resolution and then leave it like that even when the application  
> > doesn’t need it harms performance and battery life. Apparently, osx and  
> > linux are not affected by this problem.
> > 
> > So I took a glance at the windows timers in SDL just for fun and noticed  
> > a few things:
> > 
> > - it’s possible to use GetTickCount by setting USE\_GETTICKCOUNT, but as  
> > its resolution is too low (10-16ms) it is disabled
> > - by default, the high resolution timer is in use
> > - only when the high resolution timer is not available (when? it’s not  
> > clear to me) then the the timeBeginPeriod() is set.
> > 
> > However this affects the Sleep behaviour (in SDL\_Delay) as  
> > [Microsoft Learn: Build skills that open doors in your career](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298%28v=vs.85%29.aspxreport:) when timeBeginPeriod is not set Sleep may last 15.6 ms more or less.  
> > So I prepped this patch that uses WaitForObject() on the current thread,  
> > which according to the docs  
> > [Microsoft Learn: Build skills that open doors in your career](http://msdn.microsoft.com/en-us/library/ms687036%28v=vs.85%29.aspxshould) not suffer from precision skew.
> > 
> > I’m not sure how this affects existing behaviour of games and tests out  
> > there so testing and review would be welcome.
> > 
> > Vittorio
> > 
> > * * *
> > 
> > SDL mailing list  
> > SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> > [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)
> 
> * * *
> 
> SDL mailing list  
> SDL at [lists.libsdl.org](http://lists.libsdl.org)  
> [http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org](http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)