[ntp:hackers] ntpd: step_systime() and the years 2036 / 2038

juergen perlinger juergen.perlinger at t-online.de
Mon Aug 15 23:33:32 UTC 2011


On 08/15/2011 10:25 PM, Terje Mathisen wrote:
> juergen perlinger wrote:
>> Hi everyone,
>>
>> following a discussion with Dave Hart I spent some time on the problem
>> of the NTP era/epoch change in 2036. I came up with a rather simple
>> solution in 'step_systime()' that would make sure that the resulting
>> system time after the step would be between 1970 and 2106.
>
> Afaik ntpd already has code like this, effectively making sure that
> the epoch number is the one that minimizes the distance from the
> current system clock.
>
Well, implicitly it does exactly this, by having an 'l_fp' type where we
have exactly 2^32 seconds.
This is the point, really. If we are in [-2^31 .. 2^31[ seconds around
the true time (for a given value of true) then everything is fine.
Otherwise you could be warped into an area where you never expected to
appear.
> This means that you must simply make sure that a system's local clock
> is within 2^31 seconds from the true time before you start ntpd.
Yes. It might just be not that simple. But we can make sure that even
this requirement is not needed for the times between 1970 and 2106, by
adding a constraint when expanding the l_fp value to a full (that is,
not truncated to mod 2^32) value. It would avoid any attempts to set the
time before the begin of the UNIX epoch, which are either
a) likely to fail  (but that would not help us much)  or
b) bound to warp us to a system time that is surely wrong (which is IMHO
even worse)

One reason for honing in on this is that some systems (embedded stuff,
mostly) come up with system times values that are gross off-time when
they start. And since IMHO adding the necessary constraints for the next
~95 years is easy... We could even use the __DATE__ and __TIME__ macros
to get the compile time and never let us warp back further than this
time. (Perhaps minus some safety margin, like 10 years or so). This
would make sure that a specific binary would be good for a very long
time, no matter what the system clock actually shows. There are some
more aspects to this, so using  __DATE__ might not be a good idea in the
long run, but it would be possible.

And yes, there is a pitfall: If we are less than n * 2^32sec +/- 128msec
off the true time, we will not jump and have a happy life in the wrong
NTP epoch. This happens every 136 years, for a quarter of a second,
assuming that ntpd locks fast enough to not require a step after
startup. I think I could live with that.

To remove even this possibility, we would have to expand all l_fp's to a
wider type and do all offset calculations with more than 32 bits for the
integer part. *This* is something I won't go into right now, if that's
OK with you :)
>
> The old limit used to be 2^30 seconds maximum offset afair.
I haven't found that yet -- could you give me a hint?
>
> Terje
My conclusion would be: No matter what we do, NTPD works best with less
than 2^31sec offset to the time source(s) on startup. But if we need a
step, we can make sure we don't get sucked through a wormhole into the
other end of the galaxy, and I still think we should do so.

cheers,
    pearly


More information about the hackers mailing list