GetTickCount lies??
 

Hi guys!

Have faced some very interesting problem with GetTickCount.

Imagine I placed to the thread, in some endless loop, such code:
What do you think the "x" contains? Usually this is value >= 1000, but sometimes it is 999, and more curious, sometimes it is 998. Tested with 997 and looks like this never happens.

Do you know why after 1000 milliseconds sleep GetTickCount shows 998 milliseconds difference?

Sure it is not the Sleep function that lies?

On a determinate real-time operating system, it should return 1000 every single time without fail. Windows is not a determinate real-time operating system, so the value cannot be guaranteed. it's theoretically possible that the second call never occurs, and if/when it is called it could be at any priority level, with any number of other processes competing for CPU time at both higher and lower priorities.

Git

To BoB I do not what functions lies...

To Git I'm using usual PC with Win 7 x64, not under VMware and so on...

So do you think it is normal? And what other results do you think we could get after Sleep(1000)? Looks like it is quite unstable code and sometimes we could get 900 and even 1 :8 ?

@Git

Theoretically
A Real Time System must return Exactly 1000
But a non Real Time system shouldn't return a value less than 1000 but more than 1000

I think it's a algorithm related problem caused by Sleep function.

I see your point overflow, but thinking about it, couldn't the GetTickCount() function get robbed of CPU time and hence run slow?. All depends how it is implemented. If it reads a real time clock, or is interrupt driven then it should never return a low count. If it is just a queued task bumping a counter I think it could. In this example, the same applies to the Sleep() function.

Git

You cannot rely on any exact timing on Windows - it's not a real-time OS.
A context switch may always occur in the middle of your code, delaying it significantly. For example, you call the first GetTickCount, then Sleep - and after the Sleep function returns (and before the second GetTickCount is called), your process loses the CPU, another running process uses it for a while (say 20ms to the next timeslice), and then you get it back - so it looks like your Sleep actually took 20ms longer.
[OK, I know this scenario is quite unlikely with this particular code, because you'd probably get a full timeslice after Sleep, but it's just to illustrate the point].

As for why it should be less than 1000 ms... even the today's hardware doesn't make it easy for exact timing. With all those turbo modes (the CPU frequency gets temporarily increased under load) and power saving features (the CPU clock is reduced if not under heavy load - especially on mobile devices), it's very hard to measure time exactly.

VirtualDub's author wrote about it years ago: http://virtualdub.org/blog/pivot/entry.php?id=106

It could also be that the resolution of the system clock isn't that accurate.

Did you try using timeBeginPeriod to set the timer resolution ?

Don't forget that Sleep works by creating a thread to release the remainder of your time slice, which also involves delays.

MSDN says: "The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.".

For Sleep(1000) that would give a min time of 984 and a max of 1016.

That does not include the call/ret overhead for the Sleep/GetTickCount functions.

gigaman - thanks you very much for the very helpful reply!

Now this problem is more clear for me, thanks!

To dila - good MS note, but the word "typically" is very confusing :) typically 16 ms, but sometimes it could have more differences.

@Enigma:
The resolution is approximatively 10 ms for uniproc and 15 (15,625) ms for multi.
Check it wih ClockRes from SysInternals.
INT 1a use it's 65536 / 1193180 ie # 0,055 s

Regards.

Hi
You could try multimedia timers it's more accurate and has higher resolution.
good luck