Re: NTPD unable to adjust local clock

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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@xxxxxxxxxxxxx>