>>Also when using NTP to set the prefer flag to your GPS source as that would >>probably be the most accurate time and prevent NTP from hopping around >>sources or choosing the wrong one. > >I can't agree with that statement. The PREFER keyword can improve sync and reduce >clock-hopping, but it causes unfortunate side effects when the PREFERed clock has >problems. > >It reduces reliability and redundancy in the entire NTP hierarchy that uses that >server and can lead to all your machines becomming unsynchronized from the One True >Time. PREFER should be avoided if you are interested in high availability rather >than sub-millisecond accuracy.
>From the documentation: "The prefer peer can still be discarded by the sanity checks and intersection algorithm, of course, but it will always survive the clustering algorithm." http://www.ece.udel.edu/~mills/ntp/html/prefer.html The reason I mentioned the PREFER use was that because he does have a pair of highly accurate local time sources, but of course you would still want more than just two source for a "proper" group. Unless he buys more local hardware then he would probably use Stratum 1 or 2 servers over the Internet. I have seen on my own machine when purposefully testing with just one (and maybe two - it has been a while since I did all the experiments) Stratum 0 or 1 source(s) where it says one time, but if I throw in say five servers over the Internet if they happen to say a different time it will choose one of them instead and toss out the local source(s) (which I know are more correct). The uncertainty of the round-trip network delay is the biggest obvious culprit, but without preferring your local source you can potentially end up with the machine trying to sync to an incorrect time (though even at that we are talking still in the tens of ms range). Just my two cents... _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
