>>> In article <[EMAIL PROTECTED]>, David Woolley <[EMAIL PROTECTED]> writes:
David> I don't think you are ever going to get rid of ntpdate from the David> distribution (as supplied by packagers and vendors) until ntpd offers David> a mode which sets the time within about one second of being started. The current sntp code can do this now. David> I'm not convinced that SNTP will displace ntpdate for this purpose. Why not? David> People don't want to delay boot sequences, but they also don't want David> to start applications until the time has been set. Then I submit you are focusing a bit too deeply on the details and invite you to take a step back. I believe the current set of tools can be used in a variety of combinations that will handle the various cases to the best that we know how to do them. If you want to get the time set *now* and then start, regardless of how well the system can maintain that time, we can do that (sntp/ntpdate+ntpd). If you want to set the time ASAP and have stable system time before starting your apps, in the usual case you are talking about 11 seconds for this to happen (ntpd -g, with iburst, early in the boot sequence, using ntp-wait later in the boot sequence, just before starting time-critical services). Near as I can recall, any other cases have looser constraints so they're not particularly interesting for this conversation. -- Harlan Stenn <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
