[ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

Richard B. Gilbert rgilbert88 at comcast.net
Mon Mar 7 01:04:46 UTC 2011


On 3/6/2011 3:14 PM, Ralph wrote:
> Did another complete shutdown of ntpd, made suere there were no ntpd processes running, set the time with ntpd -q -g, and then started it back up.  Here is what things look like shortly after startup...
>
> ntpq -c peer -c as -c rl
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   rdns01.nexcess. 64.113.32.5      2 u   59   64    1   62.831  913.967   7.812
>   mirror          128.138.140.44   2 u   59   64    1   71.406  915.138   7.812
>   clock.trit.net  192.43.244.18    2 u   58   64    1    8.913  907.267   7.812
>   ntp1.phoenixpub .LCL.            1 u   57   64    1   18.362  911.807   7.812
>   louie.udel.edu  128.4.1.1        2 u   56   64    1   91.502  898.406   7.812
>   ns.unc.edu      204.34.198.40    2 u   55   64    1  113.150  897.946   7.812
>   ntp-3.cns.vt.ed 198.82.247.164   2 u   55   64    1  103.533  935.682   7.812
>   ntp-2.cns.vt.ed 198.82.247.164   2 u   54   64    1  109.392  927.838   7.812
>   clock.isc.org   .GPS.            1 u   53   64    1   21.831  931.162   7.812
>
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
>    1 56602  9014   yes   yes  none    reject   reachable  1
>    2 56603  9014   yes   yes  none    reject   reachable  1
>    3 56604  9014   yes   yes  none    reject   reachable  1
>    4 56605  9014   yes   yes  none    reject   reachable  1
>    5 56606  9014   yes   yes  none    reject   reachable  1
>    6 56607  9014   yes   yes  none    reject   reachable  1
>    7 56608  9014   yes   yes  none    reject   reachable  1
>    8 56609  9014   yes   yes  none    reject   reachable  1
>    9 56610  9014   yes   yes  none    reject   reachable  1
> assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
> version="ntpd 4.2.2p1 at 1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1)",
> processor="i686", system="Linux/2.6.18-194.32.1.el5", leap=11,
> stratum=16, precision=-7, rootdelay=0.000, rootdispersion=0.915, peer=0,
> refid=INIT, reftime=00000000.00000000  Wed, Feb  6 2036 22:28:16.000,
> poll=6, clock=d11e68fd.1cd5690b  Sun, Mar  6 2011 12:11:41.112, state=1,
> offset=0.000, frequency=8.747, jitter=7.812, noise=7.812,
> stability=0.000, tai=0
>
> And then not long later it goes back to...
>
> ntpq -c peer -c as -c rl
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   rdns01.nexcess. 64.113.32.5      2 u    1   64   17   60.673  7090.71 9486.71
>   mirror          128.138.140.44   2 u    2   64   17   71.406  915.138 14064.5
>   clock.trit.net  192.43.244.18    2 u    -   64   17   10.914  21512.2 15276.9
>   ntp1.phoenixpub .LCL.            1 u    1   64   17   18.362  911.807 14098.2
>   louie.udel.edu  128.4.1.1        2 u   62   64    7   90.110  12974.6 9407.68
>   ns.unc.edu      204.34.198.40    2 u    -   64   17  101.525  7375.44 9512.29
>   ntp-3.cns.vt.ed 198.82.247.164   2 u   60   64    7   99.461  13937.7 10291.4
>   ntp-2.cns.vt.ed 198.82.247.164   2 u   58   64    7  101.434  14540.0 10868.6
>   clock.isc.org   .GPS.            1 u   59   64    7   20.526  14434.1 10759.7
>

This looks very much like NTPQ output taken far too early to be meaningful.

I suggest that you start NTPD and let it run for TWENTY-FOUR HOURS. 
THEN issue ntpq and post the results.  If you are really in a rush,
you can issue NTPQ after twelve hours; NTPD needs at least that long to 
get tight synchronization!  It's a big help if you can keep the 
temperature constant.




More information about the questions mailing list