rdate or xntp

[Robert G. Brown]

On 11 May 2001, Joey Raheb wrote:

> Hello everyone,
>
> I was wondering about date updating on a cluster.  Does anybody do it and how?
> I tried rdate and this did not work for some reason, it said that I could not
> connect to the host???  Also, I tried ntpdate and when for example I type:
> ntpdate ns1.uwo.ca, it outputs the difference between the clock, but it does
> not update my clock???  If anyone can explain to me how to use one of these
> programs I would appreciate the help.

You don't mention what distro you use, but Red Hat ships with an (x)ntp
RPM (e.g. xntp3 in RH 6.2, ntp in RH 7.1).  They are preconfigured to
manage your clock but you have to turn them on at the appropriate
runlevel, e.g. 3-5, with chkconfig.  You also need to direct them (in
/etc/ntp.conf) to a suitable ntp server, which can be your master server
node or whereever you like -- ntp is arranged in layers (or "strata")
served by servers served in turn by the master clock sites on the net,
which are themselves driven by superaccurate atomic clocks.  You may
need to ask your main networking guys or upstream providers who you
should use as a stratum 2 or 3 server, direct your cluster server to
that, and it as a stratum 3 or 4 server to your cluster nodes.

When running, ntp will typically keep your hosts unbelievably accurately
slaved to Truly Accurate Time -- the protocol actually measures and
adjusts for things like the networking time delays between its queries
and the responses.  In principle one can acheive millisecond accuracy on
all hosts.

A tool like procstatd can let you monitor local clock settings on your
cluster hosts to be sure that they are all being updated correctly --
ntp does have problems if a host is down a long time or its hardware
clock is incorrectly set, as it barfs if the time to be adjusted is too
long (it otherwise works very smoothly and incrementally, but it doesn't
do hourlong adjustments or daylight savings time sized jumps).  Thus you
do have to get all your hosts set APPROXIMATELY accurately to start with
(using date -s), run ntp for a few hours to get them all truly
synchronized with true time, use /sbin/clock -w to write the >>soft<<
date/time to the BIOS clock (so that the clock doesn't get reset further
than ntp can correct on a reboot -- this is the thing that typically
screws up when times change in the spring and the fall) and then you
should be able to forget time altogether except at the spring/fall
changeover.  You could probably automate even that.

In an RPM-based cluster it is easy enough to either repackage the RPM's
with your own /etc/ntp.conf or write a short post-install script that
installs your /etc/ntp.conf, does all the messing around with date -s
required (if any), and so forth.

Hope this helps...

   rgb

-- 
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