>>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
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions