.NET Framework - High resolution Sleep

Asked By Charles Zhang on 02-Apr-08 12:09 AM
Sleep() function Sleep at lease 1 millisecond, there is a way to make a
thread to sleep less than a millisecond? One way I know of is using
performance counter which is not really sleep ( loop and check again and
again and uses CPU time).


Charles Zhang

Mark Salsbery [MVP] replied on 02-Apr-08 01:28 AM
Even Sleep() does not have true 1 ms resolution.

There is no better timer than the performance counter in Windows AFAIK.


Mark Salsbery
Microsoft MVP - Visual C++
Jordi Maycas replied on 02-Apr-08 06:10 AM
and.. what about with time struct?


where 99>=dd>=0

dd are miliseconds...

and thinking a little more, what about cpu cicles?
RFOG replied on 02-Apr-08 06:22 AM
You can use "clockres" from Sysinternals (today Microsoft) to see the
minimum resolution in your machine. Mine (Quad core is 15.6 ms).

I think less than 15 ms is impossible, and surely a sleep of 15 ms becomes
in a lot of more time because Windows uses that sleeping to do other tasks,
and if you put a for() loop you will get your CPU time scalated to 100% and
surely with no more precission that sleep.

Microsoft Visual C++ MVP
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Libros, ciencia ficción y  programación
Es un hecho que el hombre tiene que controlar la ciencia y chequear
ocasionalmente el avance de la tecnología.
-- Thomas Henry Huxley.
Jochen Kalmbach [MVP] replied on 02-Apr-08 07:09 AM

If you use "timeBeginPeriod(1)" you can mostly reduce the time-slice to
2 ms.

Willy Denoyette [MVP] replied on 02-Apr-08 07:37 AM
True, but this won't guarantee that your thread will get scheduled right
after 2ms. The scheduler is master of the game here, once you give up your
quantum, you'll have to wait until all other higher priority threads have

Jochen Kalmbach [MVP] replied on 02-Apr-08 07:42 AM
Hi Willy!


No. If a higher prio thread becomes ready to run, your quantum does not
matter. Your thread will be immediately interrupted and the higher prio
thread will run.

Jochen Kalmbach [MVP] replied on 02-Apr-08 07:48 AM
Hi Willy!

I wanted to say: This is only some side of the truth... sorry...

changli replied on 02-Apr-08 07:52 AM
Hi Charles,
Actually 1 millisecond is also not possible for Sleep function. Though you
can specify 1, the real value may be 10 or more. To get high resolution
timers that below 10 milliseconds, you need to call the kernel-mode
function NtSetTimerResolution, however for your higher timer resolution
requirement (within 1 millisecond), I am afraid that it is not possible at
upper language level. Maybe you can implement it via assemble language by
controlling interruption.

For more information, you may refer to the following article:
Inside Windows NT High Resolution Timers

Hope this give you some hints for your reviewing your requirements and

Best regards,
Charles Wang
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@microsoft.com.
Get notification to my posts through email? Please refer to

Note: The MSDN Managed Newsgroup support offering is for
non-urgent issues where an initial response from the community
or a Microsoft Support Engineer within 1 business day is acceptable.
Please note that each follow up response may take approximately
2 business days as the support professional working with you may
need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by
contacting Microsoft Customer Support Services (CSS) at
This posting is provided "AS IS" with no warranties, and confers no rights.
Willy Denoyette [MVP] replied on 02-Apr-08 08:06 AM
Hi Jochen,

I mean :
T1 normal priority calls sleep(2) - that is, give up your quantum now!
T2 normal priority gets scheduled runs for 1msec and enters a wait state
T3 higher priority  gets scheduled and runs for 1 sec.
T1 as slept ~1 sec
Sure above assumes a single proc machine :-)

Ben Voigt [C++ MVP] replied on 02-Apr-08 11:40 AM
This is not a drawback to calling sleep though, any wait method could be
pre-empted by a higher priority thread.
Ben Voigt [C++ MVP] replied on 02-Apr-08 11:42 AM
Waitable Timers allow the wait to be specified very precisely, however the
actual resolution will depend on the system clock interrupt.
timeBeginPeriod can make the clock interrupt faster to a point, I don't know
of any user-mode way to set the interrupt rate above 1kHz.
Willy Denoyette [MVP] replied on 02-Apr-08 12:02 PM
Willy Denoyette [MVP] replied on 02-Apr-08 12:30 PM
True, and for the same reason you can't use them to "wait" for an "exact"
(especially small)  amount of time when running on a Windows OS (even not on
Windows CE). Point is that once your (1) thread enters a wait state, you are
at the "mercy" of the scheduler to (2) wake you up. You are under control of
the first action, but you aren't of the second.
So whether you call Sleep(1) or WaitForSingleObject(..., 1), you will wait
for at *least* the RTC timer interval, whatever it's value.

