On 2007-May-08 15:33:51 +0200, Martin Dieringer <[EMAIL PROTECTED]> wrote: ># cat /var/db/ntp.drift >500.000 >#
There seems to be a bug in ntpd where the PLL can saturate at +/-500ppm and will not recover. This problem seems too occur mostly where the reference servers have lots of jitter (ie a fairly congested link to them). The recovery action I've used is: - Kill ntpd # /etc/rc.d/ntpd stop - Delete the existing drift file # rm /var/db/ntp.drift - Reset the kernel PLL # ntptime -f 0 - Reset the system time # /etc/rc.d/ntpdate forcestart - Restart ntpd # /etc/rc.d/ntpd start At this point, ntpd will need to recalibrate itself - which can take anything from a couple of hours to a day or more, depending on the accuracy of your system clock. During this time, your system needs to be online. In my experience, ntpd also does not recover from having its own IP address change. My work-around is to restart NTP within my dhclient configuration if the address changes. You may also be able to configure your system so that ntpd attaches to an interface with a fixed address and the NTP packets are then NAT'd to the servers (though this will add jitter due to the additional processing). -- Peter Jeremy
pgpJEPlEZfjXb.pgp
Description: PGP signature