[ntp:questions] ntpd (4.2.2p1) stays "synchronized to LOCAL"
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Dec 5 15:17:54 UTC 2006
Jon Kåre Hellan wrote:
> david at djwhome.demon.co.uk (David Woolley) writes:
>
>
>>In article <tLadnW4n2o3aQOnYnZ2dnUVZ_qqdnZ2d at comcast.com>,
>>This also raises the question of why the local clock was configured
>>in the first place. If it had not been, ntpd would have correctly
>>detected that it was in a hopeless situation and would have reported
>>unsynchronised and eventually shut down. In my view, most people shouldn't
>>configure the local clock, and those that do should have thought carefully
>>about it.
>
>
> Under what circumstances *should* the local clock be configured?
>
Normally the local clock is configured only when the system is serving
time to other systems and must continue to do so even if it loses its
connection to its upstream servers.
It is definitely a clock of last resort; if it were any good at all, why
would you bother running ntpd??? If ntpd had the clock synchronized
you have anywhere from a few minutes to a few hours of "holdover" during
which the time is still close to being correct. In most cases a few
very definitely means VERY few. If the temperature is tightly
controlled, clock drift should be minimal, if not, the clock will start
drifting as soon as the temperature changes.
A lot of people seem to want to use the local clock to synchronize
clocks in an isolated network. This can be made to work if you don't
really care about having the correct time and don't need really tight
synchronization.
More information about the questions
mailing list