We are pondering two somewhat significant and interesting changes to the
kernel clock (RTC and softclock) handling in the current NetBSD, and would
like to get suggestions and opinions on our ideas.  Credit for the idea
in the first topic goes to Kevin Braunsdorf; I have been working on the
second idea.

1. User-kernel interface to clocks

We propose that time discovery and manipulation at the user level be
directed through a new pseudo-device, /dev/clock.  Time would be read
and set with the familiar and common device interface mechanism.  The
system calls gettimeofday and settimeofday would be moved to one of
the libraries and re-written to use the device (this means two fewer
system calls!).  ioctl()s on the device would be used to get/set
clock behavioral parameters (such as those described in part 2).

/dev/clock could be owner root, group kmem, mode 664, so that users in
group kmem could set the time without being root.  This would allow
system time daemons to run non-root, if that is important to a system
administrator.

It is our suggestion that most RTC and softclock handling be moved
"under the umbrella" of the new clock device.  This might have the
side effect of making future changes and improvements to clock code
simpler.

This proposal does not resolve the RTC/softclock synchronization issue
presented by David Burren six weeks ago, but does suggest where such
a mechanism would be located and how it could be manipulated from user
level.  We have also not addressed how the rest of the kernel would
continue to access the softclock is an open issue; there are a few
possibilities.

This change would affect at least a dozen source files in the kernel
code, a few of them perhaps going away.


2. Softclock stability/accuracy improvements

As suggested by Mills [Mills92, Section 5 and Appendix G; Mills93], we
propose the addition of a phase-lock loop mechanism to automatically
adapt the softclock time keeping to the frequency offset of a machine.
The adjtime() interface is a coarse manual control mechanism--a daemon
needs to be constantly present and setting the time to maintain accuracy
in the softclock.  The phase-lock loop, implemented in software, learns
the frequency offset of a machine's clock and adapts the time update
(in the hardclock() routine) to maintain accuracy.

We are soon to be testing such a mechanism here.  The phase-lock loop first
converges in about 16 minutes, overshoots slightly, then settles down in a
few hours.  With xntpd, we could maintain time accuracy on the order of
10-20 ms.  With the phase-lock loop code we expect accuracy on the order
of hundreds of microseconds.

Some entity outside the kernel is expected to provide semi-regular updates,
at least during the initial training period.  However, if updates stop,
the clock coasts along with the last determined frequency offset, with
very little time error for several days.  If no updates are ever provided,
the behavior is identical to what currently exists; behavior is backward
compatible by default.  Note that this is NOT part of the Network Time
Protocol, but rather a mechanism that NTP daemons also use to provide
stable timekeeping.

There are about 10 new kernel variables that are managed by an external
entity and/or the phase-lock loop algorithm.  These could be easily
manipulated via the device control mechanism, as outlined above.  About
four current kernel variables could be deprecated.  We also suggest
deprecation of the adjtime() call in favor of the new system (adjtime()
is only used by timed in the current source).  timed can be modified
to use the new system with a compatibility interface (though we do not
recommend the use of timed for time synchronization).


Both these documents are available by anonymous ftp to
louie.udel.edu:/pub/ntp/doc
    [Mills92] David Mills. RFC 1305: Network Time Protocol, version 3.
    [Mills93] David Mills. Precision Timekeeping... (fine.ps)


Thanks,
Christopher Kane
kane@cs.purdue.edu

This work is not associated in any way with the Purdue Dept. of Computer
Sciences, nor any other University Department, nor is it officially
sanctioned by or part of work supported by Purdue University.

------------------------------------------------------------------------------