clock problem

Peter Jeremy peterjeremy at optushome.com.au
Tue May 8 19:16:19 UTC 2007


On 2007-May-08 15:33:51 +0200, Martin Dieringer <martin.dieringer at gmx.de> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070508/c16a8eae/attachment.pgp


More information about the freebsd-stable mailing list