[LEAPSECS] Time math libraries, UTC to TAI

Steve Summit scs+ls at eskimo.com
Tue Jan 3 22:17:12 EST 2017


Martin Burnicki wrote:
> Steve Summit wrote:
> > The answer is that on a system with the mods installed, #1
> > happens all the time for the system calls time(), gettimeofday(),
> > and clock_gettime(CLOCK_REALTIME).  It does not happen for
> > adjtimex, on the assumption that that's what ntpd is using.
> > #2 happens only when you call clock_gettime(CLOCK_UTC).
>
> Unfortunately the assumption that ntpd uses adjtimex() to compute the
> current time offset is wrong, as far as I have seen. See my other post.

Yes, I noticed.  Thanks.

> So if the system calls gettimeofday() and clock_gettime(CLOCK_REALTIME)
> return smeared time then ntpd also sees smeared time.

Right.  Which would completely undermine its clock disciplining
algorithm.

> IMO another clock type to be used with clock_gettime() would help, as
> already proposed by Markus Kuhn (there was a link to this in a recent
> post here), which could be used by new or actively maintained software.

Sure.  (But are you talking about CLOCK_UTC, or yet another new id?)
At any rate, yes, ntpd is certainly a fine candidate for being
modified to use clock_gettime and special clockids.

(I went down the road I did because one of my secondary goals was
to rig things up so that you could successfully use a modified --
fully UTC-aware -- kernel along with an unmodified ntpd.  At
first I was thinking of having the smearing scheme be adjustable
on a per-process basis, with ntpd's process getting 'unsmeared'
even for CLOCK_REALTIME.  But then I realized that since ntp --
I thought -- used adjtime for everything, I could use the trick
I described.  Oh, well.)


More information about the LEAPSECS mailing list