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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
