Re: Precision issue of CreateTimerQueueTimer()
- From: "anton bassov" <soviet_bloke@xxxxxxxxxxx>
- Date: 13 Nov 2006 09:04:29 -0800
Tom,
Is this Microsoft's advice, or yours? If MS's, do you have a citation?
Calling QueryPerformanceCounter() eventually results in
KeQueryPerformanceCounter() call in the kernel mode.
This is what KeQueryPerformanceCounter() documentation in WDK says on
the subject
//////////////////
KeQueryPerformanceCounter is intended for time-stamping packets or for
computing performance and capacity measurements. It is not intended for
measuring elapsed time, for computing stalls or waits, or for
iterations.
Use this routine as infrequently as possible. Depending on the
platform, KeQueryPerformanceCounter can disable system-wide interrupts
for a minimal interval. Consequently, calling this routine frequently,
as in an iteration, defeats its purpose of returning very fine-grained,
running time-stamp information. Calling this routine too frequently can
degrade I/O performance for the calling driver and for the system as a
whole.
////////////
Finally, what do recommend as a general purpose solution for
sub-millisecond accurate time measurements?
Why would you need it, in the first place???? However, if you are just
desperate, you can try RDTSC instruction.
Just keep in mind that:
1. Every CPU on MP system has its own counter. Therefore, if you intend
to use this instruction, you have to make sure the target thread is
allowed to run only on one CPU
2. What happens if interrupt or context switch occurs while your code
executes????? How will it affect the accuracy of your results???? In
practical terms, once you have no control over the above mentioned
things in the user mode whatsoever, doing it in the user mode just
defeats the purpose
Anton Bassov
Tom Widmer [VC++ MVP] wrote:
anton bassov wrote:
Tom,
GetTickCount() has terrible resolution. Use timeGetTime() or
QueryPerformanceCounter instead.
QueryPerformanceCounter() is quite dodgy function. It has quite
different meaning on UP and MP HALs (respectively, system timer and
RDTSC instruction), and, hence, different resolutions, so that it has
to be taken into account when converting measured period to ms. In
fact, it is not supposed to be used for measuring elapsed time, in the
first place (only for timestamps)
Is this Microsoft's advice, or yours? If MS's, do you have a citation?
Finally, what do recommend as a general purpose solution for
sub-millisecond accurate time measurements?
Furthermore, it disables interrupts on some platforms, so that calling
it too frequently may have undesireable consequences for the system....
MS recommend not calling it more than necessary:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Game_Timing_and_Multicore_Processors.asp
Tom
.
- Follow-Ups:
- Re: Precision issue of CreateTimerQueueTimer()
- From: Tim Roberts
- Re: Precision issue of CreateTimerQueueTimer()
- References:
- Precision issue of CreateTimerQueueTimer()
- From: Rainny
- Re: Precision issue of CreateTimerQueueTimer()
- From: Tom Widmer [VC++ MVP]
- Re: Precision issue of CreateTimerQueueTimer()
- From: anton bassov
- Re: Precision issue of CreateTimerQueueTimer()
- From: Tom Widmer [VC++ MVP]
- Precision issue of CreateTimerQueueTimer()
- Prev by Date: Re: CreateFile() returns ERROR_ACCESS_DENIED to the user
- Next by Date: Re: CreateFile() returns ERROR_ACCESS_DENIED to the user
- Previous by thread: Re: Precision issue of CreateTimerQueueTimer()
- Next by thread: Re: Precision issue of CreateTimerQueueTimer()
- Index(es):
Relevant Pages
|