High resolution Sleep

  • Thread starter Thread starter Charles Zhang
  • Start date Start date
C

Charles Zhang

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).

Thanks

Charles Zhang
 
Even Sleep() doesn't have true 1 ms resolution.

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

Mark
 
and.. what about with time struct?

hh:mm:ss,dd

where 99>=dd>=0

dd are miliseconds...

and thinking a little more, what about cpu cicles?
 
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.

Charles Zhang said:
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).

Thanks

Charles Zhang
Click to expand...

--
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.
 
Hi RFOG!
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.
Click to expand...

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

Greetings
Jochen
 
Jochen Kalmbach said:
Hi RFOG!


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

Greetings
Jochen
Click to expand...


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
run.

Willy.
 
Hi Willy!
True, but this won't guarantee that your thread will get scheduled right
after 2ms. The scheduler is master of the game here,
Yes...

once you give up
your quantum, you'll have to wait until all other higher priority
threads have run.
Click to expand...

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.

Greetings
Jochen
 
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
http://technet.microsoft.com/en-us/sysinternals/bb897569.aspx

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

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: (e-mail address removed).
===========================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

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
http://msdn.microsoft.com/subscriptions/support/default.aspx.
============================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================
 
Jochen Kalmbach said:
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.
Click to expand...

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 :-)

Grüßen,
Willy.
 
Willy said:
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
Click to expand...

This isn't a drawback to calling sleep though, any wait method could be
pre-empted by a higher priority thread.
 
Charles said:
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).
Click to expand...

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.
 
Ben Voigt said:
This isn't a drawback to calling sleep though, any wait method could be
pre-empted by a higher priority thread.
Click to expand...

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.

Willy.
 
Jordi Maycas said:
and.. what about with time struct?

hh:mm:ss,dd

where 99>=dd>=0

dd are miliseconds...
Click to expand...


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...

and thinking a little more, what about cpu cicles?
Click to expand...


Now you're at the performance counter level :)

Mark
 
Willy said:
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.
Click to expand...

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.
So whether you call Sleep(1) or WaitForSingleObject(..., 1), you will
wait for at *least* the RTC timer interval, whatever it's value.
Click to expand...

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).
 
Ben Voigt said:
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.
Click to expand...
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
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).
Click to expand...

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).

Willy.
 
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
NtQuerySystemTime
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.

Regards,
--PA
 
Pavel said:
You can get Sleep() delay on XP close to the current timer resolution
but measuring the actual sleep time can be difficult.
Click to expand...

Not difficult, just use QueryPerformanceCounter.
 
Pavel A. said:
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
NtQuerySystemTime
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.

Regards,
--PA
Click to expand...



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
systems.
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.


#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0500
#endif
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <process.h>
#include <cstdio>
#include <math.h>
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);
_endthreadex(0);
return 0;
}
int main() {
__int64 startcount, stopCount, frequ;
QueryPerformanceFrequency((LARGE_INTEGER*)&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 ));
QueryPerformanceCounter((LARGE_INTEGER*)&startcount);
Sleep(1);
//Or, use next
// WaitForSingleObject(tHandle, 1); // wait for thread to finish or timeout
QueryPerformanceCounter((LARGE_INTEGER*)&stopCount);
CloseHandle(tHandle);
printf_s("%Lf seconds\n", (double)(stopCount - startcount)/frequ);
return 0;
}



Willy.
 
Back
Top