On Mon, Feb 28, 2022 at 1:12 PM Miroslav Lichvar <mlich...@redhat.com> 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 <mlich...@redhat.com> > > 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. > >
