In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Danny Mayer) writes: >Per Hedeland wrote: >> In article <[EMAIL PROTECTED]> Steve Kostecke >> <[EMAIL PROTECTED]> writes: >>> Here's the configuration you need: >>> >>>> [1.] participants are identically configured both as broadcast client >>>> and as broadcast server. >> >> So the part that says "operates in subnet configurations in all modes" >> is wrong? Do you know this for a fact and/or have tried it? I would >> imagine at least that if all the participating servers have each other >> configured as "peer", there shouldn't "technically" be a need for a >> broadcast setup. >> > >The biggest problem with peer is that you have to specify each and every >system you want to have participate in the scheme. With broadcast and >multicast you don't need to do that, they find each other.
Yes of course, and I guess this is appealing in some scenarios - in others it may be largely irrelevant, e.g. I'd think a typical usage case would be for someone setting up 2-4 "main internal" servers that get their time from Internet servers and and provide it to lots of internal clients. If you configure all those clients with the identity of the "main" servers anyway, dropping it into their own config files too is not a big deal, and it may be preferrable to setting up broadcast/multicast. Actually you'd likely want to configure those "main" servers as peers to each other even if you weren't using orphan mode, thus orphan mode just becomes a simple addition for increased reliability in case your Internet link goes down - and much better than the "local clock with minimum of 2 stratum difference" hack that has been the standard recommendation, of course. --Per Hedeland [EMAIL PROTECTED] _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
