[ntp:questions] Advice needed - really bad clock drift in OpenBSD

henry cow cow at ax-im.com
Sun Nov 23 03:05:05 UTC 2003


I have recently installed ntp-4.1.74 on a new P4 server with a fresh
install of OpenBSD 3.4.  I'm having major problems with bad clock drift
which I have controlled to a certain extent, but I think I've had to
resort to some very questionable practices, so I'm seeking advice on
what else I might do which would be more elegant and/or correct.

I have never had a problem with NTP before -- I've always just
installed it with a really simple ntp.conf, e.g. just a drift file
location and a couple of servers which I've obtained permission to use. 
Then it's off and running, and in a couple days, the clock's in sync.

But this time it's different.  From OpenBSD, the clock drifts so badly
that NTP can't tame it -- it loses 66 seconds an hour.  I have read *a
lot* of documentation, but I am new to this, so I need someone with
experience to give me a bit of feedback as I have to admit that my eyes
are beginning to glaze over.

I have already pursued one direction with this problem -- I've asked
the OpenBSD list about this.  One suggestion was to check the clock
from DOS to make sure the timer chips were ok, i.e. that it's not a
hardware problem -- it checks out fine.  I've tried older versions of
NTP, but no difference.  I've tried djb's clockspeed program -- still
no joy.

The only thing I've been able to do which works is mess with tickadj. 
I calculated an appropriate value for tick, and I use that in the
system's boot scripts.  Output from tickadj is below.  I know people
will look at this and cry out in horror, but I'll mention that now the
clock does in fact run at the correct speed, and NTP appears to be
working properly...

$ tickadj
KERNEL tick = 10186 usec (from _tick kernel variable)
PRESET tick = 10000 usec
KERNEL tickadj = 50 usec (from _tickadj kernel variable)
PRESET tickadj = 5 usec
KERNEL hz = 100
calculated hz = 100.00 Hz
recommended value of tickadj = 5 us

...with one qualification:  the clock appears to have some stability
issues.  After nearly a week of continuous uptime at a datacenter, I'm
still getting groups of messages such as the following, once or twice a

Nov 22 06:53:17 warlock ntpd[25617]: time reset +0.182694 s
Nov 22 07:59:32 warlock ntpd[25617]: time reset -0.139963 s
Nov 22 11:09:08 warlock ntpd[25617]: time reset -0.325983 s
Nov 22 11:27:20 warlock ntpd[25617]: time reset +0.145826 s
Nov 22 13:38:58 warlock ntpd[25617]: time reset +0.252916 s
Nov 22 14:25:14 warlock ntpd[25617]: time reset -0.152734 s

Can I relax about this, or is it indicative of a serious problem?  I'm
open to all suggestions.  Thanks in advance...

ax at ax-im dot com

More information about the questions mailing list