"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.
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?
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.
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.
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.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Thu Jan 19 2006 - 12:22:55 PST