[ntp:questions] Re: NTP, Unix and the 34-year itch (better read this)

Terje Mathisen terje.mathisen at hda.hydro.com
Sat Jan 24 02:05:54 UTC 2004

David L. Mills wrote:

> Terje,
> Curious. NTP internally has no dependence on Julian day numbers at all.
> I'm sure you have seen the page I've been yakking about
> www.eecis.udel.edu/~mills/y2k.html. It suggests a method similar to the
> last one you mention.
> There's a bit of overlooked principle here, one motivated by the need
> perceived in the theory community, to make strong correctness assertions
> about the time. According to these principles NTP never sets the time,

This principle is (or should be?) relaxed for the initial big step, at 
least when 'ntpd -g' is used.

> only adds or subtracts values from the current time. This was done for,
> among other reasons, that rollovers become transparent and you don't
> have to worry about them as long as the four most recent timestamps are
> struck in the same era.
> Boiled down to essentials, the assertions worked out several years ago
> in a meeting in beautiful southern Germany, NTP never knows the time,
> just an amount less than 68 years to add or subtract from the apparent
> current time. However, there has to be a way to set the real current
> time within an interval assumed correct, in this case less than 34 years
> from UTC to avoid overflow. Once this is done NTP can maintain the time
> without ambiguity unless it is banned on an island and put to sleep for
> 34 years.
> You've got me thinking again about the roll issues. We should be able to
> compute from the origin of the Julian ers, 1.5 January 4713 to the death
> of the universe using only the additive group modulo 68 years and
> survive rollover while needing nothing except a reliable timestamp
> within 68 years of the current time.

Sure, that's obviously right: As long as you can get the local clock 
into the right epoch/window, ntp differences is all you need.

I'm suggesting that in the case of ntpd -g (the ntpdate replacement), 
where the clock is indeed set instead of adjusted, the full 136 year 
epoch can be used, not just 1/2 or 1/4 of it.

- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list