[ntp:questions] Strange behaviour

Richard B. gilbert rgilbert88 at comcast.net
Thu Apr 12 17:43:36 UTC 2007


Burkhard Schultheis wrote:
> Harlan Stenn schrieb:
> 
>>If you are running ntpd on those systems then ntpdate will not adjust the
>>time because it will not be able to bind to port 123.
> 
> 
> For the test with ntpdate I stopped ntpd (via yast, it's SuSE SLES 9.0).
> Before stopping ntpd I got an error message from ntpdate.
> 
> 
>>If you are running ntpd, please post the ntp.conf files and the output of
>>'ntpq -p' on both systems.
> 
> 
> ntp.conf is identical ob both systems. Here are the relevant lines:
> 
> server 127.127.1.0  # local clock (LCL)
> fudge 127.127.1.0  stratum 10 # LCL is unsynchronized
> driftfile /var/lib/ntp/drift/ntp.drift # path for drift file
> logfile /var/log/ntp		# alternate log file
> server <IP>
> 
> ntpq -p <IP> on first machine:
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  LOCAL(0)        LOCAL(0)        10 l    3   64  377    0.000    0.000
>  0.008
> +192.53.103.104  .PTB.            1 u    8   64  377   32.460  3741.35
> 205.107
> *192.53.103.108  .PTB.            1 u    9   64  377   32.179  3737.53
> 201.231
> 
> on second machine:
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  LOCAL(0)        LOCAL(0)        10 l   59   64    7    0.000    0.000
>  0.008
>  192.53.103.104  .PTB.            1 u   59   64    7   32.136  522.209
> 203.600
>  192.53.103.108  .PTB.            1 u   50   64    7   32.756  556.967
> 204.109
> 
> The delay seams to be very high, or am I wrong? Another mystery: In both
> drift files I read 0.000!
> 
> Regards,
> Burkhard

The delays are a little high on both machines.  The offset is far too 
high on both machines and so is the jitter on both machines!

In the case of the second machine, it appears as if the machine might 
have been rebooted just a few minutes ago or that ntpd might have been 
started only a few minutes ago.

Ntpd needs to run for a while before it will reach anything 
approximating a steady state.  I'd say that thirty minutes is a minimum. 
   If you fail to use the "iburst" keyword on your server statements, 
and/or to start ntpd with the -g option it may need a great deal more 
time than that!




More information about the questions mailing list