Re: Windows clock update frequency

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

What would you need this for? I am curious because I can't think of
anything that would have this requirement. For a high rate sequence /
timestamp (e.g. while sampling at high frequency), tick count would be
better because it can't go backwards and you can use statistical analysis to
correlate the tick counts to absolute time; for a regular timestamp, I can't
see how a resolution of 1 ms would be meaningful.



"Guillaume" <Guillaume@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:966D8334-F927-4C04-8296-734E6DA60A0C@xxxxxxxxxxxxxxxx
Thanks for that. In fact, we have already tried this solution, but it does
not change a lot of things.
So you confirm that it is not possible on Windows to update the clock
update
frequency? It seems different on Linux, that is why I wonder.

"Tim Roberts" wrote:

Guillaume <Guillaume@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

In fact, I have 2 servers synchronized with NTP, and on each server, I
need
an accurate time. I cannot rely only on timers, because they are not
impacted
by NTP. So I would like to rely on the absolute time, but with Windows,
the
accuracy seems to be only 15/16 ms. On Linux, gettimeofday() seems to
have a
1 ms accuracy.

I think you will have to get clever. You could, for example, align the
cycle counter and the wall clock time every now and then, doing something
like this:

FILETIME ftmAlign;
LARGE_INTEGER qpcAlign;

void align()
{
FILETIME ftm1, ftm2;
GetSystemTimeAsFileTime( &ftm1 );
while( 1 )
{
GetSystemTimeAsFileTime( &ftm2 );
if( ftm1.dwLowFileTime != ftm2.dwLowFileTime )
break;
}
QueryPerformanceCounter( &qpcAlign );
}

Now, you can call QueryPerformanceCounter, figure the delta between it
and
qpcAlign, and add that to ftmAlign.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.



.