[ntp:questions] 2xGPS and 4x peers setup - disturbed by 5th and 6th peer
Martin Burnicki
martin.burnicki at meinberg.de
Tue Nov 4 09:06:40 UTC 2014
E-Mail Sent to this address will be added to the BlackLists wrote:
> Martin Burnicki wrote:
>> We have had a case where a customer had one local
>> computing center and 2 ones at different remote locations.
>> In each of the computing centers were 2 GPS
>> controlled LANTIME NTP servers installed.
>>
>> In the local computing center there was also a Linux server
>> running ntpd which had all 6 LANTIMEs configured as time sources.
>>
>> Unfortunately the internet connection of the local
>> computing center seemed to have an asymmetry in the
>> packet delay, so from the Linux client's point of view
>> all 4 LANTIMEs in the remote locations seemed to have a
>> time offset in the same range, a few milliseconds,
>> compared to the 2 local LANTIME.
>>
>> 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.
>>
>> If I remember correctly then the Linux client was
>> running 4.2.6p?, and a test with a -dev version of ntpd
>> showed that the newer ntpd preferred the 2 local
>> LANTIMEs over the 4 remote ones. This seems to indicate
>> that the weight put on different criteria
>> in the selection algorithm has changed over versions,
>> and the newer versions of ntpd act more like you'd expect.
>
> TOS MinDist affects this.
>
> e.g. in the case of serial nema and pps, sometimes the mindist
> needs to be increased from 1ms to perhaps 20ms,
> and I've seen as much as 400ms (fairly often);
> {which makes me wonder if the PPS is inverted?}
I know, but you have misunderstood.
In the case I mentioned there were 6 GPS disciplined NTP servers
(Meinberg LANTIMEs) involved, and one Linux machine as NTP client. Of
course each of the LANTIMEs was synchronized properly to GPS, and the
problem was *not* that the NTP servers got a wrong time from their GPS
receivers.
The client was configured to poll all 6 NTP servers, 2 of which were
available on the local network which provided low jitter, but the other
4 NTP servers were only reachable via a WAN connection and thus showed
more jitter than the servers on site.
In addition, the WAN connection had a slight asymmetry, so the mean
offset computed by the NTP client for the servers at the remote location
was different than the mean offset computed for the 2 NTP servers on the
local network.
Thus the local NTP client preferred the 4 servers located on remote site
over the 2 servers on the local site, even though the local ones were
"better" and showed lower jitter.
I've just looked through my email archives and saw that the NTP client
was initially running v4.2.2 (shipped with the installed Linux version),
and a test with a current 4.2.7 version showed that the current version
worked more like I'd expect, i.e. indeed it preferred the 2 local
servers with lower jitter over the 4 remote servers with higher jitter.
So of course 4.2.2 was very much outdated, but once more this shows how
important it is to mention the version of NTP package running on the
involved nodes.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
More information about the questions
mailing list