From: hebo@mbari.org (Bob Herlien)
Newsgroups: comp.os.vxworks
Subject: re: NTP
Date: 15 Dec 92 22:33:57 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Sorry about the previous message.  Fingers slipped, and the message was gone.

>
> I'm using the VxWorks port of NTP on both a Motorala MVME147 and MVME167.  I've
> gotten the 147 to work reasonably well.  But, on the 167, after 15 minutes or
> so, I constantly get:
> 
>     Previous time adjustment didn't complete
> 
> Since I'm not familiar with NTP, has anyone else seen this problem and solved
> it.  Our clock rate is 1000 Hz on both machines.  NTPD is the only "user" task
> operating on the machines (during our NTP tests), so there's nothing really to
> steal the CPU away from timekeeping.
> 
> 				Tom Nicinski
> 				Fermi National Accelerator Lab
> 				nicinski@fnal.fnal.gov
> 				708-840-3145


Basically, this message means exactly what it says.  NTP acts as a phase-locked
loop, trying to synchronize your clock to the selected host.  Periodically,
(every 4 seconds by default) it calculates the offset between the two, and 
slews the local clock toward the correct time, using the adjtime() system
call (implemented for vxWorks in usrTime).  The above message means that
adjtime() returned an error because the slew requested by the previous 
adjustment still hasn't completed.

This message is usually a symptom of a clock that's out of adjustment.  If
you read comp.protocols.time.ntp, for example, you'll see that it's a common
complaint from Sun owners, because their clocks are not very good (actually,
it's because Suns can lose clock interrupts).

A couple of things to try.  First, simply let it run for a couple of days 
and see if it corrects itself.  When you first bring up NTP, it doesn't have
a drift file established yet, so it assumes a long-term clock drift of zero.
As it gains experience, it estimates the clock drift and compensates for it.
So, if the clock is a little too far off for the basic algorithm to achieve
lock, but close enough to lock with drift compensation, it will fix itself.

If that doesn't work, it probably means that the clock frequency is not close
enough to assumed frequency for NTP to achieve phase-lock.  There are two
parameters you may want to tweak, both of them in usrTime:  tick and tickadj.
Tick is the amount of time represented by one clock tick in your system;
e.g., for a 60 Hz clock, tick should be 16667 (microseconds).  However, some
systems may not have that fine a resolution, and may actually be ticking
at some other period.  My SBE VPU-30, which I used for porting NTP, actually
ticks at 16664 us, because the timer chip has a resolution of 4 us.  As
another example, the clocks in Sun (3? 4? I don't use Sun's) are nominally
100 Hz (10000 us), but NTP users have learned that, for them, you need to
define tick to be 9999 or 9998, to get them close enough to reality for 
NTP to phase-lock.

An aside here:  NTP is a heavily filtered phase-lock loop, with a narrow
capture range.  I'm not sure what that range is for this version, but the
authors assumed that crystal oscillators typically provide accuracies of
better than 100 ppm, and optimized accordingly.  100 ppm is one part in 10000,
which accounts for the fact that changing "tick" by one count can be 
significant.

The other variable you may tweak is tickadj.  This tells usrTime how quickly
to adjust the clock when adjtime() is called.  UsrTime will add or subtract
tickadj microseconds every clock tick until the adjustment is complete.
Increasing tickadj will allow bigger adjustments to complete in the same time.

If the problem persists after allowing a couple of days for it to settle
down, try to determine how far off the clock is, and in what direction.
You can look at the numbers in the drift file for an estimate, or look at
variable "drift_comp" in ntp.  In both cases, the number is the actual 
error estimate * 4096.  Adjust tick as appropriate.  You may also try 
making tickadj larger to see if the problem goes away.  If it does, and you
get a good drift estimate out of the drift file, see if tick needs adjusting,
as above.  In either case, you should set tick to be the closest estimate
possible to the actual number of microseconds per clock tick.

Oh yeah, make sure your application isn't doing anything to make you lose
clock ticks.  If you are, you're almost certain to get the above message.

Good luck.

--------------------------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@mbari.org