On Apr 5, 2014, at 11:45 AM, Jason Rabel <[email protected]> wrote: [ ... ] > I have four stratum-1 servers connected to GPS receivers. The stratum-1 > servers are configured to be completely independent, they don't talk to each > other (for reasons beyond the scope of this post). They get their time solely > from their GPS module.
Your comment means a discussion of best practices of configuring these stratum-1s is also beyond the scope of answers to your post. Odd, but have this as you would.... [ ... ] > All three servers have: > > server S1-1 iburst > server S1-2 iburst > server S1-3 iburst > server S1-4 iburst > > Then they differ as follows: > > NTP1: > peer NTP2 iburst > peer NTP3 iburst > > NTP2: > peer NTP1 iburst > peer NTP3 iburst > > NTP3: > peer NTP1 iburst > peer NTP2 iburst Don't bother using more than one iburst entry per server. It's a waste of bandwidth and you've already setup 7 servers which provides massive redundancy...enough for many tens of thousands of clients, or even hundreds of thousands of clients at reasonable polling intervals. > Is there a command to check that they are setup properly in a peering > configuration? Start eveything up; wait a while; run ntpq -pcrv? > If all my S1 servers go offline, will the S2 servers still function since > their only valid time source would be each other? They'll be fine for several days. Howwever, if all of the S1s go down for an extended duration, and there are no other sources of time available to the S2s, then the S2 servers will increase their dispersion estimate, which will eventually cause downstream clients to prefer other time sources. Unless you have unusual and unrevealed requirements, it's not going to matter that much; clients which were already synced will likely stay within 10 ms of each other even after a week or two. > Or would I need to add some additional settings (like orphan)? I suppose that's a last resort. The first resort would be to add trusted non-local timesources. Pick a different one for each of the S2s. Regards, -- -Chuck _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