Mark Salsbery [MVP] replied on 02-Apr-08 12:46 PM
Yes, many APIs have 1ms units in parameters.  Some use 100-nanosecond units.
But the actual accuracy is much less than 1ms.

See Charles Wang's response below...

Now you're at the performance counter level :)


Mark Salsbery
Microsoft MVP - Visual C++
Ben Voigt [C++ MVP] replied on 02-Apr-08 01:52 PM
In any OS with virtual memory, you aren't in complete control of #1 (you can
enter a wait state due to page fault).
And with preemptive multitasking, being non-runnable due to a wait state
isn't the only reason for a context switch.

True, although this is an OS design issue.  See for example the new tickless
support in the linux kernel, where the RTC is programmed based on the waits
requested by applications as well as the scheduler quantum instead of
running with a fixed interval, this gives all the benefits of a
high-frequency RTC interrupt with none of the overhead of extra processing
(although it is a little more complicated).
Willy Denoyette [MVP] replied on 02-Apr-08 02:38 PM
Yep, but  we are discussing Windows OS services here right?
On Windows, whenever you try to lower the RTC clock interval (say something
like 1 or 2 msec.), then the system starts to behave eratically (NT4 even
fails to boot), dont know about Vista and later, but clearly Windows is not
built to deal with such short RTC intervals. Note that here I mean
programming the RTC at the BIOS level, not by calling timeBeginPeriod.

See for example the new tickless

The same is more or less possible with Windows CE, which gives a user
program some more control over the scheduler, which runs at a 1 msec timer
interval by default (also the minimum).

Pavel A. replied on 02-Apr-08 06:04 PM
You can get Sleep() delay on XP close to the current timer resolution
but measuring the actual sleep time can be difficult.
I've made a simple test based on Sysinternals clockres sample.

The minimal resolution is  1 or  2 ms on most modern systems where the
default is 15.6 ms, and 1 ms on older systems where the default was 10 ms.
AFAIK there still is no good explanation why the newer PCs have default
resolution > 10 ms.

Surprising is that value returned by GetSystemTimeAsFileTime or
seems to update only once in system clock tick (15.6 ms in my case),
so when I call GetSystemTimeAsFileTime  before and after Sleep(1), I got
_same_ value 7 times out of 8;
and on 8th time the difference jumps to 15 ms :(   So the average Sleep()
delay of many samples is close to 1 ms.

Ben Voigt [C++ MVP] replied on 02-Apr-08 06:11 PM
Not difficult, just use QueryPerformanceCounter.
Willy Denoyette [MVP] replied on 02-Apr-08 07:19 PM
Indeed, measuring is the key, but as I said before, you can't Sleep (or
Wait) for a reliable amount of time,
when sleeping (waiting)  for < RTC interval, you give up your remaining
quantum, and you may possibly get re-scheduled after this period of time,
that is, after X msec. where X >= the remaining quantum.
For instance when you call Sleep(1) after your thread has run for Y msec,
you will probably sleep for 15.6 - X msec. on current multi-core/SMP
When you call Sleep(1) after your thread consumed 10 µsec of it's quantum,
this thread will sleep for at least 15.6 msec.
When you call Sleep(1) after your thread has consumed 14 msec you will sleep
for at least 1.6 msec.
That means you cannot reliably sleep with Windows ;-)

Compile and run the following sample , you'll see what I mean.

unsigned __stdcall Run(void* dummy)
double r = 0.0;
for(int i = 0; i < 50000000; i++)
r += (double)sqrt((double)i);
printf_s("%Lf\n", r);
return 0;
int main() {
__int64 startcount, stopCount, frequ;
HANDLE tHandle;
unsigned thread_Id;
Sleep(1); // Give up the current quantum so we can start with a fresh one
after return
tHandle = reinterpret_cast<HANDLE>(_beginthreadex(0, 0, &Run, 0, 0,
&thread_Id ));
//Or, use next
// WaitForSingleObject(tHandle, 1); // wait for thread to finish or timeout
printf_s("%Lf seconds\n", (double)(stopCount - startcount)/frequ);
return 0;

Pavel A. replied on 02-Apr-08 09:32 PM
thanks, point taken.
What are typical quantum values for the default priority class on  XP and

Ben Voigt [C++ MVP] replied on 03-Apr-08 10:00 AM
on desktop windows, at least, it depends on what other programs are running.
See the documentation for timeBeginPeriod.
Willy Denoyette [MVP] replied on 03-Apr-08 11:50 AM
The thread quanta on XP depend on whether a thread belongs to a foreground
or a background process, foreground threads have a quantum of 6 (RTC ticks),
others have a quantum of 2. Note that these are the default values and
assume that the priorities are the same, the real quantum can vary at run
time, the scheduler can boost the quantum with a value stored in the
Don't know the details for CE.