Reliability of Timers

I am concerned about the vulnerability of timers to being delayed by background processing. (In the mid nineties, writing real-time programs in C under DOS, we found that interrupts could be held at bay for up to a third of a second, occasionally, due to background disk operations. That was old software on old hardware.) Currently, I find occasional glitches in a simple ~ 1.1 second timer playing a short audio click, or similar (so far, always at start-up). This involves layers of VB6 as well as the windows system (Win2000), of which I have little knowledge. I have two questions:

1. Roughly, what can be said about the sources of lack of reliability/accuracy of timers in logic using VB6 timers?

2. Are there timing/timer functions in DirectX that would be more reliable?

Thanks in advance,
Jim

The timers are poor *in most cases* i think the most accurate they are is 15 ms *nt sur eon that*

you could use the GetTickCount Api or evan the QueryPerformanceCounter api bothe are more accurate :) as for direct x i dotn think direct x has any built in timer function most people use one of the above apis :)

Then include a sync check in your algo, say check every hour if its synced or not with the system clock.

What you can do is a little trick:

1. set the interval to 800 ms
2. Have the timer insert the Time$ in a textbox
3. And then on Textbox_Change you know that one second has passed (change will not be triggered if the data entered is the same as the one already in it)

Re baja_yu: If I understand your intent correctly, you are suggesting setting the timer to fire early, then sitting in a loop, testing the system clock for the desired time, to insure accuracy. Clever idea.

It seems to me though that the loop has to run without "DoEvents", or else there is no advantage. Or, one could loop with "DoEvents", but not release to "DoEvents" when one gets critically close to the desired time. That critical time would be a reasonable estimate of the period of timne for which one could be interrupted by tasks (including system tasks) that could run on the "DoEvents".

To all: In general, I assume GetTickCount, and other such, would give a reasonably accurate time count (easily within the 10+ ms desired). The question I have is: How long can the timer logic, (a) within VB6/system or (b) within one's own program, be held off by background system (or other programs) processing? If there is a delay in getting control, it doesn't make any difference how accurate the time routines are, one has missed the desired time of the timer event.

Here is a rephrase of my questions:
What is the maximum temporal latency of timer events in a Windows 2000 operating system?
Is there knowledge of background programs that may have a significantly detrimental contribution to such latency?

Thanks for your participation
Jim

We could very well derive the latency from a series of statistics, matched with the known identities of Timer API code, but the detrimental effects would very well be exposed on slower systems.:rolleyes:

:p What I mean is the Timer is horrible, and really depends on the speed of your system. For my computer using Windows XP, the timer is accurate to 10ms. Any slower and accuracy will suffer. The best timing would be the multimedia timers, which could be accessed using API.

That is helpful.

Have you run for long enough durations to know if there are "oddball" occurances in the system that might cause a much longer "hold-off" occasionally? (For example, something similar to the occasional long disk cache operation [~ 300 ms hold-off} we experienced maybe once in 20 minutes or so in a very old real-time app under DOS. [Knowing what the cause was, we got around it fairly easily.])

Thanks,
Jim