Re: Windows clock update frequency

Yes but what are you timestamping? I can't think of anything that would
need 1ms precision continuous resolution. If this is a sampling
application, then the results can always be post-processed to account for
clock drift; but you are suggesting that you need to process this data as a
stream.



BTW: you will have to deal with these additional issues:

1) When using NTP, the clock may gap forward or backward. This can
cause an item that was processed later in time than another item to have a
timestamp that is earlier.

2) The resolution of the timestamp you are looking for is on the same
order of magnitude as the time taken to query it, and beneath the size of a
quantum, so your results are inherently unreliable no matter what the clock
resolution

3) The accuracy of the clock may not be improved sufficiently by NTP in
order to obtain sub-second accuracy if the clock skew in a machine is large.
You may also need to run the machines for a long time (days / weeks) to
obtain reliable corrections for the skew.



BTW: it shouldn't surprise you that Windows has limited clock resolution.
Remember that the OS core was written for 386 and similar hardware. I
remember running NT 3.51 on a 16 MHz processor with 16 MB of RAM and
thinking that I had a killer fast system ;)


"Guillaume" <Guillaume@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:AA8B6A28-A9A7-437C-AF60-576BFDD62723@xxxxxxxxxxxxxxxx
It is for timestamping. Tick count has also a drift, which is small at the
beginning, but which is in minutes after several days... That is why we
need
a synchronization with system clock.

But because we also want to synchrnonize 2 servers, we use NTP. And tick
counts do not take into account NTP drift correction. I hope it better
explains why we need that.

Again, I find surprising that the clock update frequency is higher on
Linux
than on Windows.

"m" wrote:

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.






.

Relevant Pages

  • Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday
    ... >> The basic idea behind this is that ntp defines the frequency of the ... >> adjustment, which should be applied every f cycles. ... >> which allows for a very stable clock. ... >> resolution is still well within the practical limits of the clock. ...
    (Linux-Kernel)
  • Re: Reading time offset from ntp variables using ntpq
    ... I just wanted to use NTP as a tool to measure the time drift of my system clock and now you pull the dreaded "read the architecture briefing" weapon on me. ... I would guess that the transmit timestamp would provide the best accuracy if you have to measure over a short interval. ...
    (comp.protocols.time.ntp)
  • Re: Post processing of NTP data...
    ... One might measure the offset between the local system clock and UTC as the difference between the results of the gettimeofdayfunction executed on the local system and a 1 PPS signal standard. ... The offset measurement itself between an ntp system trained clock and the reference standard is a sum of the actual time error between the two clocks, the precision in which time is reported to the system OS by the hardware. ... The tick rate can generally be thought of as the system's metronome and limits the accuracy at which the system can report time. ... However I think OSes provide higher resolution time stamps, and I can only assume they interpolate between ticks with software. ...
    (comp.protocols.time.ntp)
  • Re: Reading time offset from ntp variables using ntpq
    ... > architecture briefing on the NTP project page. ... I just wanted to use NTP as a tool to measure the ... > the raw offset measurement does not reflect the actual clock offset, ... I would guess that the transmit timestamp would provide the best ...
    (comp.protocols.time.ntp)
  • Re: Hardware SNTP server
    ... Directly connecting our SNTP server and passing through ... We also have a remote experiment site, where we use a cesium clock ... the fraction of a timestamp is culculated from this 250MHz count. ... the NTP response is sent from the same GbE port. ...
    (comp.protocols.time.ntp)