The Windows Timing Issues Page

This is a brief note regarding a windows timing issue that bit me when
I wrote the WSE control program for windows.  I am hoping my posting it will save someone
from hours wasted.
 

In the WSE control program I wrote, it was necessary for me to insert a 'sleep'
statement after I wrote each bit to the printer, or the printer commands
would not properly control the WSE units.  Sleep(1) was sufficient for this purpose.

When I ran the WSE controller in the Delphi IDE the speed of my Up/Down-arrow
routine for setting frequency was good and I could move from one end of
the band to the other in a second or two.

But when running the executable file directly from Windows XP64,
sometimes the speed was great and other times it was 10-20 times
slower!  There seemed to be no rhyme or reason to this, and it was not
CPU-use-related, as the CPU use was on the order of 5% or less.

My first WSE controller code had been just a quick hack to get things working, so after
this problem surfaced I optimized the code as best I could, through several iterations,
figuring that improving the efficiency of the code would resolve the problem.  After each
iteration of code improvement the controller was quite fast and I was convinced I had
fixed things.  Then later the speed would again drop to a snail's pace.  I was surfing
the web and running various other applications throughout this process.

It turns out that the default windows timer, on which the sleep function depends, does
not function as one might think.  The function parameter () is used to set the sleep time
in increments of 1 msec, down to a minimum of 1 msec [e.g. sleep(1)].  But in its default
state, the timer interval/resolution actually doesn't go below 15 ms.  If you set it to
any number between 1 and 15 it will be [approximately] 15 msec.  But you can set the
timer to 'high resolution' using the Windows Multimedia function timeBeginPeriod() where
the resolution is specified in milliseconds, with a minumum of 1 msec.  When you no
longer need the high resolution timer, you then revert to the default timer by using
timeEndPeriod() and specifying the same resolution.

What happened to me is that when I entered the Delphi IDE it set the timer to high
resolution and so my program ran quickly.  When I closed the IDE the default timer was
returned to standard resolution, so things slowed down.  But at times other other
applications I was running [and some of the webpages I was surfing] were resetting the
timer resolution to high resolution, and thus affecting my program's speed, and making me
think that I had 'fixed' the problem.  Then going to another webpage or changing the mix
of applications that was open would reset the timer to its original low-resolution state!
 Although some documents suggest that the timeBeginPeriod and timeEndPeriod functions are
application-specific, they are NOT so, and affect the performance of other applications
that are running under Windows at the same time, as my experience showed.

If you are using a sleep command in windows or another function that depends on the
resolution of the windows timer, I would suggest that you explicitly set the timer
resolution using timeBeginPeriod() before you use the sleep function [or any other
function that depends on the default windows timer], and then reset it to default at
termination using timeEndPeriod().

There is a nice free, downloadable application that lets you see what your default
windows timer is doing at:
http://www.grahamwideman.com/gw/tech/dataacq/skedgran/skedgran.htm

There is a nice story of how surfing the Yahoo Finance page can appear to improve your
computer's performance by this mechanism at:
http://www.codeproject.com/tips/YahooSpeeds.asp

You don't need to download the application from the Yahoo Finance story page to check
this out; just use the SkedGran application from the first URL I gave and check the
default timer result, then open the Yahoo Finance page, recheck it, and then close the
Yahoo page and check it again.

My love for Windows continues to grow...NOT!
Here are some Webpages on Windows Timing issues that I found helpful:
Precision Timing Under Windows Operating Systems
Inside Windows NT High Resolution Timers
timeBeginPeriod
timeEndPeriod
Timer Resolution

Brought to you by the folks at W3SZ