Am 10.01.2012 22:42, schrieb Jarry: > On 10-Jan-12 22:18, Florian Philipp wrote: > >>> Wouldn't it make more sense to get the clock set correctly on bootup >>> with ntpdate, and then have ntpd keep things in line moving forward? >>> Otherwise, every couple hours, you'd have your cron'd ntpddate jumping >>> the clock around. I've had apps get stuck in infinite loops from >>> retrograde clocks, and having it happen at the wrong time during a >>> compile process has its own context-sensitive consequences. >>> >> >> It depends on how bad your clock is. If the skew is too large, ntpd >> cannot keep up, even if you initially set it to the correct time. If >> your clock is too good and doesn't drift, you can just forget ntpd and >> save the RAM for something you actually need. > > "step threshold" is 0.128s if default settings for ntpd are used. > If time difference is less, time is corrected using "slewing" > (depending on kernel settings, in my case +/- 0.5ms per second). > If it is more, "stepping" is used instead. > > So there is no way ndpd could not keep up. But changing time > with "stepping" might cause problems for some applications > (i.e. dovecot in some previous versions just died). If ntpd > is configured with "tinker step 0", step adjustments never > occur. But if clock is off more than 0.5ms/s, time gets never > synchronised and deviation will keep increasing... > > Jarry >
I can't find the counter example I had in mind on the archive now. Since your explanation sounds sensible, I guess that in that other thread some configuration issue was also involved or ntpd simply took too long to skew back to correct time (as the man-page states, this might take 2000s per second difference). Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
