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

E-Mail Sent to this address will be added to the BlackLists Null at BlackList.Anitech-Systems.invalid
Thu Oct 30 18:08:21 UTC 2014


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


> Is it possible to restrict to those 4 peers only

If you really don't want them, just comment them out in your conf?


> send time to stratums lower than 2 as well

Nothing prevents sending time to lower stratums;
-----------------^^^^^^^
 and at the client "by default, servers of all strata are acceptable".

  However "a stratum filter selects just those servers with stratum considered useful"

   tos cohort 1    will cause it to not "avoid servers operating at the same stratum as the client"

   peering a server will might make it more likely to be included
   prefering a server will also make it more likely to be included


> 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)

{My wild guess would be lack of trust by t1
  perhaps missing or mismatched keys.}


-- 
E-Mail Sent to this address <BlackList at Anitech-Systems.com>
  will be added to the BlackLists.



More information about the questions mailing list