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 :-) _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
