Starting ntpd at boot is an extremely poor idea. A much better program is to cold boot a server with ntpdate at boot, followed by a minimum of 72 hours running a "top of the hour" cron job to execute ntpdate 72 times.

After your system has attained its best stabilized temperature and kernel pll levels normalize along with an estimated error of 0.003 or less, then it's time to launch ntpd.

Unless your server is running a GPS reference clock (stratum 1, in other words) and/or has a temperature compensated compartment whose purpose is to stabilize clock chip rates (with the side effect of stabilizing the system time), for the good of the ntp network community sysops should wait until the machine has been running 72 hours and has settled into a predictable pattern of heat generation and dissipation which can be compensated.

If your machine has clock chips so unstable that you are unable to attain 0.003 estimated error, kernel pll lock does not happen, or the frequency of clock and other critical members of the chipset conspire to create an aggregate error that either exceeds the levels established by ntpd configs or results in a clock that moves in unpredictable and uncorrectable ways, your "server" will not even be allowed to connect as a client at most locations where ntpd is run.

Ntpd samples 16 peers in the general network neighborhood. It finds them without operator input. There will be 3 at "stratum 4" which will not be polled. If their clocks have not stabilized within 72 hours some configurations will exclude them. There are peers at stratum 1 (normally 3) along with peers at stratum 2. As your server first joins a group, and particularly if your clock was not stabilized before you connected, you will find that only stratum 2 servers will peer with stratum 3, which is where most machines end up that have not been running at least 15 days.

Bottom line? Fast, fancy new system boards generate lots of heat which degrades the accuracy of your system clock. Let it "burn in" for a good long time before launching an ntpd server.

Thanks for your very helpful comment, Clark. You are absolutely right, running ntpdate in a cronjob is a much better solution. Actually I did that too, somehow I wrote a different method in the post.