[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