Clock Synchronization

[alvin at Maggie.Linux-Consulting.com]

hi ya

in our case.... the ntp server has a messier config files...

the client ntp is simpler...

-- also be sure that the client is within 1000(?) sec of the 
   actual time... otherwise ntp will not sync...

http://www.Linux-Consulting.com/NTP
	- server config example
	- client config
	- some ntp commands to help debug whats wrong

have fun
alvin


in Mike's config file for the client... i think you need to
remove the broadcast info... you want to receive timestamp
info as opposed to being a ntp server ??


On Mon, 24 Jun 2002, Robert G. Brown wrote:

> On Mon, 24 Jun 2002, Mike Snitzer wrote:
> 
> > Josip Loncaric (josip at icase.edu) said:
> > 
> > > "Robert G. Brown" wrote:
> > > > 
> > > > I personally think that networked systems, nodes or not, should have the
> > > > time network synchronized if at all possible.  
> > > > 
> > > > We use ntpd to keep everything sync'd.
> > > 
> > > I concur -- ntpd is very good, and it can be very easy on your internal
> > > network (within your cluster, just use broadcast client/server model
> > > instead of polling).
> > > 
> > > Unsynchronized systems can misbehave, particularly with schedulers etc.
> > 
> > Josip et. al.,
> > 
> > I've tried to configure a test cluster with the broadcast client/server
> > model and I've yet to get it working... ntpd yields little output that is
> > of any help.  So if you or anyone else on the list can offer some
> > assistance based on the following data, I'd really appreciate it.
> > 
> > I have Redhat's ntp-4.1.1-1 running on all nodes.  
> > 
> > /etc/ntp.conf on the master has:
> 
> On a typical client we use:
> 
> #
> server  ntpsvr1.phy.duke.edu
> server  ntpsvr2.phy.duke.edu
> server  ntpsvr3.phy.duke.edu
> #
> driftfile /etc/ntp/drift
> multicastclient                 # listen on default 224.0.1.1
> broadcastdelay  0.008
> #
> authenticate no
> 
> where the servers are even simpler:
> 
> #
> server clock.radonc.duke.edu
> driftfile /etc/ntp/drift
> 
> clock.radonc is the university's timeserver and it generally ignores
> non-Duke IP numbers. 
> 
> More generally, you can use any public ntp server (listed in the ntp
> docs) to sync your master to IF you can get them to respond to you --
> some of them do, some don't, some have gone away, and in all cases it
> wouldn't hurt to ask the operators of the systems if they mind the extra
> load.
> 
> EQUALLY generally, it is pretty easy to set up your own toplevel public
> server and sync it to a GPS clock.  I've never done it because I don't
> need to, but it was discussed some on the list not long ago, and it is
> simple to find fairly inexpensive server hardware clocks to keep your
> server itself sync'd to amazingly high precision.
>