This is a discussion on "good enough" ntp configuration - NTP ; >>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 ...
>>Also when using NTP to set the prefer flag to your GPS source as that
>>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
>clock-hopping, but it causes unfortunate side effects when the PREFERed
>It reduces reliability and redundancy in the entire NTP hierarchy that uses
>server and can lead to all your machines becomming unsynchronized from the
>Time. PREFER should be avoided if you are interested in high availability
>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."
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
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