In article <[EMAIL PROTECTED]>, Stewart Pelegan <[EMAIL PROTECTED]> wrote:
> Right now, I've got the following in the clients' ntp.conf: > broadcastclient > multicastclient 224.0.1.1 It's not very sensible to have both. You should get things working properly without multi/broad-cast before you add this complication. > enable auth monitor I'm not an expert on auth, but you should not have it, initially, when debugging without broadcast. I think it may be needed for broadcast modes. I cannot see any indication of the key files that it must need. > and the servers have: > server 127.127.5.0 prefer > server 10.20.30.41 > server 127.127.1.0 > fudge 10.20.30.41 stratum 1 The stratum 1 here will be ineffective. > fudge 127.127.1.0 stratum 1 Setting a local clock to stratum one is not something you want to do lightly. I can see no valid reason for doing it here. I am pretty sure that having this local clock will make the configuration unstable when the radio clocks fail. The only time to have one at stratum one is if the local clock is being disciplined by something other than ntpd, and even then there is the problem that ntpd will not know if that source has failed. > broadcast 224.0.1.1 ttl 6 ttl 6 is too large if all the clients are on the same sub-net. Simple broadcast would be enough. > This is a PRIVATE message. If you are not the intended recipient, please Nothing posted to comp.protocols.time.ntp is PRIVATE, and therefore nothing posted to the feeder email gateway is PRIVATE. However, the gateway is broken, so, if possible, please use the newsgroup directly. I am assuming that the legal notice is bogus, at least as to confidentiality and I can ignore it and copy into my reply. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
