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
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
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,
this problem surfaced I optimized the code as best I could, through several
figuring that improving the efficiency of the code would resolve the problem.
iteration of code improvement the controller was quite fast and I was convinced
fixed things. Then later the speed would again drop to a snail's pace. I was
the web and running various other applications throughout this process.
It turns out that the default windows timer, on which the sleep function
not function as one might think. The function parameter () is used to set the
in increments of 1 msec, down to a minimum of 1 msec [e.g. sleep(1)]. But in
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
timer to 'high resolution' using the Windows Multimedia function timeBeginPeriod()
the resolution is specified in milliseconds, with a minumum of 1 msec. When you
longer need the high resolution timer, you then revert to the default timer by
timeEndPeriod() and specifying the same resolution.
What happened to me is that when I entered the Delphi IDE it set the timer to
resolution and so my program ran quickly. When I closed the IDE the default
returned to standard resolution, so things slowed down. But at times other
applications I was running [and some of the webpages I was surfing] were
timer resolution to high resolution, and thus affecting my program's speed, and
think that I had 'fixed' the problem. Then going to another webpage or changing
of applications that was open would reset the timer to its original
Although some documents suggest that the timeBeginPeriod and timeEndPeriod
application-specific, they are NOT so, and affect the performance of other
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
resolution of the windows timer, I would suggest that you explicitly set the
resolution using timeBeginPeriod() before you use the sleep function [or any
function that depends on the default windows timer], and then reset it to
termination using timeEndPeriod().
There is a nice free, downloadable application that lets you see what your
windows timer is doing at:
There is a nice story of how surfing the Yahoo Finance page can appear to
computer's performance by this mechanism at:
You don't need to download the application from the Yahoo Finance story page to
this out; just use the SkedGran application from the first URL I gave and check
default timer result, then open the Yahoo Finance page, recheck it, and then
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
Copyright © 1997-2007 COPYRIGHT Roger Rehr W3SZ. All Rights Reserved
Brought to you by the folks at W3SZ