[ntp:questions] Garmin LVC 18x jitter problem

2019-07-10 Thread Michael Haardt
I use a Garmin LVC 18x with a Raspberry Pi, process NMEA with gpsd
(SHM driver) and acess PPS by GPIO (kernel PPS driver).  gpsd allows
monitoring and passing PPS right into ntpd avoids gpsd conversion of PPS.

Sometimes this works, but then there are times where both clocks are
thrown out as falsetickers.  I believe that's due to the strange jitter
behaviour of the NMEA data.  If I understood the clock selection right,
then basically the measured jitter forms an interval around the offset
and the intersection interval is the root dispersion.  Should the NMEA
clock have no intersection with the used PPS clock, it is a falseticker,
but since PPS depends on it, PPS is so as well.

I graphed offset and jitter from two days peerstats where I was locked
on PPS (tos mindist 0.1) and the system ran stable without the need
to adjust the crystal frequency at constant environment temperature.
The first day was mostly fine, but in the middle of the second day, the
GPS jittered really bad and there are many occasions where the jitter
interval did not intersect with 0.  The ntpd jitter estimation works as
expected for a normal distribution, but the distribution is clearly
different:

http://www.moria.de/~michael/tmp/offset.svg
http://www.moria.de/~michael/tmp/jitter.svg

Using the tos mindist extends the intersection interval, but that
effects the root dispersion.  That's correct if it is needed to have an
intersection between different clocks of low jitter, but in my case the
problem is a wrong (too low) jitter estimation of a clock I only need
as PPS reference.

Is there any way to specify the precision manually, like fudge minjitter?
Clearly the jitter suffices to keep the PPS clock running and I would
like to have PPS determine the root dispersion, because the PPS clock
has a jitter of 4 us.

This problem seems to have come up a number of times in the past, but
I never saw the root dispersion impact of tos mindist mentioned and I
suspect in a number of cases configuring a minimal jitter would have
been a better solution.

Michael

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


Re: [ntp:questions] Garmin LVC 18x jitter problem

2019-07-10 Thread David Taylor

On 10/07/2019 22:15, Michael Haardt wrote:

I use a Garmin LVC 18x with a Raspberry Pi, process NMEA with gpsd
(SHM driver) and acess PPS by GPIO (kernel PPS driver).  gpsd allows
monitoring and passing PPS right into ntpd avoids gpsd conversion of PPS.

Sometimes this works, but then there are times where both clocks are
thrown out as falsetickers.  I believe that's due to the strange jitter
behaviour of the NMEA data.  If I understood the clock selection right,
then basically the measured jitter forms an interval around the offset
and the intersection interval is the root dispersion.  Should the NMEA
clock have no intersection with the used PPS clock, it is a falseticker,
but since PPS depends on it, PPS is so as well.

I graphed offset and jitter from two days peerstats where I was locked
on PPS (tos mindist 0.1) and the system ran stable without the need
to adjust the crystal frequency at constant environment temperature.
The first day was mostly fine, but in the middle of the second day, the
GPS jittered really bad and there are many occasions where the jitter
interval did not intersect with 0.  The ntpd jitter estimation works as
expected for a normal distribution, but the distribution is clearly
different:

http://www.moria.de/~michael/tmp/offset.svg
http://www.moria.de/~michael/tmp/jitter.svg

Using the tos mindist extends the intersection interval, but that
effects the root dispersion.  That's correct if it is needed to have an
intersection between different clocks of low jitter, but in my case the
problem is a wrong (too low) jitter estimation of a clock I only need
as PPS reference.

Is there any way to specify the precision manually, like fudge minjitter?
Clearly the jitter suffices to keep the PPS clock running and I would
like to have PPS determine the root dispersion, because the PPS clock
has a jitter of 4 us.

This problem seems to have come up a number of times in the past, but
I never saw the root dispersion impact of tos mindist mentioned and I
suspect in a number of cases configuring a minimal jitter would have
been a better solution.

Michael


Michael,

I'm not an expert in this, but the timing seems to be the same in both 
graphs, the problem occurring around 8000.  Could that be due to someone 
with a GPS jammer parking nearby?


I always try and have more than just the NMEA source as a "prefer" 
server if possible, something from the Internet will be much more 
reliable than the serial data!  Try adding a "pool" directive or some 
known good servers.


--
Cheers,
David
Web: http://www.satsignal.eu

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions