At this point, I guess the easiest option would be to install gpsd 3.20 and
test it again
Gabriele
On 1 Mar 2022, 22:10 +0100, Steven Sommars , wrote:
> Gabriele provided ntpshmmon output which I've graphed below. The host was
> roughly synchronized, then chrony was disabled for the duration of the test.
> NTP1 (pps) drifted slightly (0.7 msec) during the test, but that was too
> small to be visible on the scatterplot.
> The notable feature is that NTP0 times (green) regularly jump by 180 msec.
>
> Note: I'm not a gpsd expert, some of this may be inaccurate.
> I understand the jumps to be gpsd-related. I see identical behavior on one
> of my RPi4+ublox GPS units.
> NMEA sentence timing remains consistent. As an optimization some gpsd
> versions move the GPS into ublox binary mode for the serial data stream.
> The ublox serial binary mode timing is not consistent. The gpsd folks
> apparently believe that the arrival time of serial data is untrustworthy and
> should not be used.
>
> I don't understand gpsd internals; version 3.20 didn't show this behavior.
>
> Steve Sommars
>
>
>
> > On Mon, Feb 28, 2022 at 8:35 AM Gabriele Coppi
> > wrote:
> > >
> > > > On Mon, Feb 28, 2022 at 1:12 PM Miroslav Lichvar
> > > > wrote:
> > > > > On Mon, Feb 28, 2022 at 10:37:09AM +0100, Gabriele Coppi wrote:
> > > > > > On Mon, Feb 28, 2022 at 8:46 AM Miroslav Lichvar
> > > > > >
> > > > > > wrote:
> > > > > > > On Fri, Feb 25, 2022 at 12:10:40PM +0100, Gabriele Coppi wrote:
> > > > > > > > refclock SHM 0 precision 1e-1 delay 0.5 refid GPS
> > > > > > > > refclock SHM 1 precision 1e-7 refid PPS
> > > > > > >
> > > > > > > You should remove the first source and just rely on the PPS-based
> > > > > > > SHM 1, or alternatively use SHM 0 + PPS /dev/pps0. SHM 1 from
> > > > > > > gpsd is
> > > > > > > sufficient.
> > > > > > >
> > > > > >
> > > > > > I am using the SHM1 because the /dev/pps0 it is always reported as a
> > > > > > falseticker. I checked with ppstest and I got out the signal, so I
> > > > > > don't
> > > > > > know why
> > > > >
> > > > > As a falseticker against SHM 0, or some NTP server? If the latter, it
> > > > > might be using the wrong edge of the pulse.
> > > >
> > > > Now it seems working also using
> > > >
> > > > refclock PPS /dev/pps0 precision 1e-7 refid PPS
> > > >
> > > > instead of the SHM1 PPS signal. However, I am still getting falseticker
> > > > after ~15min from both PPS and SHM0 sources. I will try to use only the
> > > > PPS now based on what you wrote below
> > > >
> > > > >
> > > > > > > If you see both sources marked as falsetickers (x symbol) in the
> > > > > > > chronyc sources output, that means they don't agree with each
> > > > > > > other.
> > > > > > > If the offset of the SHM 0 is around 0.25s, small changes in the
> > > > > > > delay
> > > > > > > would cause the behaviour you see.
> > > > > > >
> > > > > >
> > > > > > Yes, the offset of SHM0 is always between 250 and 500ms.
> > > > >
> > > > > That should be compensated with the offset option. But better it is to
> > > > > not use the SHM 0 at all. As you see, its offset is too variable.
> > > > >
> > > > > --
> > > > > Miroslav Lichvar
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
> > > > > with "unsubscribe" in the subject.
> > > > > For help email chrony-users-requ...@chrony.tuxfamily.org
> > > > > with "help" in the subject.
> > > > > Trouble? Email listmas...@chrony.tuxfamily.org.
> > > > >
