David Woolley <[email protected]> wrote: > 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.
You probably mean "locally connected GPS sources" where Martin means "NTP servers with local GPS sources on the local network". Those are not heavily preferred over remote NTP servers, just as Martin describes, at least in the production version of ntpd. "shouldn't be treated", sure. But reality is a bit different. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
