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

David L. Mills mills at udel.edu
Sat Jan 24 04:42:03 UTC 2004


I suspect you might have missed a previous message. Even if NTP steps
the clock, it does not set it directly; the only operations allowed are
to add or subtract something from the current time. Therefore, ntpd -g
does have the same overflow problem whether or not the clock is nudged,
stepped or stirred. Yes, I know deep down under the hood the actual time
is handed off to Unix, but we don't allow customers to see that.

The primary motive for this design is that rollovers are transparent as
long as you keep track of the hidden bits or reconstruct them from the
file system. I need to say a few more words about that, but better said
in an update of the web pages.


Terje Mathisen wrote:
> 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
> --
> - <Terje.Mathisen at hda.hydro.com>
> "almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list