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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
