I see 4 ways to for ntpd to handle pivoting.
1) The current code does the pivoting at step_systime
2) We could do the pivoting "as soon as possible", when the received packet
arrives. The NTP calculations use 4 time stamps: 2 local, 2 remote. The
local time stamps need to save the timespec used to produce them.
3) We could assume that the system time is "close enough". That turns into
pivoting around "now". That assumes that the system has a sane RTC or
software that does something like get a sane time from the file system.
"close enough" doesn't have to be very close. Within 50 years is good enough.
4) We could add a few lines of code to the initialization of ntpd that jumps
bogus time to some compiled in value. The old way to get that value was
__DATE_ but the last git commit date or something similar from the distro
environment avoids the reproducible problem. This is pivoting around the
build date.
I don't think ntpd needs to do any pivoting _except_ at startup time,
where it is unavoidable and it should attempt to do anything after it
has started up.
For setting the initial time you'll want to have as many independent
bounds on the time as you can provide, since you potentially cannot
trust _any_ of the possible sources. Short of an authoritative and
trusted time that is within about 68 years of the true time, the only
thing you can do is a maximum likelyhood estimate and that always means
that there is a non-zero chance to resolve to the wrong NTP era since
any assumption that you make can turn out to be wrong for any number of
reasons.
We could supplement that sanity check with a pivot check. If we have a build
date, we know the time should be after that build date and less than the life
of the program past that.
One assumption delivering a single bound. The other assumption is that
the system time is already close enough for ntpd to not need to pivot
again. Getting time over HTTPS[*] could deliver a third venue to start
doing a majority vote.
[*] http://phk.freebsd.dk/time/20151129.html
What's a reasonable life of a program like ntpd? 20 years seems like the
right ballpark. After that, we have to check the GPS drivers. The magnovox
driver just checks for before. I haven't checked the NMEA driver. 50 would
be more conservative for IoT type devices. (Many GPS devices lasted long
enough to hit the week roll over bug.) Configure options, both build and
run-time, could help but they would probably be ignored by the few people who
should use them.
Given that there are still PDP8 and VAX systems running production
plants (albeit increasingly as virtual machines), I'd say you vastly
underestimate the longevity of something that is mostly out-of-sight and
"just works". Even if you only consider physical hardware, based on the
projected lifetime of automotive qualified systems (15 years or longer)
you have to expect a much longer actual lifetime in the field.
--
Achim.
(on the road :-)
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel
