Pivoting

[Achim Gratz]

> 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 :-)