Clock Synchronization

[Robert G. Brown]

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.


     rgb

> server  clock.psu.edu    # arbitrary choice for external NTP server 
> server  127.127.1.0      # local clock
> fudge   127.127.1.0 stratum 10
> 
> broadcast 192.168.0.255 ttl 6
> broadcastdelay  0.008
> enable bclient
> 
> driftfile /etc/ntp/drift
> authenticate no
> 
> /etc/ntp.conf on the slaves has:
> 
> broadcastclient   # also tried with broadcastclient 192.168.0.255
> broadcastdelay  0.008
> enable bclient
> 
> driftfile /etc/ntp/drift
> authenticate no
> 
> /etc/ntp/step-tickers on the slaves has:
> LC1
> 
> NOTE: this really shouldn't needed in a properly configured broadcast
> client/server config correct?  I've read that when ntpd starts as a client
> it handshakes a bit with an available ntpd server like a normal polling
> config and then reverts to using the broadcasts.
> 
> starting ntpd on a slave yields:
> [root at LC1 ~]# rsh LC2 /sbin/service ntpd restart
> Shutting down ntpd:                                        [  OK  ]
> ntpd: Synchronizing with time server:                      [  OK  ]
> Starting ntpd:                                             [  OK  ]
> 
> /var/log/messages on the slave has:
> Jun 24 11:23:27 LC2 ntpd: ntpd shutdown succeeded
> Jun 24 11:23:27 LC2 ntpdate[3080]: step time server 192.168.0.1 offset -0.005725 sec
> Jun 24 11:23:27 LC2 ntpd:  succeeded
> Jun 24 11:23:27 LC2 ntpd[3085]: ntpd 4.1.1 at 1.786 Mon Apr  8 06:30:52 EDT 2002 (1)
> Jun 24 11:23:27 LC2 ntpd: ntpd startup succeeded
> 
> tcpdump from the master shows:
> [root at LC1 ~]# tcpdump -i eth0 "port 123"
> tcpdump: listening on eth0
> 11:35:46.125187 LC1.ntp > 192.168.0.255.ntp:  v4 bcast strat 3 poll 6 prec -17 (DF) [tos 0x10] 
> 11:36:49.125308 LC1.ntp > 192.168.0.255.ntp:  v4 bcast strat 3 poll 6 prec -17 (DF) [tos 0x10] 
> 
> tcpdump from a slave shows:
> [root at LC2 ~]# tcpdump -i eth0 "port 123"
> tcpdump: listening on eth0
> 11:35:46.108483 LC1.ntp > 192.168.0.255.ntp:  v4 bcast strat 3 poll 6 prec -17 (DF) [tos 0x10] 
> 11:36:49.110939 LC1.ntp > 192.168.0.255.ntp:  v4 bcast strat 3 poll 6 prec -17 (DF) [tos 0x10] 
> 
> SO... the master's ntpd appears to be doing what it should be and it 
> would appear the client (slave) is getting the packet(s) it needs.. I
> suppose now it's just a question of whether or not the ntpd on the slave
> is actually listening for the broadcast. 
> 
> ntpq -p on a slave:
> [root at LC2 ~]# ntpq -p
> No association ID's returned
> 
> NOTE: shouldn't the client (slave) ntpd see 192.168.0.255 as a source _IF_
> it's ntpd were doing what it should?
> 
> If anyone any ideas why the clients aren't reporting any association IDs
> or can provide the details on how you got your broadcast client/server
> ntp config working please let me know.
> 
> Thanks.
> Mike
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> 

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu