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