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
--
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.
