lockclock

[Hal Murray]

Context is Issue #524, NTPsec daemon hangs after startup

The problem is that if configured with --enable-lockclock, ntpd doesn't work 
as a server if you don't activate the local clock driver in your ntp.conf.  
(It doesn't work as a client either.)

-----------

There isn't any NTP documentation on lockclock or how to run a server in 
lockclock mode.  Google finds that lockclock is an NIST algorithm, one of 3.  
The stuff I was looking at was pre-web, no links.  I didn't try very hard - 
the NIST web site is in shutdown mode.

Here is what I think is going on...  (from reading the comments in our code)

The basic idea is to trust the system time.

The local clock driver uses ntp_adjtime to get the status of the system clock: 
OK, bad, leaping...  If bad, it reports bad time which disables the server.

The loop filter is setup to never change the system time.  It watches the 
other servers specified in ntp.conf and declares itself dead if the local 
clock is not within the surviving clocks.

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

I think we have 3 choices.

1) Drop it.

2) Support it.  That includes documentation and testing.  We could do testing 
by building a version of ntpd that use another port but otherwise did 
everything ntpd does.  That would free up port 123 so we could run a lockclock 
mode server there.

3) Kludge things.  I'm not sure what to do.  I'm thinking of things like 
change --enable-lockclock to --enable-lockclock-and-I-know-what-I'm-doing 
and/or add a trap to make sure you have setup the local clock if built with 
ENABLE_LOCKCLOCK.

I vote for dropping it.  We can put things back together if we find a customer 
who wants it.



-- 
These are my opinions.  I hate spam.