Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Apr 2015 10:28:35 -0500
From:      Jim Thompson <jim@netgate.com>
To:        Christian Weisgerber <naddy@mips.inka.de>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: System clock always unsynced
Message-ID:  <0E68BBCF-5E21-4189-9358-F7BA3F5BECDC@netgate.com>
In-Reply-To: <slrnmjsigv.8j.naddy@lorvorc.mips.inka.de>
References:  <slrnmjsigv.8j.naddy@lorvorc.mips.inka.de>

next in thread | previous in thread | raw e-mail | index | archive | help

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.=E2=80=9D  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?=E2=80=
=9D likely requires a thesis length posting, and it likely suffices to =
state that you=E2=80=99re 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@mips.inka.de> =
wrote:
>=20
> 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.
>=20
> 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...
>=20
> offset:    0
> freq:      2730304
> maxerror:  84860000
> esterror:  500000
> status:    UNSYNC
> constant:  0
> precision: 0
> tolerance: 32500000
> state:     ERROR
>=20
> ... 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.
>=20
> What *does* an ntpd daemon need to do to sync the clock?
>=20
> The ntp_adjtime(2) man page documents struct timex in detail, but
> is very vague on what all of this means.
>=20
> --=20
> Christian "naddy" Weisgerber                          =
naddy@mips.inka.de
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to =
"freebsd-hackers-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E68BBCF-5E21-4189-9358-F7BA3F5BECDC>