Why is the sleep-time of Sleep(1) seems to be variable in Windows?

Last week I needed to test some different algorithmic functions and to make it easy to myself I added some artifical sleeps and simply measured the clock time. Something like this:

start = clock();
for (int i=0;i<10000;++i)
   {
   ...
   Sleep(1);
   ...
   }
end = clock();

Since the argument of Sleep is expressed in milliseconds I expected a total wall clock time of about 10 seconds (a big higher because of the algorithms but that's not important now), and that was indeed my result.

This morning I had to reboot my PC because of new Microsoft Windows hot fixes and to my surprise Sleep(1) didn't take 1 millisecond anymore, but about 0.0156 seconds.

So my test results were completely screwed up, since the total time grew from 10 seconds to about 156 seconds.

We tested this on several PC's and apparently开发者_运维问答 on some PC's the result of one Sleep was indeed 1 ms. On other PC's it was 0.0156 seconds.

Then, suddenly, after a while, the time of Sleep dropped to 0.01 second, and then an hour later back to 0.001 second (1 ms).

Is this normal behavior in Windows? Is Windows 'sleepy' the first hours after reboot and then gradually gets a higher sleep-granularity after a while? Or are there any other aspects that might explain the change in behavior?

In all my tests no other application was running at the same time (or: at least not taking any CPU).

Any ideas?

OS is Windows 7.

I've not heard about the resolution jumping around like that on its own, but in general the resolution of Sleep follows the clock tick of the task scheduler. So by default it's usually 10 or 15 ms, depending on the edition of Windows. You can set it manually to 1 ms by issuing a timeBeginPeriod.

I'd guess it's the scheduler. Each OS has a certain amount of granularity. If you ask it to do something lower than that, the results aren't perfect. By asking to sleep 1ms (especially very often) the scheduler may decide you're not important and have you sleep longer, or your sleeps may run up against the end of your time slice.

The sleep call is an advisory call. It tells the OS you want to sleep for amount of time X. It can be less than X (due to a signal or something else), or it can be more (as you are seeing).

Another Stack Overflow question has a way to do it, but you have to use winsock.

When you call Sleep the processor is stopping that thread until it can resume at a time >= to the called Sleep time. Sometimes due to thread priority (which in some cases causes Sleep(0) to cause your program to hang indefinitely) your program may resume at a later time because more processor cycles were allocated for another thread to do work (mainly OS threads have higher priority).

I just wrote some words about the sleep() function in the thread Sleep Less Than One Millisecond. The characteristics of the sleep() function depends on the underlying hardware and on the setting of the multimedia timer interface.

A windows update may change the behavior, i.e. Windows 7 does treat things differently compared to Vista. See my comment in that thread and its links to learn more abut the sleep() function.

Most likely the sleep timer has not enough resolution.

What kind of resolution do you get when you call the timeGetDevCaps function as explained in the documentation of the Sleep function?

Windows Sleep granularity is normally 16ms, you get this unless your or some other program changes this. When you got 1ms granularity other days and 16ms others, some other program probably set time slice (effects to your program also). I think that my Labview for example does this.