On Wed, 07 Dec 2011 07:30:12 +0000, Harlan Stenn wrote: > I'm saying I'm not aware of good reasons to set the clock before > starting ntpd at system startup. [...] > With a good drift file and a proper ntp.conf file, ntpd will have the > clock fully sync'd in about 11 seconds' time.
Of 18 computers here currently running ntpd, 11 do not have stable frequency offset across a reboot (i.e. a drift file is not useful at system startup for those machines). The remaining 7 machines do have stable frequency offset across a reboot except in the case of a kernel update, which does sometimes cause a change in frequency offset even in those machines. Four of the machines are not normally on-line; they are running as a testbed for a distribution update which is being rolled out, and one of those four is one of the ones with a stable frequency offset (so the normal numbers are 14 computers running ntpd, 8 of which do not have a stable frequency offset across a reboot). Motherboard/BIOS design seems to have the biggest impact on frequency offset stability across a reboot (four of the seven machines with stable frequency offsets are of a single motherboard design). Ntpd version is a modified 4.2.6p4. I do run sntp to set the clock before starting ntpd (so I don't need ntpdate). Setting the clock this way at least gets the time offset in the ballpark before ntpd starts. Also, I have not seen machines "fully sync'd" in anywhere near as quickly as 11 seconds, but my interpretation of "fully sync'd" may differ from yours; I consider a machine "fully sync'd" only when time offset, frequency offset, and jitter (as reported in loopstats) have all stabilized, which may take a few hours. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
