Pivoting
Hal Murray
hmurray at megapathdsl.net
Thu Apr 20 21:57:53 UTC 2017
We need a web page that summarizes this area - not the internal details, but
the general problem and how it impacts users.
NTP overflows in 2036
32 bit signed time_t overflows in 2038
GPS overflows every 1024 weeks (~20 years starting from 1980)
First rollover was 22 August 1999
They added 3 bits in ???
Some older devices used pivot logic to extend their lifetime past 2000
A description of pivoting and how it works.
Maybe mention the distro reproducible problem and __DATE__
Good URLs for more info
--------
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.
--------
We need to verify that ntpdig does something sane.
As long as we are cleaning up this area...
32 bits of seconds spans 136 years. ntpd panics if it is about to step the
clock more than 900 seconds. There is a startup switch to bypass that and
allow one long jump.
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.
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.
--
These are my opinions. I hate spam.
More information about the devel
mailing list