[ntp:hackers] Simplifying NTPD

Warner Losh imp at bsdimp.com
Fri Jun 27 15:09:10 UTC 2014


On Jun 27, 2014, at 8:50 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

> 
>  My proposal is to "evict" them to separate processes, so they don't
>  have to touch the rest of ntpd in any other way, than through a
>  simple well defined ASCII/text based protocol.
> 
> I think it would be good to write up the protocol and design first, as
> there are a few subtleties.

The initial protocol design looked good on its surface, but I share this concern.

> I am guessing that the protocol will be spoken over a unix-domain
> socket, usually, or perhaps TCP for systems where that doesn't work.
> So that seems to drive the design to report an offset from the system
> clock observed at some system clock value.

TCP sounded interested, until I realized that you needed to measure against the
system time. Even then it might be quite useful for simulations

> So I wonder if there is any support already for using high-precision
> timers other the system clock, and whether this would require that to be
> duplicated into refclock land.   Arguably people should instead make
> their system clocks use the better hardware, and the refclock should
> just call gettimeofday or use some other systme facility to associate a
> system timestamp with the edge.

Many systems already support high precision timers of various flavors
and capabilities. However, this support usually translates either to a direct
call to that hardware to get the system time, or more typically a call that
returns what can be thought of as a steered “paper” clock that might use
the extra precision hardware to add a bit of extra precision since the last
tick.

Some systems support hardware time stamping of events with the same
clock domain as timer registers so you can directly measure the system time
at the time of PPS. Any ref clock would know this, and in such specialized systems
would likely be implemented in the kernel. Today this is typically implemented
using the classic PPS reporting API. Most private ref-clocks that do that
today wight he RFC2378 facilities, and the ntp ref clock driver is little more than
a hacked ATOMIC refclock (if hacking is even needed: it usually is for the absolute
phase (e.g. initial time)).

> It would be good to explain how this relates to PPS.  Presumably a
> refclock might enable PPS with the RFC2783 facilities, and it would
> either just use the same FD being used for NMEA/etc. (on BSD)  or have
> the local magic to figure out how to find the pps device.   So it seems
> there might be some flag to a refclock that it should enable PPS.

It would be nice if there were a simple library that did this sort of things that
ref clocks could hook into. Or alternatively, if there was some easy way to
specify how the initial phase was set, that might help cut down on the proliferation
of ref clocks. In past systems I’ve worked on, it has always been some ad-hoc affair
here: some waited to report measurements until they got an initial time from a source
of truth. Others waited early in the boot process for this most trusted phase
to come online (usually a GPS receiver starting to spew NMEA or proprietary
time info) before letting the rest of the system start. Both models have their pros
and cons, so one shouldn’t be dictated over the other.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.ntp.org/pipermail/hackers/attachments/20140627/33f29d37/attachment.sig>


More information about the hackers mailing list