[ntp:questions] Re: NTP miss-information

Terje Mathisen terje.mathisen at hda.hydro.com
Wed Feb 2 07:41:16 UTC 2005


David L. Mills wrote:

> Alain,
> 
> At the NTP project page www.eecis.udel.edu/~mills/ntp.html you can find 
> a number of white papers on generic NTP issues, including the timescale, 
> rollover, leapsecond and other arcane issues. In fact, while the NTP 
> timestamp does roll over in 2036, the computer clock time will <<not>> 
> be affected. You might have some trouble believing that, but see the 
> paper and analyze for yourself.
> 
> Dave
> 
> Alain wrote:
> 
>> Steve Gibson says in
>>
>> http://www.grc.com/port_123.htm
>> ----------   The network time protocol is a clean, simple, 
>> lightweight, and efficient protocol allowing clients to query servers 
>> for the current time (including the date). The only glitch is that the 
>> 64-bit NTP time value will overflow (suddenly go back to zero) in 
>> early February (the 6th or 7th, no one seems to be sure which) in the 
>> year 2036. I plan to be relaxing on a beach somewhere on that day.

Dave is of course correct. :-)

The key idea which Gibson have missed is that NTP when running uses only 
differences between (unsigned) 64-bit numbers, and these differences 
will almost always be less than 1/100 of a second, which corresponds to 
a fixed-point (signed) 64-bit number in 32:32 format, with 38+ leading 
zero bits.

So what happens during the big rollover?

Nothing much, even if one timestamp was taken before the rollover , and 
the next just after: Subtracting (or adding) two unsigned values is very 
well defined in the C standard, even when we're working around the 
rollover point:

It will simply return the actual difference, which is required to be the 
same as you would have gotten if you had more significant bits and no 
rollover had happened.

Anyway, after you have the (small) differences, you can then calculate 
how much your local clock is behind or in front of the reference clock, 
and then use this sto slightly increase or decrease the speed of the 
local clock, so that it will catch up.

At no point in all of this is absolute time values ever used!

Terje

PS. There are some possible problem spots related to initial startup, 
but that's not really relevant when considering the rolloever behaviour.
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list