Date: Mon, 21 Jul 1997 22:09:05 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: dbader@umiacs.umd.edu Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp, freebsd-stable@FreeBSD.ORG Subject: Re: ntpdate (was Re: "saver") Message-ID: <199707220209.WAA10142@whizzo.TransSys.COM> In-Reply-To: Your message of "Mon, 21 Jul 1997 08:30:36 EDT." <199707211230.IAA12056@eve.umiacs.umd.edu> References: <199707211230.IAA12056@eve.umiacs.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
The "ntpdate" program was primarily intended as a way to get the clock on your system set with minimal accuracy, say within a few hundred milliseconds. The assumption is that you then start an NTP daemon which keeps the clock synchronized to a much tighter tolerance. The long-lived daemon has the ability to better estimate the path characteristics over a large number of clock offset/delay samples as well as being able to do a better job at not trying to synchronize to an "insane" clock. Additionally, it can estimate the intrinsic drift of the clock in your system, and continue to apply frequency corrections even if it loses contact with it's reference clock. Running an ntpdate periodically "behind the back" of an NTP daemon throws much of this out of kilter, and is obviously wrong if you happen to be running xntpd on your system. I think having ntpdate in /etc/daily is really broken unless it's automatically inhibited should you have xntpd configured to run. louie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707220209.WAA10142>