Pivoting

[Achim Gratz]

> How do you decide whether to reject it or pivot it into the future?

That's the thing: you can't do it in the general case.

> I know about three pivots to consider.  One is GPS 10 bits for weeks with a
> 20 year step size.  Another is 2 digit year numbers with a 100 year step
> size.  The third is 32 bits of seconds in NTP packets with a 136 year step
> size.  Are there any others I've overlooked?

Let's consider them seperately.  Limitations in primary clock sources 
are one thing, the more important case is cold startup.  The two become 
quite entangled for a stratum-1 of course, but running a server rather 
than a client increases the chances of some actual person getting 
involved.  If you indeed know the overflow cycles, then you can make the 
reconciliation timespan much longer than each individual one if the 
offsets and periods are relatively prime.

> If we want our software to last more than 20 years while talking to crappy
> GPS receivers, we need a way to update the pivot date at run time.  (I'm
> using "last" to mean without rebuilding.)

Look at what gets done for leap seconds.  However (again), this is not a 
problem at all for a running NTP server with a tiny bit of care in 
interpreting the input (which should never be fully trusted anyway).

> If we want our software to reject bogus time, we have to balance the tradeoff
> between long life and good filtering.  Run time parameters will allow the
> user to choose.

I don't think the user will be able to chose anything except tell 
whether the time is good or not _if_ he gets involved.

> It would be interesting to see what those setups are actually doing and if
> they have documentation for something as obscure as NTP.

None of that is networked to the interwebs or anything like that.

> There is a lot of lab gear running embedded software.  I wonder how much of
> it will be running at its 25th or 50th birthday.  I have a pre-software scope
> that's over 35 years old.

We have measurement systems still in active use in our lab bought in 
1993 that had a positively ancient embedded system software on them at 
that time already.  It's also never seen an update since.  I'm not sure 
I can tease out the build date for the software, but since it uses NFS 
I'd say it's some 28 years old.  These _are_ networked, since otherwise 
we'd have to exchange data via 3 1/2" floppy disks.

> The combination of long life and crappy GPS seems obscure enough that I'm
> willing to document it as a limitation.  It's the kind of code that Eric
> would love to rip out if he found it a year ago.

In any case resolving this really belongs into the drivers, not the main 
ntpd code.  I've long been convinced that the clock drivers should be 
able to tell ntpd how sure they are about the data they report and ntpd 
should be able to tell them what it thinks about the correctness of the 
data in some fashion as well.

> The documentation issue gets interesting.  A feature isn't any good if you
> can't figure out how to use it.  I wonder if the web will solve that problem.
>   Will NTPsec still be online 20 years from now?  Will we maintain online
> versions of 20 year old releases?

I have saved plenty of links to documentation over time that are now 
dead.  Some of them can be revived using the Wayback archive, but not 
all.  So yes, this is a concern, however it may be out of scope for the 
project at least at the moment.

> Would anybody notice a warning message from a program that's been running for
> 19 years?

No, but if it was a time server that systems still followed, it'd take 
your network down quite fast these days.  Figuring out why would be a 
minor nightmare.


-- 
Achim.

(on the road :-)