[ntp:questions] Re: synchronization

Richard B. Gilbert rgilbert88 at comcast.net
Thu Mar 9 22:53:42 UTC 2006


Ron Croonenberg wrote:

> Richard B. Gilbert wrote:
> 
>> Ron Croonenberg wrote:
>>
>>> Hello,
>>>
>>> I am trying to do the following.
>>>
>>> We are planning to have a time server with it's own gps/clock and 
>>> have other servers sync with that one.
>>>
>>> For now I am setting up one machine that servers as the main time 
>>> server and let others sync with it.
>>>
>>> Problem I have is that I see things in the ntp.log like :
>>>  9 Mar 09:06:21 ntpd[2431]: time reset 1.734569 s
>>>  9 Mar 09:06:21 ntpd[2431]: synchronisation lost
>>>  9 Mar 09:15:01 ntpd[2431]: synchronisation lost
>>>  9 Mar 09:30:03 ntpd[2431]: time reset 1.740734 s
>>>  9 Mar 09:30:03 ntpd[2431]: synchronisation lost
>>>  9 Mar 09:34:28 ntpd[2431]: synchronisation lost
>>>
>>> So I either have a problem in the  server and client config files or 
>>> I am facing another problem ?
>>>
>>> tia,
>>>
>>> Ron
>>
>>
>>
>> Please post the ntp.conf files for both the server and the client.  
<snip>
> 
> here's what I have.
> 
> 
> Server ntp.conf:
> ********************************************************
> restrict default nomodify notrust
> restrict 127.0.0.1
> restrict xxx.yyy.zzz.0 mask 255.255.255.0 nomodify notrap
> 
> noquery

noquery, on a line by itself is invalid!!!!  If it were valid, you would 
be shooting yourself in the foot because "noquery" means "do not respond 
to querys" which means your server couldn't serve time anyway!!!!

> 
> server  129.6.15.29
> server  204.34.198.40
> server  18.145.0.30
> 
> driftfile /var/lib/ntp/drift
> logfile   /var/log/ntp.log
> broadcastdelay  0.008
> 
> authenticate no
> 
> keys            /etc/ntp/keys
> ********************************************************
> 
> 
> 
> server ntpq -p :
> ********************************************************
>      remote           refid      st t when poll reach   delay   offset 
>  jitter
> ============================================================================== 
> 
> +time-b.nist.gov .ACTS.           1 u   43   64  377   36.473  3598.51 
> 33.187
> *tick.usnogps.na .USNO.           1 u   50   64  377  107.202  3594.40 
> 31.645
> +NAVOBS1.MIT.EDU .PSC.            1 u   43   64  377   36.762  3596.60 
> 32.328
> ********************************************************

This is a pretty dismal looking ntpq banner!!  The offsets say that your 
clock is off by more than three seconds.  At the maximum slew rate of 
500 parts per million, it will take several hours to bring your clock 
into synchronization.

How are you starting ntpd?  What options are you using?  If you use the 
-g option, ntpd should set the clock unconditionally at startup; e.g. it 
should query the servers to find out what time it is and then set your 
clock to that time.

Next, the three servers you are using appear poorly chosen.   You should 
not be using stratum 1 servers unless you will be serving time to 
several hundred clients!  All the public stratum 1 servers are generally 
loaded to the breaking point and should be avoided if possible.  The 
figures for round trip delay are quite high!  107 milliseconds is 
downright unreasonable!  36 is not very good either.  The highest delay 
I have is 19 milliseonds.   Look for servers closer to you; e.g. with 
shorter round trip delays.

You should be using four servers.  Four is the minimum number of servers 
  required to defend against one false ticker.  Two is the worst 
possible number.  Three is better but if one fails. . . .

Add the "iburst" keyword to each server statement.  That will cause the 
first eight requests to each server to be sent at intervals of two 
seconds and get the data necessary to start synchronizing your clock in 
about sixteen seconds versus five and a half minutes without it.

> 
> server OS: Linux 2.4.21-4.ELsmp
> 
> 
> 
> 
> client ntp.conf:
> ********************************************************
> restrict default ignore
> restrict xxx.yyy.zzz.8 mask 255.255.255.255 nomodify notrap noquery
> restrict 127.0.0.1
> 
> noquery

Once again, the above "noquery" is invalid on a line by itself.

> 
> server xxx.yyy.zzz.8
> 
> driftfile /var/lib/ntp/drift
> broadcastdelay  0.008
> logfile /var/log/ntp.log
> 
> authenticate no
> 
> keys            /etc/ntp/keys
> ********************************************************
> 
> 
> 
> 
> 
> client ntpq -p:
> ********************************************************
>      remote           refid      st t when poll reach   delay   offset 
>  jitter
> ============================================================================== 
> 
> *neptune.sub.dom NAVOBS1.MIT.EDU  2 u   50   64  377    0.214  -315.16 
> 36.796
> ********************************************************
> 
> client OS : Linux 2.4.21-32.ELsmp
> 

I'd suggest removing or commenting out ALL the restrict statements until 
you get everything else working.  Then you can uncomment or replace them 
and see if they break anything.




More information about the questions mailing list