[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