Guys, The local clock driver has always been a crock and is often misused. Its purpose is as the ultimate backup should all synchronization sources be lost. The misuse occurs when folks try to have more than one local clock driver in the interests of additional redundancy. The actual scenario was not what was intended; two local clock machines would find each other and count to infinity in the classic Bellman Ford scenario.
The orphan mode is designed to avoid infinity. The idea is that two or more redundant servers, perhaps synchronized to multiple sources, share a common Ethernet or run symmetric mode with each other. If all sources fail, the redundant servers will operate at the orphan stratum and use an election algorithm to decide which one of them synchronizes the subnet. If a single server is used to import time and all sources fail, operating is like with the local clock driver. The immediately ascendent clients will see the reference ID as the loopback address. Dave Steve Kostecke wrote: > On 2007-10-02, Richard B. Gilbert <[EMAIL PROTECTED]> wrote: > > >>Steve Kostecke wrote: >> >> >>>At least one of the nodes will need to be configured to poll an >>>adequate number of remote time servers. >> >>I thought that the whole point of Orphan Mode was for situations >>where no remote time servers were available; e.g. your home network >>is without an internet connection and you have no hardware reference >>clock! > > > Orphan Mode allows a group of ntpds to autonomously select a leader when > no legitimate time sources are reachable. Possible uses include the > "synchronization" of "time islands" and the provision of a "clock of > last resort" for a LAN which normally has access to legitimate time > sources. > > My answer to the OP presumed that application was not a "time island". > Obviously, if this is not the case, there is not need to configure > remote time servers. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
