[ntp:questions] Re: NTP, Unix and the 34-year itch (better read this)
terje.mathisen at hda.hydro.com
Thu Jan 22 14:14:17 UTC 2004
Hal Murray wrote:
>>Almost all computers of today have some means, such as a time-of-year
>>(TOY) chip, to set the system clock at power up or reboot surely within
>>within 34 years, but some embedded systems do not. For embedded systems
>>without a TOY chip and running an embedded Unix kernel, the initial time
>>is usually the Unix base epoch 1 January 1970. Readers will quickly
>>realize the time since then now in 2004 exceeds the 34-year limit. These
>>systems have a problem unless something is done.
> Another case to consider is the battery running down. That happens
> after a while if the box is not plugged in.
> Another way to get a good starting epoch would be to use the
> build time of the kernel.
Even better, and easier to get for an ntpd deamon:
The build time of the ntpd deamon itself: This will then be good for the
next 34 years, and any system which can run without recompilation for 34
years deserves a _lot_ of respect.
In fact, I suspect such a system will be well-engineered enough to have
a working TOY clock.
Even if the TOY clock breaks (battery stops working after ~5-10 years),
simply demanding that the initial time is >= the build time would suffice.
Alternatively, use the file system level timestamp of the ntpd deamon:
If you're really paranoid/scared, you could run 'touch ntpd' (or a
companion date flag file) as part of the normal shutdown sequence, this
would work for all systems with less than 34 years between reboots.
However, since the 34-year limit is for ntp time differences, a 68 or
even 136 year range should work for ntp absolute times, i.e. ntpdate or
ntpd -g initial time setting.
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
More information about the questions