Thread: Delay using timeGetTime is too short

Ok I understand that by trying to create a delay using timeGetTime I'll get an approximate delay, not an exact one. But if anything it should be AT LEAST the amount of time I tell it to delay. My problem is:

I have one
printf ("time is: %i", timeGetTime());
statement before and one after executing the following code. The difference between the first and the second outputs is always much less than 1 sec (usually between 500 and 600 ms)...

Code:

int Delay1sec(void)
{
	static unsigned long ultime = timeGetTime()+1000;
	while (timeGetTime()<ultime)
	{ Sleep(5);	}
	ultime = timeGetTime()+1000;
	return 0;
}

What am I doing wrong?

Why not just Sleep(1000)?

From MSDN

Windows Multimedia
Previous Next

timeGetTime
The timeGetTime function retrieves the system time, in milliseconds. The system time is the time elapsed since Windows was started.

DWORD timeGetTime(VOID);
Parameters

This function does not take parameters.

Return Values

Returns the system time, in milliseconds.

Remarks

The only difference between this function and the timeGetSystemTime function is that timeGetSystemTime uses the MMTIME structure to return the system time. The timeGetTime function has less overhead than timeGetSystemTime.

Note that the value returned by the timeGetTime function is a DWORD value. The return value wraps around to 0 every 2^32 milliseconds, which is about 49.71 days. This can cause problems in code that directly uses the timeGetTime return value in computations, particularly where the value is used to control code execution. You should always use the difference between two timeGetTime return values in computations.

Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution,

Windows 95: The default precision of the timeGetTime function is 1 millisecond. In other words, the timeGetTime function can return successive values that differ by just 1 millisecond. This is true no matter what calls have been made to the timeBeginPeriod and timeEndPeriod functions.

Requirements

Windows NT/2000/XP: Included in Windows NT 3.1 and later.
Windows 95/98/Me: Included in Windows 95 and later.
Header: Declared in Mmsystem.h; include Windows.h.
Library: Use Winmm.lib.

See Also

Multimedia Timers, Multimedia Timer Functions, timeGetSystemTime, MMTIME, timeGetTime, timeBeginPeriod, timeEndPeriod, QueryPerformanceCounter, QueryPerformanceFrequency

Previous Next

--------------------------------------------------------------------------------

© 2005 Microsoft Corporation. All rights reserved.

Since the default res is >= 5 ms you may not get accurate timing unless you call timeBeginPeriod() and timeEndPeriod() to set the resolution. For high performance timing you should look into QueryPerformanceFrequency() and QueryPerformanceCounter(). Note that on AMD dual core machines you may need to also call SetProcessAffinityMask() since the BIOS's on those machines do not accurately handle the performance counters from the 2 cores.

NVM I found out what the problem was. My application(it's an infinite loop) was taking longer to process than 1 sec sometimes an therefore the delay wouldn't work in this case because I declared it as a static variable.
Sleep is usually not a good choice in time-critical applications because it has poor resolution. Also I needed a function that would take into account the amount of time elapsed since the delay's last execution.
Thanks Elysia and bubba.