Stromeko at Nexgo.DE
Fri Apr 21 08:26:36 UTC 2017
> 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
> 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.
> 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.
(on the road :-)
More information about the devel