Subj : Re: high resolution time function under visual c++ environment?
To   : comp.programming
From : Joe Butler
Date : Thu Aug 04 2005 09:03 pm

It's been my understanding that QueryPerformanceFrequency() these days is
going to return the frequency of an NTSC colour crystal (about 3.5 MHz).
So, if that is the case, the processor clock may be stepped down, but the
QPF should still return the same frequency.

Actually just checked the docs and it says the frequency cannot change while
the system is running.

Has anyone actually confirmed if QPF ever returns a higher freq than 3.5 MHz
and if so, what hardware/OS combination gives that?


<websnarf@gmail.com> wrote in message
news:1123108670.667048.273280@g43g2000cwa.googlegroups.com...
> wavelet wrote:
> > I am searching one time function under windows2000
> > with Visual C++ environment. Is there function available
> > like gethrtime() in unix? Thx.
> >
> > #include <sys/time.h>
> >
> > main()
> > {
> >      hrtime_t start, end;
> >      int i, iters = 100;
> >
> >      start = gethrtime();
> >      for (i = 0; i < iters; i++)
> >              getpid();
> >      end = gethrtime();
> >      printf("Avg getpid() time = %lld nsec\n", (end - start) / iters);
> > }
>
> If you include the WinMM library, you can use the
> QueryPerformanceCounter() function to get access to the on-chip cycle
> counter, which is really as precise and you can get.
>
> The problem with using it is that it doesn't take "power savings modes"
> (which may include down-clocking the CPU) of the processor into
> account.  So you might like to do something like compare it to the
> incremental results of time(NULL) (or in fact clock(), since most
> Windows compilers don't subtract time not given to the process for that
> call) and if there is a sufficiently high deviation, you can
> recalibrate it via the QueryPerformanceFrequency() call.  You might
> need to do tricks to make sure that the output remains monotonic.  Of
> course you have to keep in mind that for most Windows compilers,
> time(NULL) will stop functioning properly in 2038.
>
> Hmm ... thinking about all this, I would be highly surprised if there
> wasn't a better solution somewhere.  :)
>
> -- 
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/
>

.