NTPD unable to adjust local clock
Matthew Dillon
dillon at apollo.backplane.com
Wed Apr 6 11:48:35 PDT 2005
:On Tue, Apr 05, 2005 at 06:44:33PM -0700, Matthew Dillon wrote:
:> I've investigated this a bit more. OpenBSD's ntpd is just not up to
:> snuff. It has no PLL locking code at all and the result is that the
:> timekeeping is constantly out of whack, oscillating back and forth as
:> ntpd does its occassional adjtime() based corrections. If it isn't
:> out of whack due to the clock being fast or slow, it's out of whack due
:> to the adjtime() call trying to correct 5 minutes worth of creep with a
:> single call. My test boxes are oscillating between -10ms and +25ms of
:> error and they have fairly accurate clocks. Any boxes with inaccurate
:> clocks are going to be hit hard. A 1 second error is easy to accumulate
:> with a clock that is only 0.3% off.
:
:Well, I get differences between ntp0.fau.de and ntps1-1.cs.tu-berlin.de
:of 0.003, so the system time oscillating somewhat is not critial.
:
:After watching the output of ntpd for a while, there seems to be a bug.
:The offset goes down from initially 1.138025 to 0.048019 and 0.024507,
:but it gets addjusted to 0.663717s right afterwards. That's bogus.
:
:Joerg
It can't adjust instantly unless it calls settimeofday(). adjtime()
only shifts the clock 30ms/60seconds if the correction is < 1 second,
300ms/60seconds if the correction is > 1 second.
You can do a rough check of the drift by running:
while (1)
rdate -v -p -n <some_real_time_protocol_based_timesource>
sleep 1
end
What is likely happening is that it is doing one correction every 5
minutes and since it is not correcting the frequency error the clock
is sliding out of correction even as the first correction is being
applied, and then sliding out even worse after the system has finished
applying the correction. At the next 5 minute mark ntpd applies
the next correction and the whole mess starts over. You wind up with
an oscillating clock.
As I said... it's broken. There is NO WAY to correct the clock with
adjtime(), that's why ntp_adjtime() exists. In the early days real time
clocks used reasonably high quality crystals and it wasn't a problem.
Today's PC's use poor quality, non-thermally compensated crystals or
even don't use crystals at all (they use something based off one of the
motherboard's frequency multipliers, which are TERRIBLE time keepers).
-Matt
Matthew Dillon
<dillon at xxxxxxxxxxxxx>
More information about the Users
mailing list