(I've already sent this reply on Oct 31, but unfortunately only to ardi'
email address instead of the news group)
ardi wrote:
Hello Martin,
GPS sources=Meinberg LANTIME time server with antenna that uses
GPS: Satellite receiver for the Global Positioning System.
Great!
do you speak about bigger jitter in remote.yy?
Yes.
remote refid st t when poll reach delay offset jitter
========================================================
*local.xx .GPS. 1 u 1 16 377 0.344 -0.037 0.046
+remote.yy .GPS. 1 u - 16 377 34.258 -0.074 0.273
In the scenario above the local NTP server is what NTP calls the "system
peer" , and the remote server is a "candidate" which means it can become
the "system peer" if the local NTP server becomes unreachable.
There is a potential problem if for some reason both the local and
remote NTP server claim to be synchronized, but provide a time which
differs too much. In this case the clients of these 2 servers might
accept neither of the 2 since the clients don't know which one has the
"right" time.
See also:
http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.
Again, the page I've mentioned below explains the details:
Have you had a look at:
http://doc.ntp.org/4.2.6p5/prefer.html#peer
This explains the way ntpd selects the time sources it uses preferably.
the problem is would like to exclude these annoying time sources via
configuring ntp.conf on my 4 peers correctly.
If you configure several time sources for an NTP client then the client
polls them all, and based on the results (jitter, dispersion, ...) from
each NTP server it selects the ones which agree at most on the same time
and provide the most accurate results.
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.
Instead, you need to think about the case if the GPS controlled servers
and the other machines disagree about the right time. In this case 3 or
more other servers might "overvote" your 2 GPS controlled servers, which
is probably not what you want.
Also see the link above to understand why "prefer" may not always work
as you might expect.
I have thought the server is sets priority according to lines in ntp.conf.
does this mean if jitter on remote GPS is much bigger than the jitter
of 3 peers (or any of them), then this GPS source is omitted/skipped?
Exactly.
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.
This also shows how important it is to mention the versions of the
involved NTP nodes.
This sounds like the upstream server isn't reachable, or claims to be
*not* synchronized.
well, this is the error/problem i would like to solve.
is there a line missing in the stratum3 server's ntp.conf file?
If a line would be missing then the NTP server would not be listed in
the output of "ntpq -p".
If the association can't be established (i.e remains in the .INIT. state
this can be a network problem (routing, firewall), the NTP server can be
down, or can may not claim to be synchronized, e.g. if the GPS antenna
has been disconnected.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
