Steve wrote: > There is nothing common about the use of ntp-wait. So I don't understand > why it is being referred to as a "BCP".
Because it is Best *Current* Practice. > Bruce wrote: > > Those times apply *after* enough samples have been gathered for > > an offset estimate, which happens *after* a system peer has been > > selected. That can take many minutes. With ntp-wait, the boot sequence > > would be effectively stalled for the duration. > > There is no need to use ntp-wait. > > Use sntp. > > Use a separate 'ntpd -gq' invocation. Why? These are separate issues. ntp-wait will block until leap != 11, which means that ntpd is satisfied that it has a sufficient understanding of time sync that steps should not be needed and timekeeping is on its way to stability. ntp-wait can be used to wait until this is true, at which time it is considered safe to start things like database servers and dovecot. If you are not running any of these sort of services there is no need to run ntp-wait. > > 2. your estimate of "fully sync'd in 11 seconds' time" seemed > > overly optimistic (and still does, even with minimum polling times and > > maximum slew rate). > > The 11 second figure applies to the initial setting of the clock with > 'ntpd -gq' (which is analogous to the use of ntpdate for the same > purpose) and not to disciplining the clock to maximum stability. I'm not gonna dig deeply into that one, but I will say that I remember seeing similar values for "delay" when using ntp-wait. It would be instructive to test and document these things more thoroughly. H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
