[ntp:questions] Synchronize clocks without a reference clock
David L. Mills
mills at udel.edu
Fri Mar 23 02:06:38 UTC 2007
I should correct a couple of misconceptions here.
First, the 500-PPM limit is imposed on the inherent hardware oscillator
frequency error. Should this be exceeded, ntpd continues to discipline
the clock, but it will not be able to reduce the residual offset to
The 15-PPM dispersion increase is a compromise. The computing theory
guys say that it should be 500 PPM, since under extreme conditions at
initial start, that could be the case. A more practical case is to set
it some ten times what is commonly observed with disciplined
oscillators. I take this to be nominal 1.5 PPM, which is near the
extreme commonly observed.
All the sticky constants, including the 15-PPM, can be tinkered. Anyone
would be nuts to change the 15-PPM, since it allows all clients to have
a consistent dispersion as each server gets older. If it is changed, it
sould be changed for all servers in the subnet.
Harlan Stenn wrote:
>>>>In article <45fe723f$0$69886$e4fe514c at news.xs4all.nl>, "Maarten Wiltink" <maarten at kittensandcats.net> writes:
>>>Does this mean that the maximum rate of change is 15 µs per second?
> Maarten> No, that's something else, probably the worst-case estimate for how
> Maarten> fast synchronisation deteriorates between server polls. But that's
> Maarten> no more than a guess.
> Maarten> The number I mean is the 500PPM cap on the observed drift that NTP
> Maarten> will accept before giving up. You can't change that without
> Maarten> recompiling, IIAMN.
> You can't change that without rewriting the code to handle the algorithmic
> The current algorithms are designed to work in an environment where the
> clock source is correct to within 500ppm. If you want a wider range you
> will need to do *serious* work on the algorithms and then rewrite the code
> to use those new algorithms.
More information about the questions