Clock Synchronization

[Robert G. Brown]

On Mon, 24 Jun 2002, Mike Snitzer wrote:

> in the client you specify multicastclient, but in the server config you do
> NOT specifiy: broadcast 224.0.1.1 

I think that the multicastclient statement is basically cruft of some
sort -- from what I can see it basically enables multicast client
binding and operation if it ever receives a multicast but otherwise
doesn't interfere with the polling operation of the client daemon.
Other client configs I use are little more complicated than the server
config in the first reply -- a single server line and a driftfile spec.
Both seem to work fine.

As you note, we don't deliberately configure multicast server operation;
ntp isn't so heaviweight as all that.

> So are you sure that the server is spitting out a multicast on 224.0.1.1?  

Probably not.  I think that we're just binding to the servers in polling
mode.

> Thanks for your response, but I'm still looking for some broadcast
> client/server specific insight.  What kind of ntpq -p output do you have

I'd avoid this (broadcasts), unless you have a real problem with network
load, and even then I'd consider solving it by building some different
strata servers and organizing your binding hierarchically.

The simplest ntp.conf set that you can install that will (probably, I'm
sure folks will correct me if not:-) work is just:

# server mystratum2.my.net
server stratum1.whatever.net	# Ask First (or build your own)
driftfile /etc/ntp.conf

# client (any client, ideally local to mystratum2.my.net
server mystratum2.my.net
driftfile /etc/ntp.conf

and you can get fancier from here once you get this to work.  Note that
in a lot of cases you'll be displacing the strata down by one or two --
our clients are generally stratum 4, our local servers stratum 3.  I
expect this is at least in part an expression of the docs suggestion to
carefully avoid synchronization loops and strictly limit connection load
on stratum 1 (and by now 2) servers.

ntp is pretty simple and automagic, really.  All the fancy stuff is for
people with complex needs -- authentication, WAN network control via
multicasts or broadcasts, load control (poll interval spec).  In most
cases you can just ignore this (given a good stratum N-1 server or three
synced to a stratum N-2 server) and your stratum N hosts will stay
within a few thousandths of a second at worst of Real Time.  More than
accurate enough to make e.g. make happy or to ensure that log times are
comparable across systems.

If you start ntp via /etc/init.d/ntpd start (instead of directly) then
it runs ntpdate first to step your client directly into near-sync with
its servers; this avoids the problem produced by a drifting or mis-set
hardware clock (more than 1000 seconds out) and usually means that the
client time converges to really really GOOD time in a matter of minutes
after boot and is never really bad.

> on the server and clients?  Broadcast and multicast with ntp are very
> similar in configuration.. but the fact that you don't even specify
> "broadcast" line in the server config is a bit strange.

But it works (see below) because we don't really use multicasts.  The
clients would probably work automagically work without reconfiguration
if we DID change our servers around so they used multicasts.

I suppose an Evil Fiend could probably bring up a multicast server on
our LAN and maliciously reset our clocks to London time.  Once.  Then of
course we'd find them and apply a sucker rod (see man syslogd for
definition) to their schooling...

(client)
rgb at ganesh|T:143>ntpq -p
     remote refid st t when poll reach delay offset jitter
==============================================================================
+einstein.phy.du geiger.RadOnc.D 4 u 228 1024 377 0.260 -3.581 0.481
+nebula.phy.duke geiger.RadOnc.D 4 u 569 1024 377 0.313 -13.442 5.558
*bigbang.phy.duk clock.isc.org 3 u 675 1024 377 0.339 0.620 0.887
rgb at ganesh|T:144>einstein
Warning: Remote host denied X11 forwarding.
Last login: Mon Jun 24 13:42:14 2002 from ganesh.phy.duke.edu

(server)
rgb at einstein|T:101>ntpq -p
     remote refid st t when poll reach delay offset jitter
==============================================================================
*geiger.RadOnc.D ns3.oit.unc.edu 3 u 153 512 377 0.703 2.555 2.347

Or, if you prefer:

(client)
rgb at ganesh|T:150>ntptrace
localhost.localdomain: stratum 4, offset 0.000020, synch distance 0.11975
bigbang.phy.duke.edu: stratum 3, offset -0.004264, synch distance 0.09537
clock.isc.org:  *Timeout*

(as I said, lots of servers don't like to talk to nonlocal clients; some
WON'T talk to unauthorized clients).  Bigbang does talk to clock.isc.org
at stratum 2.  Note that server addresses in our client /etc/ntp.conf's
are all cnames, so we can easily migrate to new servers should we need
to.

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