Re: TS-7200: time sync issues

["M. Warner Losh" <imp%bsdimp.com@localhost>]

In message: <493F24BD.2070205%donhayford.com@localhost>
            Donald T Hayford <don%donhayford.com@localhost> writes:
: Ken Hornstein wrote:
: > This has been bugging me for a while now, and I thought I'd finally say
: > something about it.
: >
: > On my TS-7200, ntpd has some issues synchronizing the clock.
: > Specifically, when ntpd starts up, it finds the time servers normally
: > and does the initial time step to get the clock close enough.  But
: > after that time step occurs, the clock is off by a variable amount;
: > sometimes it's close to a second, but a lot of the time it's around
: > a quarter of a second.  E.g:
: >
: > Dec  7 20:28:57 modred ntpd[302]: frequency initialized 0.000 PPM from 
/var/db/ntp.drift
: > Dec  7 20:30:30 modred ntpd[302]: time reset -2.381602 s
: > Dec  7 20:30:30 modred ntpd[302]: kernel time sync status change 0001
: > Dec  7 20:46:32 modred ntpd[302]: time reset +0.906469 s
: > Dec  7 21:02:04 modred ntpd[302]: time reset +0.573713 s
: > Dec  7 21:18:06 modred ntpd[302]: time reset +0.201409 s
: > Dec  7 21:33:12 modred ntpd[302]: time reset +0.198393 s
: >
: > Eventually what will happen is that ntpd will get "lucky" and get the time
: > within the 128 ms slew threshold, and then ntpd will function normally.
: > I've been trying to figure out what's going on here, but I've had little
: > luck.  Does anyone have any ideas?  Or even an idea of where to start?
: >
: > --Ken
: >
: >   
: Hmm...maybe I don't understand your problem, but I thought that was how 
: ntpd worked.  When the clock isn't right, ntpd needs to both step the 
: clock and possibly change the clock frequency.  When the clock frequency 
: isn't quite right, then stepping the clock will work for a while, but it 
: will still drift off.  So, ntpd will repeatedly readjust the clock and 
: clock frequency until it doesn't drift much.  I believe that ntpd has an 
: algorithm to slowly adjust the clock frequency to minimize effects of 
: intermittent bad data points.

This is true, and false.  It is true that this is what NTP does,
however the magnitude of the error is about 30x what one would expect
in a properly operating system, and 8x too big for ntpd to cope with).

You should never see more than one of these messages, and that at
startup.  Once it does the initial slew of the phase since it has
estimated the proper frequency, the system clock should be running
within a few ppm of the reference system.

The problem is that NTP's algorithm assumes that the initial clock
frequency error on the system is within ~128ppm of the reference
system.

The above messages indicate that the error is outside that range.  The
best two estimates are at 200ppm, the others are much larger than that
(900ppm and 573ppm).  When the errors are that large, ntp can't work.
Even so, it should have steered out 100% of the frequency error in the
system's notion of real time.  The fact it had to continue to adjust
the clock indicates that the system is still losing time, which
suggests missing clock interrupts or a timekeeping device that wraps
and the wrapps are missing.

In a modern system, the errors should follow the quality of the clock
generator for the CPU.  This should be within a few ppm for the other
digital circuitry to work properly, so the appearance of the above
messages indicate a severe problem with time keeping on the system.

Warner