Timer not being time-true

[DianePDavies]

I have a form that requeries data every 20 seconds based on a timer event.

When doing that I display the requery time as well - and I can see that
sometimes the requery intervals are longer than 20 secons - sometimes as long
as 60 seconds.

How is that?

Is the Timer Interval really not a time, but a "cycle count" - and general
load on the PC can affect this?

 

[Michel Walsh]

Hi,

Windows works by sending message on a queue. When the processor got time, it
pumps a message and executes it... unless this is a Painting message or a
Timer message. A paint/timer message is only executed if there is not other
type of messages in the queue. So, on a very slow (busy) machine, the timer
event may miss a firing (or two)... We say they are low priority messages.
They are definitively not guaranteed to fire. It is preferable to ASK to
fire the event each x millisecond and, inside the timer event procedure, to
check against the reported clock time, not against the total number of time
the event fired. As example, if you write a game, and the event fire, you
look at the time, and then, compute where a given component (car, or
otherwise moving object) should be at THAT time... So, if the PC "freezes"
for a moment of two, when it comes back, your game is still "in synch" with
the other players. If you would have based your logic on the number of
frames you rendered (ie, based on the number of time the event fired), you
would then always be lagging by one of two frames-time... not desirable.



Hoping it may help,
Vanderghast, Access MVP

 

[DianePDavies]

Thanks. That explains what I am experiencing.

I can run my timer event more frequently and then check for the real time -
and then execute when time is exceeded. This still relys on the timer event
being fired every now and then though.

Is there a way to force the timer event to fire when due?

And what do you more specifically mean by "paint/timer mesage"

 

[Michel Walsh]

Hi,


There is no way to be 100% sure the event will fire in time, Windows is
not an operating system build for that. Sure, if you wish an event EventA to
fire each hour, then firing an eventB each 10 seconds to see if the clock
time is past the "next" expected hour, and if so, EXECUTE procedure EventA.
Your eventA procedure will then be run each "hour" plus or minus 10 sec (or
a couple of 10 sec).


in eventB, firing each 10 sec.

' eventB TimerInterval = 10000 ' 10000 msec = 10 sec
If Time >= ExpectedTime then

EventB
ExpectedTime=ExpectedTime + # 01:00:00# ' EventB will appear to
"fire" at the next hour

End If


Note that each OS has a lower limit on the possible slice of time. As
example, if memory serves, on W98, you will have a hard time to fire any
event faster than once each 33 milli-second. It is a little bit better on
XP, but I definitively don't remember the time slice for XP. There is
possibility to use a performance counter to get a very fine time granularity
(in the order of 1E-6 second) precision, but the OS seems to limit the
frequecyat which an event can fire, none the less.


A paint/timer message is a message about refreshing an area of the
screen (paint) or about firing a callback procedure associated to a timer.


You can also play on the priority of the application. On XP,
Ctrl-Alt-Del to get the Windows Task Manager, the "Processes" tab list the
processes (applications). Right Click on one, like MSACCESS.EXE, you get,
from the pop-up menu, Set Priority. You can increase a little bit the
priority of the process (you right click). How Windows works in this case is
like this: If there is ONE application at a top priority, that application
get ALL the CPU while it can run. If there are MANY applications at the same
given top priority, the CPU is shared between THOSE applications and between
THOSE applications ONLY. If there is no application, at a given top
priority, waiting for the CPU, then the next lower priority is considered.
And so on. If there is an actual process having the CPU and a new process
with a higher priority get launched (or unfreeze), the actual process is
descheduled (at a deschedulable point, as it is done when sharing the
resource, as example, between many processes at the same priority) ad the
new higher priority process get the CPU. So, being the only process at a
AboveNormal priority is more likely to get its paint and timer messages
processed, since they will be processed before any messages of any process
with a lower priority. Avoid using RealTime priority, since that is devoted
to Drivers-like behavior (such as putting some incoming data into a
buffer), and VBA is not necessary the best language to handle that kind of
stress. The system itself has priority hardware processes, so even at
RealTime, you MAY experience some delay, on some PCs, because of the
existence of these other processes with a quite high priority.




Hoping it may help,
Vanderghast, Access MVP