NTP problems

Matthew Seaman m.seaman at infracaninophile.co.uk
Sat Jul 19 13:09:25 BST 2003


--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 19, 2003 at 11:18:41AM +0100, Gavin Davenport wrote:
> I'm doing that - every 10 minutes
>=20
> By which time the clock reset is ~ -174 seconds.
>=20
> Any idea why the system clock has gone so bananas ???
>=20
> -----Original Message-----
> From: Peter McGarvey [mailto:fbsd-x at packet.org.uk]
> Sent: 19 July 2003 11:14
> To: Gavin Davenport
> Cc: freebsd-users at uk.freebsd.org
> Subject: Re: NTP problems
>=20
>=20
> Hmmm, if all you want to do is keep your clock correct, and (as included
> config mentions) you've got a timeserver nearby, why not simply add
>=20
>     ntpdate ntp
>=20
> in /etc/crontab?

Where does this pernicious idea that running ntpdate(8) out of cron is
such a good way to keep a clock in synch come from?  It isn't much
good at all -- the only time it was ever worth doing is when the
client machine was behind a dialup link and it was more important to
control when the line was bought up than it was to keep the clock in
synch.

ntpd(8) automatically checks against the remote servers at intervals,
which it can change as required.  It also knows how to compare the
trend in recorded time of day of the local clock against the network
time.  That means that it sets the clock to run faster or slower and
so come into line, rather than jumping the clock to whatever happens
to be the correct time at that instant, and never mind that the local
clock is running at 55 minutes to the hour.

All of this takes time: you need to allow ntpd(8) at least 24h and
preferably longer before you can tell if it is managing to keep your
clock properly in synch.  Add the line:

    driftfile   /var/ntp/ntp.drift

to your ntp.conf(5) and ntpd(8) will keep a record of how fast or slow
your clock tends to run, which will let it get back into synch faster
after a reboot.  Even so it will take many hours to get everything
settled down properly.

The one and only time that you should call ntpdate(8) to step the
clock is on reboot, to ensure that the time of day is sufficiently
close to reality the ntpd(8) can hope to coax it into line.

Trying to combine ntpd(8) and calling ntpdate(8) from cron(8) is a
recipe for disaster.  They will fight against each other and the clock
will become less stable than before.

If, despite all that, ntpd(8) can't manage to keep your system clock
in synch then:

     a) make sure you're using ntp servers that are providing you with
        a stable time source --- if you configure ntp to use at least
        three external time sources, it can tell if one of them goes
        out of whack and ignore it until it comes back into line.

        See http://www.eecis.udel.edu/~mills/ntp/clock2a.html for a
        list of publically accessible servers you can arrange to use.

     b) Start worrying about hardware problems on your own system.=20


	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/GTT1dtESqEQa7a0RAloMAJ9lCB9o/c1+aRqaklAO7iLsel4oSQCffSah
TtAoVSdye8mliBpugq5j2eU=
=/uhn
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--




More information about the Ukfreebsd mailing list