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.
