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

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.

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

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

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

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.

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

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

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

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

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

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

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

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/

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 !

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

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

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 !