[ntp:questions] Is this normal behavior?

Richard B. gilbert rgilbert88 at comcast.net
Fri Mar 2 22:52:50 UTC 2007


Zembower, Kevin wrote:
> I'm not very knowledgeable about NTP, but I'm suspicious of its
> implementation on one of my servers. I have one server running the
> Debian sarge package of NTP:
> cn2:/var/log# ntpq
> ntpq> version
> ntpq 4.2.0a at 1:4.2.0a+stable-2-r Fri Aug 26 10:30:19 UTC 2005 (1)
> ntpq>
> 
> I've tried to set this server up as a timeserver for my network, using
> tock.usno.mil, a time server at my institution (Johns Hopkins
> University) and the pool timeservers:
> ntpq> peers
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ========================================================================
> ======
> +jhname.hcf.jhu. 128.4.1.1        2 u   60   64  177    3.313  835.818
> 545.232
> *ntp1.usno.navy. .USNO.           1 u   60   64  177    8.567  827.174
> 551.616
> +trane.wu-wien.a 195.13.1.153     3 u   57   64  177  125.292  841.188
> 548.251
> +221-15-178-69.g 140.142.16.34    2 u   50   64  177  107.300  1212.00
> 395.490
> +tock.jrc.us     207.168.62.76    2 u   58   64  177   16.942  1020.49
> 432.251
>  LOCAL(0)        LOCAL(0)        13 l   55   64  177    0.000    0.000
> 0.002
> ntpq>
> 
> I notice the problem here, and if I run 'watch ntpq -p.' Seldom is my
> reachability 377, and it frequently and inexplicitly drops to 1 as I'm
> watching it. Ten minutes ago reachability was 177 as shown above.
> Watching it in the last minute, it dropped from 377 to 1 on all sources.
> Now it's:
> Every 2s: ntpq -p
> Fri Dec  8 10:35:18 2006
> 
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ========================================================================
> ======
>  jhname.hcf.jhu. 128.4.1.1        2 u   53   64    3    2.707  660.049
> 176.587
>  ntp1.usno.navy. .USNO.           1 u   52   64    3    8.904  663.193
> 181.873
>  trane.wu-wien.a 195.13.1.153     3 u   49   64    3  125.979  681.070
> 186.182
>  221-15-178-69.g 140.142.16.34    2 u   51   64    3  104.207  485.281
> 183.834
>  tock.jrc.us     207.168.62.76    2 u   50   64    3   16.912  668.565
> 186.520
>  LOCAL(0)        LOCAL(0)        13 l   49   64    3    0.000    0.000
> 0.002
> 
> Is this normal behavior for NTP, to frequently lose the ability to reach
> a timeserver? If not, how can I troubleshoot it further?


Hell no!  You seem to have a serious network problem of some sort.  Can 
you ping these servers?  At a time when the problem is manifesting itself?

It has nothing to do with your present problem but the pool has 
presented you with servers several thousand miles away from you.  The 
delays are such that it is most unlikely that these servers will ever be 
selected.  I believe that the pool allows you to specify servers in the 
US (other areas as well but you, being in the US should be using nearby 
servers).  You should find out how and configure accordingly.  I think 
you just stick a "US" in front of the "pool.ntp.org".  If you want to 
play guessing games you might try us.pool.ntp.org.

> 
> Here's the syslog entries pertaining to npt for just one hour this
> morning:
> Dec  8 09:03:06 cn2 ntpd[16955]: time reset +3.120367 s
> Dec  8 09:07:21 cn2 ntpd[16955]: synchronized to LOCAL(0), stratum 13
> Dec  8 09:08:25 cn2 ntpd[16955]: synchronized to 67.128.71.75, stratum 2
> Dec  8 09:09:31 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 09:23:33 cn2 ntpd[16955]: time reset +3.503628 s
> Dec  8 09:27:51 cn2 ntpd[16955]: synchronized to LOCAL(0), stratum 13
> Dec  8 09:28:56 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 09:36:18 cn2 ntpd[16955]: synchronized to 128.220.2.7, stratum 2
> Dec  8 09:36:25 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 09:40:40 cn2 ntpd[16955]: synchronized to 128.220.2.7, stratum 2
> Dec  8 09:41:45 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 09:41:47 cn2 ntpd[16955]: synchronized to 69.178.15.221, stratum
> 2
> Dec  8 09:43:46 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 09:49:21 cn2 ntpd[16955]: synchronized to 67.128.71.75, stratum 2
> Dec  8 09:49:21 cn2 ntpd[16955]: time reset +4.512453 s
> Dec  8 09:53:41 cn2 ntpd[16955]: synchronized to LOCAL(0), stratum 13
> Dec  8 09:54:39 cn2 ntpd[16955]: synchronized to 128.220.2.7, stratum 2
> Dec  8 09:54:44 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 10:01:11 cn2 ntpd[16955]: synchronized to 67.128.71.75, stratum 2
> Dec  8 10:02:14 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 10:09:40 cn2 ntpd[16955]: synchronized to 67.128.71.75, stratum 2
> Dec  8 10:10:51 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> Dec  8 10:10:51 cn2 ntpd[16955]: time reset +3.950081 s
> Dec  8 10:15:08 cn2 ntpd[16955]: synchronized to LOCAL(0), stratum 13
> Dec  8 10:16:14 cn2 ntpd[16955]: synchronized to 192.5.41.41, stratum 1
> 
> These time resets seem rather large to me. Is this normal, too?

That's not normal either.  Nor is the fact that your system is "clock 
hopping".

> 
> Here's the output of the peerstat.qwk script:
> cn2:/var/log/ntpstats# gawk -f
> /home/kevinz/ntp-4.2.2p4/scripts/stats/peer.awk peerstats
>        ident     cnt     mean     rms      max     delay     dist
> disp
> ========================================================================
> ==
> 67.128.71.75     715 2364.263  996.393 2364.263   16.751  947.994
> 96.315
> 127.127.1.0      844    0.000    0.000    0.000    0.000    0.990
> 0.957
> 192.5.41.41      728 2321.937 1023.300 2964.896    7.907  944.371
> 94.581
> 137.208.3.51     675 2500.134  995.134 3013.699  124.989  503.205
> 44.951
> 128.220.2.7      721 2405.904  982.298 2712.599    2.564  940.869
> 95.476
> 69.178.15.221    722 2395.872 1002.130 2911.691  104.730  997.703
> 95.423

Excuse me while I barf!  I can't tell what's wrong but something is FUBAR!

What kind of internet connection do you have?  Tin cans and string?




More information about the questions mailing list