[ntp:questions] 2xGPS and 4x peers setup - disturbed by 5th and 6th peer

Martin Burnicki martin.burnicki at meinberg.de
Mon Nov 3 10:56:03 UTC 2014


(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



More information about the questions mailing list