Question to NTP developers - NTP

This is a discussion on Question to NTP developers - NTP ; I have an obsesion regarding the "PPS SYNC DISABLED" message. So, please tell me how is this message generated by the ntpd service ! I'm a hardware specialist and, if it is a hardware related problem, I'm decided to try ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: Question to NTP developers

  1. Question to NTP developers

    I have an obsesion regarding the "PPS SYNC DISABLED" message.

    So, please tell me how is this message generated by the ntpd service !
    I'm a hardware specialist and, if it is a hardware related problem, I'm
    decided to try to solve this.

    I'll try, as a first solution, to supply the GPS receivers whith a very
    good 5VDC voltage.

    Thank you !


  2. Re: Question to NTP developers

    The comment just above the line in ntp_loopfilter.c that generates that
    message says:

    Declare PPS kernel unsync if the pps signal has not been heard for
    a few minutes.

    so I'd guess the problem is that ntpd had not heard any pps signals for
    PPS_MAXAGE for 120 seconds (the current value of PPS_MAXAGE in
    ntp_loopfilter.c).

    H

  3. Re: Question to NTP developers

    Thanks for support.

    In the log, the standard listing is as follows:

    Aug 23 21:55:39 ntp2 ntpd[56501]: kernel time sync disabled 2307
    Aug 23 21:56:36 ntp2 ntpd[56501]: pps sync disabled
    Aug 23 21:56:44 ntp2 ntpd[56501]: kernel time sync enabled 2107


    I have 2 servers, ntp1 and ntp2, with the SAME signals (RXD, GND and
    PPS from only one GPS receiver). The moments the messages PPS SYNC
    DISABLED appear are NOT THE SAME. This is why I do not suspect only the
    hardware part of the systems.

    This is ntp1's log:

    Aug 23 19:13:25 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 19:14:19 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 19:14:30 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 19:26:20 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 19:27:17 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 19:27:26 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 20:08:11 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 20:09:07 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 20:09:16 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 20:21:06 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 20:22:03 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 20:22:10 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 21:02:50 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 21:03:46 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 21:03:56 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 21:06:06 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 21:07:00 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 21:07:10 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 22:12:42 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 22:13:38 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 22:13:45 ntp1 ntpd[91813]: kernel time sync enabled 2107
    Aug 23 22:39:34 ntp1 ntpd[91813]: kernel time sync disabled 2307
    Aug 23 22:40:30 ntp1 ntpd[91813]: pps sync disabled
    Aug 23 22:40:39 ntp1 ntpd[91813]: kernel time sync enabled 2107


    and this is ntp2's log:

    Aug 23 20:54:41 ntp2 ntpd[56501]: kernel time sync disabled 2307
    Aug 23 20:55:39 ntp2 ntpd[56501]: pps sync disabled
    Aug 23 20:55:47 ntp2 ntpd[56501]: kernel time sync enabled 2107
    Aug 23 21:55:39 ntp2 ntpd[56501]: kernel time sync disabled 2307
    Aug 23 21:56:36 ntp2 ntpd[56501]: pps sync disabled
    Aug 23 21:56:44 ntp2 ntpd[56501]: kernel time sync enabled 2107

    As you may see, with the same signals combination, but different
    computer configuration (ntp1 is Intel PII and ntp2 is AMD K6III) the
    logs look differrent.

    Could you figure out any ideas ?

    Thank you !

    P.S. My main problem is that ntp1, after severals days, seems to loose
    completly the PPS sync, and it could not be synced again without user
    intervention.


  4. Re: Question to NTP developers

    You're gonna have to look at the code.

    Do you have a program that just looks at the incoming serial data and lets
    you know if either the pps signals are not arriving or for some reason your
    GPS is saying "Here's some data, but due to X PPS is currently disabled".

    H

  5. Re: Question to NTP developers


    Harlan Stenn wrote:

    > for some reason your
    > GPS is saying "Here's some data, but due to X PPS is currently disabled".
    >
    > H


    There is only one GPS receiver and, of course, one PPS hardware signal.
    How could the PPS signal be present on one server and absent on the
    other in the same time ? This is my problem and I suspect 50% the
    hardware on the motherboards and 50% the software (OS + NTP) !

    And this is why I put only one receiver on both servers to diagnose the
    problem.

    And, very strange, when the server stop syncing on the GPS, only and
    many PPS SYNC DISABLED messages appear in the log. Just restarting the
    ntpd service will solve the problem. This is another strange behaviour
    - why, if it is a hardware problem, restarting the service eliminate it
    ?

    Still searching ...


  6. Re: Question to NTP developers


    >There is only one GPS receiver and, of course, one PPS hardware signal.
    >How could the PPS signal be present on one server and absent on the
    >other in the same time ? This is my problem and I suspect 50% the
    >hardware on the motherboards and 50% the software (OS + NTP) !


    What type of GPS receiver are you using? Have you turned on
    logging and looked in (both) clockstats?

    Some GPS receivers turn off the PPS signal when they know they
    don't have a good signal. Some leave it running.

    Most GPS receiver give you some sort of status indication to tell you if
    the signal they are receiving is reasonable. For example, here are
    a few lines from a receiver that uses NMEA:
    53963 17392.501 127.127.20.2 $GPRMC,044953,A,3726.0639,N,12212.1673,W,000.3,105 .4,160806,015.3,E*6B
    53963 17456.337 127.127.20.2 $GPRMC,045057,V,3726.0630,N,12212.1664,W,,,160806, 015.3,E*7C
    53963 17519.324 127.127.20.2 $GPRMC,045200,V,3726.0630,N,12212.1664,W,,,160806, 015.3,E*7C
    53963 17584.547 127.127.20.2 $GPRMC,045305,A,3726.0804,N,12212.1886,W,000.1,050 .9,160806,015.3,E*69
    53963 17647.534 127.127.20.2 $GPRMC,045408,A,3726.0806,N,12212.1892,W,000.0,064
    53963 17712.586 127.127.20.2 $GPRMC,045513,A,3726.0805,N,12212.1929,W,000.1,096


    The V means bad, and the A means good. So the signal dropped out for
    somewhere between a bit over a minute and three minutes.

    One possible reason why your two boxes are not doing the same thing is
    that they aren't actually looking at the same data. The info above
    is only part of data that goes over the serial line. Normally NMEA
    receivers send a line of info every second (or every N seconds).
    ntpd only looks for info every 64 seconds. (handwave, that's probably
    not right but it's close enough) If you have two boxes looking
    at the same signal they may be out of phase.

    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


  7. Re: Question to NTP developers


    Hal Murray wrote:

    > What type of GPS receiver are you using? Have you turned on
    > logging and looked in (both) clockstats?
    >
    > Some GPS receivers turn off the PPS signal when they know they
    > don't have a good signal. Some leave it running.
    >


    Yes, I have turned on all possible loggings on ntpd. There is nothing
    strange to see.

    I have Garmin GPS18LVC - correctly configured (without PPS Diabled or
    other things - like power savings features).

    > Most GPS receiver give you some sort of status indication to tell you if
    > the signal they are receiving is reasonable. For example, here are
    > a few lines from a receiver that uses NMEA:
    > 53963 17392.501 127.127.20.2 $GPRMC,044953,A,3726.0639,N,12212.1673,W,000.3,105 .4,160806,015.3,E*6B
    > 53963 17456.337 127.127.20.2 $GPRMC,045057,V,3726.0630,N,12212.1664,W,,,160806, 015.3,E*7C
    > 53963 17519.324 127.127.20.2 $GPRMC,045200,V,3726.0630,N,12212.1664,W,,,160806, 015.3,E*7C
    > 53963 17584.547 127.127.20.2 $GPRMC,045305,A,3726.0804,N,12212.1886,W,000.1,050 .9,160806,015.3,E*69
    > 53963 17647.534 127.127.20.2 $GPRMC,045408,A,3726.0806,N,12212.1892,W,000.0,064
    > 53963 17712.586 127.127.20.2 $GPRMC,045513,A,3726.0805,N,12212.1929,W,000.1,096
    >
    >
    > The V means bad, and the A means good. So the signal dropped out for
    > somewhere between a bit over a minute and three minutes.


    Not my case ! The receiver is mounted with almost 99% sky view. I've
    verified this for 3 weeks of loggings after installing.

    >
    > One possible reason why your two boxes are not doing the same thing is
    > that they aren't actually looking at the same data.


    Hardware the two boxes are looking at the same data (as the signal are
    hardwired connected at the same GPS).

    The info above
    > is only part of data that goes over the serial line. Normally NMEA
    > receivers send a line of info every second (or every N seconds).
    > ntpd only looks for info every 64 seconds. (handwave, that's probably
    > not right but it's close enough) If you have two boxes looking
    > at the same signal they may be out of phase.
    >


    My GPS is configured to send three strings (RMC, GLL and GSA) every
    second - I've verified this.

    > --
    > The suespammers.org mail server is located in California. So are all my
    > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    > commercial e-mail to my suespammers.org address or any of my other addresses.
    > These are my opinions, not necessarily my employer's. I hate spam.



  8. Re: Question to NTP developers


    >My GPS is configured to send three strings (RMC, GLL and GSA) every
    >second - I've verified this.


    I'd try turning off GLL and GSA. The extra work to send them may
    add jitter to the RMC messages. It's a long shot.

    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


  9. Re: Question to NTP developers

    Eugen COCA wrote:
    []
    > There is only one GPS receiver and, of course, one PPS hardware
    > signal. How could the PPS signal be present on one server and absent
    > on the other in the same time ? This is my problem and I suspect 50%
    > the hardware on the motherboards and 50% the software (OS + NTP) !


    ... another long shot - but do you convert the GPS signals to true RS-232
    levels, or simply use them as-is from the GPS18?

    David



  10. Re: Question to NTP developers


    Hal Murray wrote:
    > >My GPS is configured to send three strings (RMC, GLL and GSA) every
    > >second - I've verified this.

    >
    > I'd try turning off GLL and GSA. The extra work to send them may
    > add jitter to the RMC messages. It's a long shot.


    I've tried this several months ago and the result was the same. We may
    explain this as the interval between the two RMC strings (one second)
    have nothing to do with the PPS signal witch is delivered by another
    piece of hardware in the GPS receiver on another wire. The PPS sync in
    the kernel count on the signal on the DCD pin of the RS232 interface.

    P.S. Is there any NTP server without the "pps sync disabled" in his log
    ? Just curious about the hardware involved ...


  11. Re: Question to NTP developers


    David J Taylor wrote:

    > .. another long shot - but do you convert the GPS signals to true RS-232
    > levels, or simply use them as-is from the GPS18?
    >



    David,

    this could be a possible problem as the GPS receiver deliver signals
    from 0 to 5V and not true TIA-232 levels (-9V to +9V). I thought at
    this situation several months ago but I'm not sure if such a converter
    will not add too much jitter to the PPS signal (as it must be supplied
    with a separate voltage source).


  12. Re: Question to NTP developers

    Eugen COCA wrote:
    > David J Taylor wrote:
    >
    >> .. another long shot - but do you convert the GPS signals to true
    >> RS-232 levels, or simply use them as-is from the GPS18?
    >>

    >
    >
    > David,
    >
    > this could be a possible problem as the GPS receiver deliver signals
    > from 0 to 5V and not true TIA-232 levels (-9V to +9V). I thought at
    > this situation several months ago but I'm not sure if such a converter
    > will not add too much jitter to the PPS signal (as it must be supplied
    > with a separate voltage source).


    Eugen,

    I would not expect a level convertor to add any significant jitter, as it
    will be in the tens of nanoseconds or less, compared to the perhaps
    hundreds of nanoseconds for the PPS signal and perhaps microseconds for
    NTP. Indeed, by swinging the voltage over a wider level, it might
    actually reduce the effects of noise (which would translate into jitter)
    at the receiver.

    On the other hand, serial ports usually have a much better threshold than
    the +/- 9V. IIRC, +/- 3V is the actual threshold required. However, it
    does mean that using 0V for the lower level is, technically, outside the
    RS-232 specification, but it's something which people do seem to have done
    successfully for the last 20 years or so!

    It would be more important, of course, on longer connections or where the
    environment was electrically noisy.

    Cheers,
    David



  13. Re: Question to NTP developers

    Hal Murray wrote:
    >> There is only one GPS receiver and, of course, one PPS hardware signal.
    >> How could the PPS signal be present on one server and absent on the
    >> other in the same time ? This is my problem and I suspect 50% the
    >> hardware on the motherboards and 50% the software (OS + NTP) !


    What is the PPS pulse width coming out of the GPS? A pulse that's too
    narrow won't be seen by the PC serial port hardware/software.

    I have this issue with my Cs and Rb clocks. One of the clock pulses
    about 15us wide, and will not work with my Linux system that uses the
    shared memory PPS refclock. The same pulse works just fine with the
    ATOM driver on a FreeBSD box, on a slightly slower processor. Another
    clock has a pulse that's a bit more than 20us wide, and that works fine
    on the Linux system.

    While I think the Motorola receivers all have a wide pulse, some others
    are also down in the microsecond range.

    John
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  14. Re: Question to NTP developers

    John Ackermann N8UR wrote:
    > Hal Murray wrote:
    >>> There is only one GPS receiver and, of course, one PPS hardware
    >>> signal. How could the PPS signal be present on one server and
    >>> absent on the other in the same time ? This is my problem and I
    >>> suspect 50% the hardware on the motherboards and 50% the software
    >>> (OS + NTP) !

    >
    > What is the PPS pulse width coming out of the GPS? A pulse that's too
    > narrow won't be seen by the PC serial port hardware/software.
    >

    []
    > John


    The GPS18 LVC pulse is 100 ms by default, although it can be programmed
    from 20 ms to 980 ms.

    David



  15. Re: Question to NTP developers

    David J Taylor wrote:
    > John Ackermann N8UR wrote:
    >> Hal Murray wrote:
    >>>> There is only one GPS receiver and, of course, one PPS hardware
    >>>> signal. How could the PPS signal be present on one server and
    >>>> absent on the other in the same time ? This is my problem and I
    >>>> suspect 50% the hardware on the motherboards and 50% the software
    >>>> (OS + NTP) !

    >> What is the PPS pulse width coming out of the GPS? A pulse that's too
    >> narrow won't be seen by the PC serial port hardware/software.
    >>

    > []
    >> John

    >
    > The GPS18 LVC pulse is 100 ms by default, although it can be programmed
    > from 20 ms to 980 ms.


    That should be more than long enough. So much for that theory...

    John
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  16. Re: Question to NTP developers


    jra@febo.com (John Ackermann N8UR) writes:
    > While I think the Motorola receivers all have a wide pulse, some
    > others are also down in the microsecond range.


    600ms / 400ms for my m12 oncore. I'm not quite sure what the rational
    was for not making it perfectly square. (Maybe they wanted to drive
    the point home that the halfway mark wasn't to be used for timing???)

    -wolfgang
    --
    Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

  17. Re: Question to NTP developers


    John Ackermann N8UR wrote:

    > I have this issue with my Cs and Rb clocks.


    John,

    could you recommend me a good (and cheap enough) Rb clock ?

    Thanks !


  18. Re: Question to NTP developers

    Eugen COCA wrote:
    > John Ackermann N8UR wrote:
    >
    >> I have this issue with my Cs and Rb clocks.

    >
    > John,
    >
    > could you recommend me a good (and cheap enough) Rb clock ?
    >
    > Thanks !


    There are a number of used Rb "bricks" available on eBay that work
    pretty well. Many of them came out of digital cell sites, where they
    apparently were replaced by GPS units.

    There are a couple of Efratom models -- FRK and FRS, I think, that are
    well respected. They tend to go for ~$300 (give or take a hundred) and
    are quite reliable. They are little bricks about 3x4x5 inches and run
    off of 24 volts.

    However, these are generally 10MHz output only and don't have a clock or
    1pps output so you'll need to add that externally.

    Stanford Research sells a unit -- the PRS-10 -- hich is maybe $1200 new
    and has a very interesting RS-232 interface, can be disciplined to GPS,
    and (I think) has a 1pps output. It's the same form factor as the
    Efratom units. I've never played with one, but I know several folks who
    have and think they're nice units.

    The unit I'm using is a surplus HP-5065A with an "after-market"
    replacement for the HP digital clock option. The problem is that the
    after-market unit PPS signal is just a little bit shorter than the
    original HP, and thus doesn't like to feed the Linux box.

    As an overly nit-picky note for this forum, one difference between the
    inexpensive Rb units and the lab-quality ones like the HP-5065A is that
    the small, inexpensive guys directly FM the frequency standard as part
    of the phase lock detection process. That results in relatively poor
    phase noise. The lab units apply the FM separately from the oscillator
    output, and thus are much cleaner. For timekeeping purposes this is
    utterly irrelevant; for use in RF systems it becomes meaningful.

    John
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  19. Re: Question to NTP developers

    Eugen,

    Are you using the PPS driver (22)? If so, look at the relative offset
    between the serial timecode and PPS signal. If it is more than a few
    milliseconds, use the fudge time1 option to move the serial timecode
    offset close to the PPS signal. Or, see the tos mindist option on
    http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html.

    Dave

    Eugen COCAEugen wrote:

    > Harlan Stenn wrote:
    >
    >
    >>for some reason your
    >>GPS is saying "Here's some data, but due to X PPS is currently disabled".
    >>
    >>H

    >
    >
    > There is only one GPS receiver and, of course, one PPS hardware signal.
    > How could the PPS signal be present on one server and absent on the
    > other in the same time ? This is my problem and I suspect 50% the
    > hardware on the motherboards and 50% the software (OS + NTP) !
    >
    > And this is why I put only one receiver on both servers to diagnose the
    > problem.
    >
    > And, very strange, when the server stop syncing on the GPS, only and
    > many PPS SYNC DISABLED messages appear in the log. Just restarting the
    > ntpd service will solve the problem. This is another strange behaviour
    > - why, if it is a hardware problem, restarting the service eliminate it
    > ?
    >
    > Still searching ...
    >


  20. Re: Question to NTP developers


    David L. Mills wrote:
    > Eugen,
    >
    > Are you using the PPS driver (22)?


    Dave,

    No, I have FreeBSD and I use PPS to discipline the kernel.

    I made in this morning a change, and I use now the 22 driver and see is
    there are any differences form the previous situation. I must think to
    use a MAX232 and an inverter to generate true RS232 levels (as the
    inverter will add some delay and, I'm sure, a small portion of jitter
    due to it's own 5V supply and MAX232 internal +/- 10V inverters).

    I made a temperature stabilization of one of the servers mainboard
    crystal, and the results are quite encouraging. After all, I'm decided
    to buy this year a Rb box, to see if there are any changes !


+ Reply to Thread
Page 1 of 2 1 2 LastLast