Jukka Marin <jmarin@teeri.jmp.fi> writes:

>Jason Thorpe said:
>
>> Why not keep both?  I use xntpd on my main server to get time from a 
>> reliable source, and then use timed in a master/slave configuration to 
>> sync time on my small network at home.  It's not _completely_ useless :-)

>I'm doing this, too.  timed is a smaller thing to run and as it's part of
>the standard distribution, it saves time (you only need xntpd on one
>system).  Please keep timed in NetBSD.  Thanks.

My own opinion on xntpd vs. timed is this: let individual users decide
for themeslves. timed is small enough that it may well be worth
keeping for those who don't want the overhead (memory residence, or
configuration effort) of using xntpd.  Including an xntpd in the
NetBSD distribution would be a Good Thing for spreading NTP-based
clocking, but not essential. (It's no accident that there are so many
NTP version 1 servers still running on the Internet on Ultrix hosts:
Ultrix ships with ntpd, even though ntpd, like Ultrix, is now obsolete.)

To re-state the point behind why I started this thread: xntpd can do a
much better job of synchronizing the system clock if the underlying
kernel has David Mills' kernel phase-locked-loop clock-disciplining
code, and the ntp_adjtime() syscall with which to control the PLL
code.  NetBSD does not have ntp_adjtime() -- only a do-nothing stub in
the FreeBSD emulation code.

Versions of both timed and xntpd that compile `out of the box' on
NetBSD are and will be available, regardless of whether or not the are
in a NetBSD distribution.  I think the more important issue is the
level of *kernel* support NetBSD has for xntpd, since that's more
effort to add if it's not there already.

If NetBSD supports ntp_adjtime(), it will make those of us who *do*
want to run xntpd much happier.  Mills' kernel code can also support
radio-clocks pulse-per-second TTY disciplines, for those who run
low-stratum, radio-clock-synched, NTP timeservers.  Incorporating
ntp_adjtime() would make NetBSD a viable platform for running a
low-stratum timeserver -- without the hassle of having to incorporate
ntp_adjtime() and into some vendor OS.

I, personally, think that having the ntp_adjtime() support would be a
neat thing, and should also be good press for NetBSD.  That issue is
now under consideration in the appropriate forum.