At 12:48 PM +0400 5/13/08, Eugene wrote:
Hello,
From: "Quentin Garnier" cube@cubidou.net
I'm not the one having trouble reading, here. The proper way to start a system is to run ntp*date* (as early as possible) and then ntpd.
That's what you say, and it is far from being officially accepted.
There is nothing 'official' in regards to how you start up your system that should carry more influence than having it start up correctly.
NTP project clearly deprecates ntpdate for several reasons.
I think that is an incorrect statement, and to the degree that it is correct, it still does not mean that it is reasonable to have an unstable clock.
The practice of running ntpdate as a cron job rather than a ntp daemon certainly is deprecated and always has been, but even that is not so much because of how well it works (on most systems it is perfectly functional) but rather because it does not scale across the net: the public NTP infrastructure gets what Dr. Mills calls "little fireballs of congestion" as the cron jobs fire, and that has bad impacts on everyone's NTP-based time accuracy.
On the other hand, ntpdate run once at boot still serves a purpose, even if you are running the latest ntpd with the initial stepping functionality rolled in and enabled, and it is helpful to note Per Hedeland's succinct and practical counterpoint in the FAQ immediately following Dr. Mills' long explanation of the various edge cases involved in choosing when to step and when not to.
In addition, "the clock should not be stepped until a consistent offset has been observed for a sanity interval, currently 15 minutes". So ntpd may in principle step time again. http://www.ntp.org/ntpfaq/NTP-s-config.htm
You are misreading and/or misrepresenting the context of the piece you quote. A good NTP daemon is properly quite conservative about stepping the clock at times *other than* at boot, and should take precautions against trusting clocks that seem wrong once it has what should be a trustworthy synchronization and characterization of its own local clock.
--
Bill Cole
bill@scconsult.com