[EMAIL PROTECTED] (Mohit Aron) writes: >> The best solution to this mess was to deprecate ntpdate, once there was a >> way to provide all of the intended *and assumed* functionality of ntpdate >> by >> some other way. >> >> The first set was removing the need to set the time with ntpdate before >> starting ntpd. The solution to this problem is -g, and perhaps calling >> ntp-wait (which actually implemented a missing feature that had been needed >> before). >>
>I don't think '-g' option to ntpd is a practical solution - since it takes >way too long to set the local time. Given this, people will continue to use >ntpdate or sntp to set the time in a one-shot way before actually running >ntpd. No, it sets it fast. As long as the computer clock is way off. If the computer clock is "almost OK" then problems arise. There is absolutely no reason why ntp should take as long as it does to set the time. But that will bring up the whole issue of chrony ( whichoperated much more raplidly) and ntp algorithms. With the decision to use a Markovian technique to discipline the clock, ntpd is probably the best you can do. >> There will be a script called "ntpdate" for those folks who want to keep >> running a program by that name. >> >That will be great. It'll also be super if the ntpd man page can be fixed so >it doesn't say ntpdate is to be retired and that 'ntpd -q' is an alternative >to using ntpdate. This is spreading a lot of misinformation and causing >waste of time. My company changed all the configs in our product to use >'ntpd -q', only to realize the hard way that it is way slower than 'ntpdate' >and then we had to revert back. >- Mohit _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
