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

Martin Burnicki martin.burnicki at meinberg.de
Fri Oct 31 10:57:42 UTC 2014


Ardi (Peter?),

wow, the way you are quoting makes it *really* hard to read your posts, 
so this can just prevent folks here on the list from replying.

ardi wrote:
>
> ardi wrote:
>> having 2 GPS sources and 4 peers to each other (see below the setup),
>> When turning on 5th and 6th peers, they disturb my setup.
>
>> root at local.a2:~# ntpq -pn
>>       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
>> -local.a1   xx.xx.xx.a1         2 u   12   16  377    0.286    0.043   0.015
>> +remote.b1  yy.yy.yy.b1         2 u    3   16  377   33.555   -0.016   0.055
>> -remote.b2  yy.yy.yy.b2         2 u    7   16  377   33.700    0.049   0.281
>> +local-annoying.c1  yy.yy.yy.c1 2 u   12   16  377    0.216    0.043   0.044 <--why? how to get rid of it?
>> +local-annoying.c2  yy.yy.yy.c2 2 u   12   16  377    0.326    0.043   0.03  <--why? how to get rid of it?
>
> I'm missing why you find those two indicated so disturbing,
>
>   They both have lower latency than remote.yy, remote.b1, remote.b2
>   They both have lower jitter than remote.yy and remote.b2
>   Their offset is in line with local.a1, and less than remote.b2 and remote.yy
>
> Ardi:
> ===ardi_start
> let's skip this part - i can come back to this later.
> ===ardi_end
>> Is it possible to restrict to those 4 peers only
>
> If you really don't want them, just comment them out in your conf?
>
> Ardi:
> ===ardi_start
> it is not question of commenting them - i can do it easily.
> imagine a hypothetical situation, when somebody defines on network these extra 2 servers on purpose to "inflict" the existing setup.
> I would like to avoid it by correct setup on those 2 GPS sources and 4 peers.

If I understand this correctly then "local.xx" and "remote.yy" are not 
GPS sources in the sense that the NTP daemon gets the time directly from 
a GPS hardware refclock. Instead this looks like the client just polls 2 
NTP servers claiming to be synchronized to GPS, one of them on the local 
network and the other one at a remote site.

> what i would like to achieve is that 4 peers getting time only from GPS sources
> and from each other and all stratum3 servers and below can have the possibility to get time only from any of those 4 peers.

If it's correct what I wrote above then at least the remote "GPS" source 
provides much more jitter than the "local-annoying" time sources, so it 
wouldn't be even surprising if ntpd preferred the "local-annoying" time 
sources over the "remote.yy" GPS source.

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.

[...]
> ===ardi_start
> preferring a server is already included:
> server xx.xx.xx.a2 minpoll 4 maxpoll 4 prefer
> server xx.xx.xx.a1

Also see the link above to understand why "prefer" may not always work 
as you might expect.

> ===ardi_end
>> xx.xx.xx.a2 .INIT. 16 u - 16 0 0.000 0.000 0.000 <---------does not get time from xx.xx.xx.a2!!!!
>
> (Shrug), looks like it is not getting packets back from a2.
>   If you get and decode the association information,
>    you might find out more; e.g.
> ntpq -crv -clpe -clas -c "rv &1" (or whichever association index number is relevant)
>
> Ardi:
>
> ===ardi_start
> this is the output on xx.xx.xx.t1 (stratum3)
>
> xx.xx.xx.t1 # ntpq -crv -clpe -clas -c "rv &1"
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> version="ntpd 4.2.6p2 at 1.2194-o Sun Oct 17 13:35:13 UTC 2010 (1)",
> processor="x86_64", system="Linux/2.6.32-5-amd64", leap=00, stratum=3,
> precision=-22, rootdelay=3.731, rootdisp=45.673, refid=xx.xx.xx.a1,
> reftime=d7fdc99c.3e3638ca  Fri, Oct 31 2014  9:41:00.243,
> clock=d7fdcbbd.e46ee56a  Fri, Oct 31 2014  9:50:05.892, peer=64477,
> tc=10, mintc=3, offset=1.619, frequency=5.247, sys_jitter=1.649,
> clk_jitter=1.024, clk_wander=0.071
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   xx.xx.xx.a2 .INIT.          16 u    -   16    0    0.000    0.000   0.000
> *xx.xx.xx.a1 xx.xx.xx.xx    2 u  545 1024  377    3.243    1.619   1.649
>
> ind assid status  conf reach auth condition  last_event cnt
> ===========================================================
>    1 64476  8011   yes    no  none    reject    mobilize  1
>    2 64477  963a   yes   yes  none  sys.peer    sys_peer  3
> associd=64476 status=8011 conf, sel_reject, 1 event, mobilize,
> srcadr=xx.xx.xx.a2, srcport=123, dstadr=xx.xx.xx.t1,
> dstport=123, leap=11, stratum=16, precision=-22, rootdelay=0.000,
> rootdisp=0.000, refid=INIT,
> reftime=00000000.00000000  Mon, Jan  1 1900  1:00:00.000,
> rec=00000000.00000000  Mon, Jan  1 1900  1:00:00.000, reach=000,
> unreach=9616, hmode=3, pmode=0, hpoll=4, ppoll=4, headway=2,
> flash=1600 peer_stratum, peer_dist, peer_unreach, keyid=0, offset=0.000,
> delay=0.000, dispersion=15937.500, jitter=0.000, xleave=0.020,
> filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
> filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
> filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
> xx.xx.xx.t1 #
>
> it can be seen that it does not accept time from xx.xx.xx.a2

This sounds like the upstream server isn't reachable, or claims to be 
*not* synchronized.

> why should i need to define peer in its config?
> ===ardi_end
>
> {My wild guess would be lack of trust by t1
>    perhaps missing or mismatched keys.}
>
> Ardi:
> ===ardi_start
> why should i need keys toward stratum3? in case a-case used, it works
>        without keys ...

You have to take care when using the word "peer".

 From the role in an NTP mesh 2 peers ( configured with "peer a.b.c.d") 
are NTP servers which can affect the time of each other. In this case 
the configured peers should use authentication to prevent other NTP 
nodes from messing up the system time of the peering NTP servers.

In the output of a normal NTP client the configured servers are also 
referred to as "peers", for example the "system peer" is labelled with a 
'*' in the output of "ntpq -p", even though this can be an upstream NTP 
server to which the client sends client request, or a peer to which the 
machine sends active or passive peer packets, or a hardware refclock 
directly connected to the local machine.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list