Conference lassie::ucx

5340.0. "NTP log full of same clock reset entries" by GIDDAY::TAN () Mon Mar 17 1997 01:14

	A customer is having problem with NTP trying to sync up with
a UNIX NTP server.  He is running UCX V4.0 ECO 2 on VAX/VMS 5.5-2H4.

	His NTP config file contained the line:
		server 203.7.15.192

his ntp log file is full of the followings:  as if the local clock is
not able to sync with the server, and have to do the 'jump' all the
time.

* clock reset ~+429.500 sec by something, clearing.
* adjusting base_time [1] 10160677 to 10160676
* basetime: NTS offset is 794188370.503270
* re-acquired server 203.7.15.192
* clock reset ~+429.500 sec by something, clearing.
* adjusting base_time [1] 10160677 to 10160676
* basetime: NTS offset is 794188370.503270
* re-acquired server 203.7.15.192
* clock reset ~+429.500 sec by something, clearing.
* adjusting base_time [1] 10160677 to 10160676
* basetime: NTS offset is 794188370.503270
* re-acquired server 203.7.15.192
* clock reset ~+429.500 sec by something, clearing.
* adjusting base_time [1] 10160677 to 10160676
* basetime: NTS offset is 794188370.503270
* re-acquired server 203.7.15.192
* clock reset ~+429.500 sec by something, clearing.
* adjusting base_time [1] 10160677 to 10160676
* basetime: NTS offset is 794188370.503270
* re-acquired server 203.7.15.192

the 4 lines entries repeat itself, and because there was no
timestamp, I am not sure how soon the log was written.  Also, 
why did it re-acquired the server all the time?

/David

	Is this the infamous 7 min 9 sec bug as reported in CFS.29029,
and fixed in UCX 3.3 eco2?  (429.5 sec ~ 7 min 9 sec)

" I found the problem to be in the NTS_offset (basetime) calculation
resulting from ambiguous casting of unsigned long values to double.
This caused the observed 7 min 9 sec skew in the system time. 
-gaylord"

	I suspect what happened here is, UCX/NTP received an update
from the Unix server, but mis-set the time, so when next update
arrived, the time was wrong, and the cycle continued.

	I'll recommend customer to update their V4.0eco2 UCX, even though 
I can't find the above fix in the later ecos.


/Dave
                                        

	Customer applied ECO5 for UCX 4.0, and she is still getiing the same
problem, NTP log file is still full of the reset messages.

	Any clue, has the 7min 7sec bug raised its ugly head again?

/Dave

Sounds like probably code regression, give that you
switched UCX versions.

Given that this is a customer problem, it is a 
prime candidate for an IPMT.

Not a good or a happy answer but a relatively 
quick one ;-)

Lee
_not_ the ntp maintainer