On 03/11/14 10:56, Martin Burnicki wrote:
So as long as the NTP servers you find annoying provide the "same" time as the ones you'd like to have preferred, it doesn't matter from which your client get the time, since it's the same anyway.
If the annoying ones are consistent with the local ones, ntpd will derive the time from a combination of both of them. The system peer is only used for the stratum and root distance type measurements. Whilst prefer may change this, normally ntpd does not use a single source of upstream time.
Even though all the 4 remote servers showed much more jitter due to the long network path they were preferred by the Linux client, and the 2 local LANTIMEs were marked as "falsetickers" even though they showed much less jitter.
They shouldn't be treated as false tickers, unless they really are false tickers, or the remote servers are reporting incorrect root distances. The condition for becoming a false ticker is that you are in a minority after finding the largest subset with overlapping error bands. The remote servers should have large error bands which result in them overlapping with the narrow error bands of the GPS clocks.
Although there may be problems near the extreme edges of the error bands, you would need an extreme asymmetry before this would actually happen.
Even if you exceed the maximum number of true chimers, the local GPS sources should be preferred over the remote sources.
Having a local clock pseudo clock defined can mess this up as it will have a small error band, that may only be compatible with the remote servers. This shouldn't be a problem if you have two valid local sources and the remote sources are all truechimers.
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
