[EMAIL PROTECTED] writes: >> >> What this has to do with not believing in the algorithm I have no idea. If >> ntp runs from a refclock that is EXACTLY the default behaviour. Running on >> a local private network where you are referencing your own server, that >> behaviour is also fine. The reason for the backup to long poll intervals is >> a) to save the public servers from flooding, and b)to discipline the local >> clock's drift rate in case there are long periods of disconnection from the >> net. If you have constant connection and it is your own server, neither of >> those apply, and short polling is better.
>Thanks, that is the answer I was looking for. In our case, ntp load >on the ntp server and the network is irrelevant. We are just seeking >the best synchronization possible, short of getting a PPS signal to >every machine. I will change the machine not to use broadcast mode >and rely on min polling with maxpoll set to minpoll as well. I will >also enable iburst, as the docs indicate that it might increase >performance by loading up the network a bit more. On a local network, I doubt it. It would primarily "prime the pump" by having the IP addresses/mac addresses already in the network system when the ntp packet is sent. But on a local network that would almost certainly not be a problem, especially not with a poll interval of 16 sec. The decay time of router memories is usually longer than that. Now if you have 10^7 machines on your local net, then I might worry. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
