[ntp:questions] Experimental ntpd for Windows

Dave Hart davehart at gmail.com
Thu Jan 29 20:54:12 UTC 2009


On Jan 29, 11:38 am, Harlan Stenn <st... at ntp.org> wrote:
>
> If we can automatically detect when a "behavior shift" is needed and effect
> that change, great.
>
> If we cannot automatically detect these situations but we have a mechanism
> that would allow folks to select the behavior that is best for them, that's
> just fine.

As it stands with my experimental version, it does not attempt to
detect on an ongoing basis whether interpolation is inappropriate due
to the system clock precision being raised.  The test is done once on
startup.  I realize that is suboptimal, though it is still an
improvement over the status quo.  The reason I haven't tried to adapt
dynamically is architectural.  The obvious place to dynamically detect
a too-low system time quantum while interpolating is in the high-
priority timer thread, which is watching for every tickover of the
system clock already.  Being asynchronous to the main ntpd thread, it
can not simply switch off interpolation itself, at most it can signal
the main thread so that the next time the Windows-port-specific
gettimeofday() routine is called on the main thread, it could switch
off interpolation.  Architecturally within ntpd, though, it seems
wrong to me for the simulated system service gettimeofday() to effect
such a change.  If interpolation is switched off on the fly by
gettimeofday(), ntpd's sys_precision would be wrong, continuing to
claim a few microseconds precision when in fact it would be whatever
the system clock quantum had become, likely 500 usec to 3000 usec (3
msec).  gettimeofday() could conceivably fix up sys_precision on the
fly, but what effect will this have on the portable ntpd code?  I
would love to be able to switch interpolation on and off as it makes
sense, but first I would like to understand that ntpd portable code
will not be broken by it.

> Let's keep making incremental and/or quantum (no puns intended)
> improvements.

Cheers,
Dave Hart




More information about the questions mailing list