Double "prefer" configuration - NTP

This is a discussion on Double "prefer" configuration - NTP ; I've installed a fresh new PRS-10 frequency standard for my NTP servers. I want to set up a configuration where the server will function only on the PRS-10 PPS output in the absence of the GPS signal. For sure, this ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Double "prefer" configuration

  1. Double "prefer" configuration

    I've installed a fresh new PRS-10 frequency standard for my NTP
    servers. I want to set up a configuration where the server will
    function only on the PRS-10 PPS output in the absence of the GPS
    signal. For sure, this will be a failure condition. I tried something
    like this:

    server 127.127.20.1 minpoll 6 maxpoll 6 prefer
    fudge 127.127.20.1 flag3 0 time1 0.000 refid GPS

    server 127.127.22.1 minpoll 4 maxpoll 4 prefer
    fudge 127.127.22.1 flag3 1 time1 0.000 refid PPS

    The PPS signal is slaved from the GPS PPS signal. When the GPS data is
    absent (power supply cut-off - for tests) the server will synchronize
    on the PPS signal only (which is in phase with the GPS PPSs):

    remote refid st t when poll reach delay
    offset jitter
    ================================================== ============================
    127.127.20.1 .GPS. 0 l 135m 64 0 0.000
    0.000 0.004
    192.53.103.103 .PTB. 1 u 33 256 377 54.777
    0.314 3.395
    130.149.17.8 .PPS. 1 u 9 256 377 54.986
    0.850 0.100
    145.238.110.49 .1PPS. 1 u 4 256 377 54.876
    0.753 6.071
    18.7.7.75 .GPS. 1 u 31 256 377 204.818
    -33.562 5.309
    o127.127.22.1 .PPS. 0 l 11 16 377 0.000
    -0.001 0.004
    80.96.120.252 .PPS. 1 u 63 64 377 0.194
    0.003 0.004
    80.96.120.249 .PPS. 1 u 37 64 377 0.245
    -0.006 0.021
    192.53.103.104 .PTB. 1 u 33 256 377 55.326
    0.950 4.306
    18.7.21.64 .GPS. 1 u 25 256 377 194.803
    -27.663 10.021


    Is there something wrong ?

    Is there possible ot have two PPS signals in one server configuration ?


  2. Re: Double "prefer" configuration

    Things are good after several hours:

    ntp1# ntpq -nc pe
    remote refid st t when poll reach delay
    offset jitter
    ================================================== ============================
    127.127.20.1 .GPS. 0 l 17h 64 0 0.000
    0.000 0.004
    192.53.103.103 .PTB. 1 u 213 256 377 54.279
    -0.121 0.418
    130.149.17.8 .PPS. 1 u 195 256 373 54.698
    0.861 0.160
    145.238.110.49 .1PPS. 1 u 216 256 377 54.657
    0.741 7.154
    18.7.7.75 .GPS. 1 u 227 256 377 132.196
    2.639 0.519
    o127.127.22.1 .PPS. 0 l 5 16 377 0.000
    -0.001 0.004
    80.96.120.252 .PPS. 1 u 53 64 377 0.196
    -0.003 0.017
    80.96.120.249 .PPS. 1 u 50 64 377 0.204
    -0.009 0.014
    192.53.103.104 .PTB. 1 u 214 256 377 54.673
    0.831 1.437
    18.7.21.64 .GPS. 1 u 203 256 377 132.674
    2.338 0.323


  3. Re: Double "prefer" configuration

    After severeal hours things looks like this:

    ntpq> pe
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    GPS_NMEA(1) .GPS. 0 l 85h 64 0 0.000 0.000 0.004
    ptbtime1.ptb.de .PTB. 1 u 57 256 377 56.491 -0.062 0.132
    ntps1-1.cs.tu-b .PPS. 1 u 116 256 377 57.161 0.827 0.225
    ntp-p1.obspm.fr .1PPS. 1 u 65 256 373 57.027 0.541 5.938
    gps-2.mit.edu .GPS. 1 u 125 256 377 133.034 2.194 0.270
    oPPS(1) .PPS. 0 l 10 16 377 0.000 0.000 0.004
    ntp2.usv.ro .PPS. 1 u 61 64 377 0.198 0.003 0.007
    ntp3.usv.ro .PPS. 1 u 14 64 377 0.240 0.003 0.005
    ptbtime2.ptb.de .PTB. 1 u 33 256 377 55.610 1.183 0.334
    gps-1.mit.edu .GPS. 1 u 84 256 377 132.648 2.118 0.369


    Is there anybody able to emmit an oppinion if this configuration (with
    two prefer weywords) is good enough for a stable server ?


  4. Re: Double "prefer" configuration

    Eugen COCA wrote:
    > After severeal hours things looks like this:
    >
    > ntpq> pe
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > GPS_NMEA(1) .GPS. 0 l 85h 64 0 0.000 0.000 0.004
    > ptbtime1.ptb.de .PTB. 1 u 57 256 377 56.491 -0.062 0.132
    > ntps1-1.cs.tu-b .PPS. 1 u 116 256 377 57.161 0.827 0.225
    > ntp-p1.obspm.fr .1PPS. 1 u 65 256 373 57.027 0.541 5.938
    > gps-2.mit.edu .GPS. 1 u 125 256 377 133.034 2.194 0.270
    > oPPS(1) .PPS. 0 l 10 16 377 0.000 0.000 0.004
    > ntp2.usv.ro .PPS. 1 u 61 64 377 0.198 0.003 0.007
    > ntp3.usv.ro .PPS. 1 u 14 64 377 0.240 0.003 0.005
    > ptbtime2.ptb.de .PTB. 1 u 33 256 377 55.610 1.183 0.334
    > gps-1.mit.edu .GPS. 1 u 84 256 377 132.648 2.118 0.369
    >
    >
    > Is there anybody able to emmit an oppinion if this configuration (with
    > two prefer weywords) is good enough for a stable server ?
    >


    I would drop gps-1.mit.edu and gps-2.mit.edu. Their delays are high
    enough that they are unlikely to be selected as a synchronization
    source. Any benefit you might gain is probably too small to justify
    using them.

    Is something wrong with your GPS? It appears to have been inoperative
    for 85 hours!

    I don't know about two "prefer" keywords. I had the impression that
    only one was supported but I could be wrong.

    Other than that, it looks fine to me!


  5. Re: Double "prefer" configuration

    > I would drop gps-1.mit.edu and gps-2.mit.edu. Their delays are high
    > enough that they are unlikely to be selected as a synchronization
    > source. Any benefit you might gain is probably too small to justify
    > using them.


    All other servers except the GPS and the PPS are with the "noselect"
    keyword and are only for statistics there.

    https://ecoca.eed.usv.ro/mrtg/ntp1us...tg_offset.html

    >
    > Is something wrong with your GPS? It appears to have been inoperative
    > for 85 hours!


    Yes, the GPS is powered off. There is only the PPS signal from the
    rubidium frequency standard working.

    > I don't know about two "prefer" keywords. I had the impression that
    > only one was supported but I could be wrong.
    >


    This is the question. Without the second "prefer" in the PPS driver,
    after the GPS "death" the server will remain without any source
    for synchronization. I make an experiment with:

    server 127.127.20.1 minpoll 6 maxpoll 6 prefer
    fudge 127.127.20.1 flag3 0 time1 0.000 refid GPS

    server 127.127.22.1 minpoll 4 maxpoll 4 prefer
    fudge 127.127.22.1 flag3 1 time1 0.000 refid PPS

    and I asked if any NTP developer could tell me if there is something
    wrong in what I'm trying to do.

    > Other than that, it looks fine to me!


    Thank you !


  6. Re: Double "prefer" configuration

    In article <1172813762.918249.173020@b35g2000cwb.googlegroups. com>,
    "Eugen COCA" writes:
    >After severeal hours things looks like this:
    >
    >ntpq> pe
    > remote refid st t when poll reach delay offset jitter
    >================================================== ============================
    > GPS_NMEA(1) .GPS. 0 l 85h 64 0 0.000 0.000 0.004
    > ptbtime1.ptb.de .PTB. 1 u 57 256 377 56.491 -0.062 0.132
    > ntps1-1.cs.tu-b .PPS. 1 u 116 256 377 57.161 0.827 0.225
    > ntp-p1.obspm.fr .1PPS. 1 u 65 256 373 57.027 0.541 5.938
    > gps-2.mit.edu .GPS. 1 u 125 256 377 133.034 2.194 0.270
    >oPPS(1) .PPS. 0 l 10 16 377 0.000 0.000 0.004
    > ntp2.usv.ro .PPS. 1 u 61 64 377 0.198 0.003 0.007
    > ntp3.usv.ro .PPS. 1 u 14 64 377 0.240 0.003 0.005
    > ptbtime2.ptb.de .PTB. 1 u 33 256 377 55.610 1.183 0.334
    > gps-1.mit.edu .GPS. 1 u 84 256 377 132.648 2.118 0.369


    >Is there anybody able to emmit an oppinion if this configuration (with
    >two prefer weywords) is good enough for a stable server ?


    Try connecting the first and disconnecting the second.

    I haven't looked at the code in a while. I think that the
    prefer-ed server gets stored in a global variable where
    the PPS/ATOM driver can get it. Thus only the last
    one gets used.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  7. Re: Double "prefer" configuration

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote:

    > I haven't looked at the code in a while. I think that the
    > prefer-ed server gets stored in a global variable where
    > the PPS/ATOM driver can get it. Thus only the last
    > one gets used.


    There is a global, sys_prefer, but there's also FLAG_PREFER that
    is marked in the config for each server with "prefer". sys_prefer
    gets set to the last server with FLAG_PREFER that survives the
    clustering (?) algorithm.

    In this case, it might be better to config the PPS source in ntp.conf
    before the GPS source, so that if the GPS is good it will become
    sys_prefer.

    With the GPS inoperative and only the PPS running, there's no source
    for numbering the seconds, which is what the prefer peer is supposed
    to be doing for refclock_atom; I don't know if this is a safe config.

    --
    Ronan Flood

  8. Re: Double "prefer" configuration

    Eugen,

    The prefer scheme is not designed for more than one candidate. If more
    than one peer is so designated, the code chooses the last one in the
    configuration file.

    Dave

    Eugen COCA wrote:

    > After severeal hours things looks like this:
    >
    > ntpq> pe
    > remote refid st t when poll reach delay offset jitter
    > ================================================== ============================
    > GPS_NMEA(1) .GPS. 0 l 85h 64 0 0.000 0.000 0.004
    > ptbtime1.ptb.de .PTB. 1 u 57 256 377 56.491 -0.062 0.132
    > ntps1-1.cs.tu-b .PPS. 1 u 116 256 377 57.161 0.827 0.225
    > ntp-p1.obspm.fr .1PPS. 1 u 65 256 373 57.027 0.541 5.938
    > gps-2.mit.edu .GPS. 1 u 125 256 377 133.034 2.194 0.270
    > oPPS(1) .PPS. 0 l 10 16 377 0.000 0.000 0.004
    > ntp2.usv.ro .PPS. 1 u 61 64 377 0.198 0.003 0.007
    > ntp3.usv.ro .PPS. 1 u 14 64 377 0.240 0.003 0.005
    > ptbtime2.ptb.de .PTB. 1 u 33 256 377 55.610 1.183 0.334
    > gps-1.mit.edu .GPS. 1 u 84 256 377 132.648 2.118 0.369
    >
    >
    > Is there anybody able to emmit an oppinion if this configuration (with
    > two prefer weywords) is good enough for a stable server ?
    >


  9. Re: Double "prefer" configuration

    Dave,

    My idea is to have a configuration that work in the absence of the GPS
    signal (with the initial start-up with the GPS signal).

    The configuration with two "prefer" keywords is the only one that
    assure the server survival with the PPS Rubidium source connected and
    working and the GPS signal absent. Any other configuration I've tested
    doesn't work.

    Are there any other possibile configurations in order to obtain the
    initial target ?



+ Reply to Thread