lockclock

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> 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.

Confirmed, this matches my analysis from about 18 months ago.

> 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.

Heh.  I've been pretty ruthless about dropping every line of code I could.  Did
it occur to you to wonder why I hadn't already nuked this?

It's because the only way this code makes any sense to me is if at one
point NIST was running NTP Classic on the master fountain clock. For all
we know they might still be doing that.

This is an NTPsec use case we *absolutely* want to encourage.  What better
reference user could we have?

So, yes, we're going to support that (unless Mark knows some compelling
reason we shouldn't, which I doubt). If NIST comes asking us for help
we want to be able to say "Yes, *sir*.  At your service, *sir*."
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.