Re: [LEAPSECS] Internet-Draft on UTC-SLS

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Thu, 19 Jan 2006 14:17:17 -0700 (MST)

In message: <E1EzgIS-00012m-00_at_mta1.cl.cam.ac.uk>
            Markus Kuhn <Markus.Kuhn_at_cl.cam.ac.uk> writes:
: "M. Warner Losh" wrote on 2006-01-19 19:20 UTC:
: > Effectively, you'd have to have two time scales in the kernel. UTC
: > and UTC-SLS. You make it sound simple, but the hair in doing this may
: > be quite difficult. There's more book for the kernel to keep, and it
: > would have to expose the bookkeeping to userland for ntp to work.
: > What makes this hard is that ntpd may introduce steers into the normal
: > system time at normal times which it doesn't want to confuse with the
: > steers in frequency that are used during a UTC-SLS operation.
:
: You correctly point out some of the design considerations that have to
: go into such code. You describe roughly one of the (several) different
: ways of implementing all this that I have in mind. In comparison to how
: complicated the Mills kernel PLL is already today, that does not
: actually sound like an overwhelming additional complexity. Actually, it
: sounds quite doable when you think through it a bit. Not trivial, but
: carefully doable without performance penalty.

Anything that makes the Mills' kernel PLL more complicated is unlikely
to be implemented correctly. There have been several subtle bugs in
Mills' implementation that have taken a long time to sort out. In
fact, members of this list have found some of them and have a lot of
experience with Mills' kernel PLL.

Many people in the timing community are unhappy with Mills'
implementation. They believe it to be way too complex and have been
trying to implement a much simpler implementation that gives more
control to the measurement process to apportion the errors that it
measures by doing simpler steers. It moves the kernel time control in
the wrong direction.

: The important thing is: All this has to be done only *once* for each
: operating system and *once* for each each NTP client/server used on it,
: by someone who understands the issue, and then the problem is hopefully
: solved. We've handled far more complicated things in OS kernels, right?

No. It has to be done continuously. By that I mean that you can
clearly write an implementation once, but over time you will find
flaws with that implementation (I can 100% guarnatee that). As you
find the flaws, you'll have to investigate them and fix them. In
addition, other parts of the kernel change, and some of those changes,
though innocent looking, can have a big impact on how you implemented
the dual UTC UTC-SLS offset.

By way of illustration, in FreeBSD 2.2, the timing implementation was
changed from keeping the current time, to keeping an uptime plus a
boot time. Adjustments to the boot time were used to accomplish phase
shifts in the system time. Unbeknownst to the person implementing
this, despite him having integrated the Mills kernel NTP portion into
a prior version of FreeBSD, this broke the exact semantics of system
time around the leap second. It took years for someone (me) to notice
and fix this problem.

: I also fully appreciate that the existing *interface* between
: kernel-level clock drivers and user-level NTP clients and servers is by
: far not as well specified as it could be. With all due respect to its
: author, I do not hope that RFC 1589 will not remain the last word on
: clock-driver interfaces. A detailed proposal for a new standard on that
: area should help to smooth the process of getting the above right. I
: think a serious clock-controlling API this is what some people have been
: asking for for a long time from POSIX.

In order to implement your UTC-SLS proposal, it must change.

: I believe it is good engineering practice to specify the functionality
: before the interface and implementation, therefore I would like to
: discuss aspects of desired functionality (including UTC-SLS) before
: starting to work on a proposed successor to adjtimex(), ntp_adjtime(),
: etc.

While I agree in principle, I can tell you as one who has bloodied his
knuckles on implementing timekeeping that what you are saying sounds
hard to get pedantically right.

: I am not claiming that the spec-writing job is finished, or even half
: finished yet. I see a replacement for RFC 1589 etc. as the next job on
: the agenda before UTC-SLS (and lots of other time API ideas floating
: around here and elsewhere) can start to fly.

Unfortunately, it makes it hard to evaluate your proposal in the
absense of a concrete spec. What is there now sounds nice, but it
still strikes me as difficult to implement.

Warner
Received on Thu Jan 19 2006 - 13:19:51 PST