Tim, I don't know where you got "the docs", but it appears not to be from the official documentation. There is an explanation with diagrams at http://www.eecis.udel.edu/~mills/ntp/html/assoc.html#orphan.
Dave [email protected] wrote: >On Sep 15, 5:14 am, Harlan Stenn <[email protected]> wrote: > > >>Orphan mode sure sounds to me like what you are looking for. >>-- >>Harlan Stenn <[email protected]>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 >them >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, >tim > >_______________________________________________ >questions mailing list >[email protected] >https://lists.ntp.org/mailman/listinfo/questions > > _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
