System clock always unsynced

[Jim Thompson]

You can prevent stepping of the clock with the -x option of ntpd.  The issue here is that "can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.”  http://doc.ntp.org/4.1.0/ntpd.htm

Running openntpd is a poor substitute for a real ntpd.

Answering, "What *does* an ntpd daemon need to do to sync the clock?” likely requires a thesis length posting, and it likely suffices to state that you’re not the first to discover that openntpd is a poor implementation of an NTP daemon.

Jim

> On Apr 27, 2015, at 9:39 AM, Christian Weisgerber <naddy at mips.inka.de> wrote:
> 
> I run OpenNTPD, from ports/net/openntpd, and I've noticed that after
> each reboot, the initial system time is further off.  (This is quite
> noticeable with OpenNTPD, since by default it does *not* jump the
> clock on startup like the base ntpd does.)  It's as if the RTC was
> never synchronized to the system clock.
> 
> Some digging in sys/kern/kern_ntptime.c shows indeed that the RTC is
> only synced if STA_UNSYNC is not set, and dumping the value of the
> timex struct...
> 
> offset:    0
> freq:      2730304
> maxerror:  84860000
> esterror:  500000
> status:    UNSYNC
> constant:  0
> precision: 0
> tolerance: 32500000
> state:     ERROR
> 
> ... reveals that the clock remains permanently unsynced.  Clearly,
> OpenNTPD, which uses adjtime(2) to correct offsets and ntp_adjtime(2)
> with MOD_FREQUENCY to correct the frequency, doesn't handle this
> quite right.
> 
> What *does* an ntpd daemon need to do to sync the clock?
> 
> The ntp_adjtime(2) man page documents struct timex in detail, but
> is very vague on what all of this means.
> 
> -- 
> Christian "naddy" Weisgerber                          naddy at mips.inka.de
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"