>If I understand this thread correctly, xntpd must be reading time off a
>time server, right?

It is actually a lot more sophisticated than that.  NTP phase locks to at
least one (preferably three or more) remote time sources and attempts to
trim out the drift in the local clock.  By averaging many samples it can
generally do a good job of removing the uncertainty (and magnitude) of
network delays and keep the local clock accurate to within a few tens of
milliseconds---even if the network delay is a large fraction of a second.

I strongly encourage this group to leave NTP development to the NTP folks.
NTP is a notoriously unstable product.  Its developers do not distinguish
between tested and development versions.  New versions may be released
daily, or even more often.  We don't want our reliability held hostage to
their problems.  There are philosophical reasons---related to the treatment
of leap seconds and other things---why one may need the standard BSD
treatment of time.  (NTP forgets all about leap seconds once they are over,
so historical time values tend not to mean what you want.)  NTP is only
useful if you actually have a network connection to a real time server (or
you really get off on configuring weird interfaces to radio clocks/GPS
receivers/atomic clocks).  Finally, NTP is just a pain to configure and
debug compared to timed.

However there are some issues that *should* be addressed by either this
group or by one of the more-generic BSD groups:  We should make sure there
are appropriate configuration files for *BSD in the NTP distribution.  We
should address the mechanisms used by NTP to control the clock and make
sure they are compatible.  (Does NetBSD have a dosynctodr variable and the
set-to-pram clock process that it controls?  Given the reputedly lousy
timekeeping of MacBSD it sounds like a good idea!)  Finally, we should do
what we can to prevent, or compensate for, lost time interrupts.

Signature (perhaps permanently) under construction.  hotz@binky.jpl.nasa.gov