ntp synchronisation failed

[Corné Beerse]

T. Nifty Hat Mitchell wrote:
 >>>>>>>>>>previous stuff removed <<<<<<<<<<
> 
> 
> 
> Yes the way that the current scripts start the ntp time daemon might
> be improved.  I expect when ntpdate is eventually removed the change
> will take place.

Better not remove ntpdate, or at least not remove its functionallity at boot 
time. By default, ntpd never sets the clock and never adjusts anything if the 
offset is to large (more than a minute or so). At boot time, it is accepted to 
set the clock instead of skewing into time. Hence newer ntpd-implementations 
have an option to do this.

Specially if the system can be off for multiple hours or (even worce) if it runs 
an other OS like M$Windows, the hardwareclock and the drift will not be enough 
to start on a reasonable time.

> 
> I spent a little time looking at it a year or so back and the standard
> pair of redhat time servers seem to be overloaded enough that the
> initial connections always time out and a RED FAIL was just too common
> for me.  I looked for closer and more reliable time servers.
> 
> It really does help to exchange keys with other Linux friends and as a 
> group get connected to a pair of near by level one or two hosts depending
> on how large the group is.
> 
> If your ISP does not document a NTP time host ask.
> 
> NTP is such a high quality service that a pair of level 3 servers will
> provide exceedingly good time of day references.
> 
> Of interest there is a multicast/broadcast ntp protocol.  Opening the
> firewall to this port might find the service already active.
> 
> 
>