[ntp:questions] question regarding NTP configuration for clusters, and "cluster time" stability

rotordyn@yahoo.com rotordyn1 at gmail.com
Mon Sep 28 03:08:18 UTC 2009

On Sep 15, 5:14 am, Harlan Stenn <st... at ntp.org> wrote:
> Orphan mode sure sounds to me like what you are looking for.
> --
> Harlan Stenn <st... at ntp.org>http://ntpforum.isc.org - be a member!

Quick question. The docs say
  "Orphan Mode allows a group of ntpds to automonously
   select a leader in the event that all real time sources
   become unreachable (i.e. are inaccessible)."

What if, among this group of ntpds, only a subset consider that
all time sources have become unreachable? I'll use real numbers
to make it a bit clearer: I have 32 nodes in a cluster, and all of
are interconnected with private cluster networks, while 4 of them
also have connections to a corporate LAN. If my time reference
becomes unavailable, all 4 will see that they have no external
source. (Reading ntp_proto.c, it looks like the first ntpd to see
this state declares itself the orphan parent?)
  But what if 1 or 2 of these group of 4 lose LAN connections?
They will go into orphan mode, while the other 2 do not. This
seems that it could cause the group of 4 to move in different
directions timewise. Or do the two that still have contact with
the external reference also go into orphan mode, and ignore
the external reference? It appears not, but I'm trying to avoid
the scenario where node's clocks in the cluster drift apart.
(Since I care far more about the nodes following a single
"cluster time" than any individual nodes fidelity to UTC)

  Our testing with peers that are clients of an external reference
while at the same time servers to the internal leaf nodes
shows that this divergence is possible.

  If it isn't possible to force this group of ntpds to prioritize
a common cluster time over UTC, we'll need to define a single
master node statically. And then handle high-availability
issues externally to the reference implementation in our
clustering software.

thanks again,

More information about the questions mailing list