[ntp:questions] Period of TimerApcFunction in nt_clockstuff.c?

Dave Hart davehart at gmail.com
Sun Apr 25 14:58:48 UTC 2010


On Sun, Apr 25, 2010 at 14:20 UTC, Chaofu Chen wrote:
> Recently, I was reading the source code of NTP ports for windows.
> In \NTP\ntp-4.2.6p1\ports\winnt\ntpd\nt_clockstuff.c I noticed the
> period of TimerApcFunction is set to 43ms as default value for a
> 64Hz OS (which has clock resolution of 15.625ms). Where is this
> 43ms come from? Based on experiment result? I don't have a clue.
> Can someone give me some light?

The 43ms value is based on experimentation.  The job of the clock
thread is to collect samples covering the last few seconds correlating
the 15.625ms-stepping clock with the high-resolution counter used by
QueryPerformanceCounter().  The sampling period needs to land
unpredictably within the 15.6ms ticks for interpolation to work well,
so that at any given time, one of the recent counter/clock
correlations was taken very close to the prior tickover of the clock.

When using the correlations to interpolate the current time, the best
correlation is found with logic inspired by the NTP clock filter
algorithm, which assumes the sample with the lowest delay of the last
8 represents the best estimate of the difference between the local and
remote clocks.  Each correlation is used in turn to compute a
preliminary guess at the current time, and then the earliest result is
used.  Just as with delay in the clock filter, the error attributable
to the counter/clock sample being taken some time after the clock last
ticked forward 15ms is unidirectional, so using the earliest resulting
time chooses the minimum sampling-related error.

Cheers,
Dave Hart




More information about the questions mailing list