On 2007-04-12, RICCARDO <[EMAIL PROTECTED]> wrote: > Thanks for your exhaustive explanation but I have also one doubt:
You're making this issue quite a bit more difficult than it needs to be. As I, and others, have stated in this thread, the best way to keep your clock synchronized on an ongoing basis is to just run ntpd (as the daemon it is intended to be). > If for example I used in cron "ntpdate -c server1 server2" '-c' is not a valid ntpdate option according to the distribution documentation at http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html > (without taking accuracy but only convergence time) and local clock > was different from NTP server time for 60 seconds, ntpdate will step > time taking several hours ! If the clock offset is greater than 0.5 seconds (as in the ntpdate manual which _you_ quoted below) the clock will be stepped unless you use '-B' to force a slew. Steps are virtually instantaneous. > How can it destructive ? Time will not adjust in few seconds but in > several hours, I think. Unless you deliberately change the default behavior of ntpd (or ntpdate) an offset of more than 128ms (or 0.128 sec) will be stepped. > Ntpd -qg with this time difference has the same behavior. Do you agree > with me ? ntpd -gq will step the clock if the offset is greater than 128ms (or 0.128 sec). > See following reference of ntpdate manual: > > If ntpdate determines the clock is in error more than 0.5 second > it will simply step the time by calling the system settimeofday() > routine. If the error is less than 0.5 seconds, it will slew the time > by calling the system adjtime() routine This refutes some of your statements above. Why don't you just run ntpd as a daemon and be done with this? -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://ntp.isc.org/ _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
