Re: Ntpdate and sntpclock differ by 20+ seconds

Bennett Todd <[email protected]> Fri, 31 Jan 2003 13:36:40 -0500
Newsgroups gmane.comp.lib.libtai
Message-ID <[email protected]>
2003-01-30T16:45:50 Paul Jarc:
> sntpclock assumes the local clock is TAI - that it counts all seconds,
> including leap seconds.  ntpdate assumes the local clock is POSIX-
> that it count only non-leap seconds.  ntpdate is telling you that if
> you intend your clock to be a POSIX clock, it's well-synchronized.
> sntpclock is telling you that if you intend your clock to be a TAI
> clock, it's 22 seconds behind.

And to complete the tale, there are two "compatibility shims" to
know about.

If you want to run your system in TAI, then for most purposes, you
can set your timezone to one of the "right/" timezones. So if (as I
am hereabouts) you'd normally be "US/Eastern", use instead
"right/US/Eastern". Many systems come with the "right" timezones,
that know about leap seconds; those who don't can almost always
rebuild from from the Olson time database data, available from
<URL:ftp://elsie.nci.nih.gov/pub/>. There are some potential
problems with this approach; there's some software that really uses
POSIX's mandated guarantee that all days are always 86,400 seconds
long (leap seconds do not exist), and breaks when you run in TAI.
Not a lot of software, in practice, though. It may be helpful to set
up a standalone NTP sender to broadcast this view of time to
ntp-synchronizing systems that need to timestamp things in "seconds
since the epoch", like e.g. network fileservers and the like. Such
NTP servers would be technically wrong, but when viewed through an
interpretation of a TAI-ignorant appliance translating the NTP time
into seconds-since-epoch time, which are then decoded by a TAI-aware
platform, the results might well line up.

If you want to run your system in POSIX's perverted "UTC jerked
around to create the illusion that leapseconds don't exist",
but still want to use the clockspeed package, just delete
/etc/leapsecs.dat. And think about maybe stopping clockspeed,
hand-syncing the clock, and restarting clockspeed around leapseconds
to avoid having the required clock skip confuse clockspeed's
stabilization.

-Bennett
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+OsI3HZWg9mCTffwRAjHtAJwK1Sp/uI2CYg8hwfWFNeoIETpVTQCZASj2
/wmRvN8jf98OknV7pOti0w8=
=+sFH
-----END PGP SIGNATURE-----