What he wants is "tinker panic 0" - see man ntp.conf Allows a slew below the threshold, and a step at anything over, no matter how great - works well as long as you are not doing sophisticated DB stuff (rollbacks).
I am concerned about the rtc error: try ... bunyip ~ # ls -al /dev/rtc* crw------- 1 root root 10, 135 Jan 1 15:54 /dev/rtc bunyip ~ # If no rtc node you need to investigate the kernel options and/or loading of the relevant module - the options are confusing. BillK -----Original Message----- From: Jarry <mr.ja...@gmail.com> Reply-to: gentoo-user@lists.gentoo.org To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] ntpd crashing Date: Tue, 10 Jan 2012 22:42:07 +0100 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
