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?}
Hi
In my case that's been a figure large enough to span the range
of offset variation (both Garmin and Sure have been used). For
a while Garmin weren't even usable until a firmware fix was
released, as the range of offsets exceeded one second.
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
