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<image.png>
On Mon, Feb 28, 2022 at 8:35 AM Gabriele Coppi <gabriele.coppi@xxxxxxxxx> wrote:On Mon, Feb 28, 2022 at 1:12 PM Miroslav Lichvar <mlichvar@xxxxxxxxxx> 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 <mlichvar@xxxxxxxxxxx>
> 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 usingrefclock PPS /dev/pps0 precision 1e-7 refid PPSinstead 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-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.