[ntp:questions] Re: clock not synching with low stratum time server

Richard B. Gilbert rgilbert88 at comcast.net
Mon Jun 20 12:58:57 UTC 2005


sbalaji79 at gmail.com wrote:

>Hi,
>
>
>Following are the information that you have requested:-
>
>
>1) Hardware is alpha and Os is Tru64
>
>
> XNTPDC -P output ( every 900 seconds)
> -------------------------------------
>
>
>
>
>remote           local      st poll reach  delay   offset(secs)
>disp^M
>=======================================================================
>=LOCAL(0)        127.0.0.1       12   64    3 0.00000  0.000000 3.93846
>+cla2astr        5.0.0.0         16   64    0 0.00000  0.000000 0.00000
>+cla3astr        5.0.0.0         16   64    0 0.00000  0.000000 0.00000
>=timeclripfa     131.98.196.54    2   64    3 0.00188 -0.174708 3.93811
>
>
>
cla2astr and cla3astr have "reach fields of 0 meaning that they are 
unreachable.
The delay and offset fields are in milliseconds, not seconds.

>remote           local      st poll reach  delay   offset    disp
>=======================================================================
>*LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00189
>+cla2astr          10.0.0.1        14   64   17 0.00049 -0.275757
>0.93919
>+cla3astr          10.0.0.1        16   64    0 0.00000  0.000000
>0.00000
>=timeclripfa     131.98.196.54    2   64  377 0.00285  0.477008 0.00142
>

cla3astr is still unreachable.

>remote           local      st poll reach  delay   offset    disp^M
>=======================================================================
>*LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00189
>+cla2astr           10.0.0.1        14   64   17 0.00049  0.191304
>0.43945
>+cla3astr           10.0.0.1        14   64  374 0.00049  0.993265
>0.00208
>=timeclripfa     131.98.196.54    2   64  377 0.00284  1.122346 0.00143
>
>
>
cla2astr and cla3astr failed to respond at four out of the last eight 
polling intervals.   The "reach" field  is an eight bit shift register.  
Each response to a query results in left shifting a 1 bit  into the 
register.  Each failure to respond shifts a 0 bit into the register.   
The values are displayed in octal.  377 represents eight 1 bits.  17 
represents four 0 bits and four 1 bits or four failures followed by four 
successes.

>remote           local      st poll reach  delay   offset    disp^M
>=======================================================================
>*LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00191
>+cla2astr            10.0.0.1        14   64  377 0.00049  0.462898
>0.00200
>+cla3astr            10.0.0.1        14   64  277 0.00049 -0.428132
>0.00192
>=timeclripfa     131.98.196.54    2   64  377 0.00188  1.834147 0.00143
>
>
>The offset value of server timeclripfa  increased
>0.5-0.7s(approximately) every
>900 seconds interval. After around three days , xntpdc -p value showed
>as following:
>remote           local      st poll reach  delay   offset    disp
>=======================================================================
>=LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00191
>*cla2astr            10.0.0.1        13 1024  376 0.00615  0.002557
>0.02705
>+cla3astr           10.0.0.1        14 1024  377 0.00049 -0.000086
>0.01656
>=timeclripfa     131.98.196.54    2 1024  377 0.00383 131.74644 0.01530
>
>
>Drift file has got the following value : 1.470(after 3 days).
>
>
>I used local clock as a fall back reference just in case server
>timeclripfa
>goes down.
>
>Other local peer servers ( cla2astr,cla3astr) also has approximately
>same kind of stats as this one(cla2astr) i.e 130s drift after three
>days.
> 
>                                               
>Thanks,
>Balaji
>
>
In all cases, it appears that your local clock has been selected as the 
synchronization source (the * in the first column).   I'm not as 
familiar with the ntpdc display as I am with the ntpq display and I'm 
not certain what the "=" in column one means.  The local clock is 
drifting farther and farther from the correct time because it is 
unsynchronized.

In your original post you mentioned using "xntpd 4.1.1" but the "x" was 
dropped from the name at version 4.0.   So either it should be ntpd or 
it's not 4.1.1.

Finally, you mention a drift file, but the ntp.conf in your original 
post does not specify a drift file!   Did you really cut and paste the 
entire ntp.conf file or just the parts you thought were significant?

I would suggest the following ntp.conf:

logfile /var/ntp/ntp.log
driftfile /var/ntp/ntp.drift
server timeclripfa.akadns.net prefer
peer cla2astr
peer cla3astr
peer cla4astr

Be sure to create /var/ntp with permissions allowing ntpd to write to it.



More information about the questions mailing list