Re: [chrony-users] Chrony gets out of sync regularly
> >>> Why do you need the SHM 0? You can use SHM 1 or SOCK.Some cookbooks (e.g., > https://support.ntp.org/bin/view/Support/ConfiguringSHMRefclocks ) use both SHM 0 and SHM 1 That might had been necessary with very old versions of gpsd (IIRC it originally required something to bring the system clock close to the PPS before it locked), but with more recent gpsd versions the configuration should be one of the following: chronyd/ntpd can take PPS directly & determine the name of the second, or gpsd can intervene and do some of the work. The options are confusing and poorly documented. gpsd altered the picture without warning; fortunately the number of affected users seems to be small . I did a git bisect last year: the problem appeared between release-3.21-26 and release-3.21-30. This is the unit I've been using: https://v3.airspy.us/product/upu-rpigps/ Ublox MAX-M8Q Since the gpsd team doesn't see an issue I stopped looking. If the results might be useful I could dig deeper (e.g., turn off GPGSV or other sentences.). Steve
Re: [chrony-users] Chrony gets out of sync regularly
On Thu, Mar 03, 2022 at 10:03:54PM -0600, Steven Sommars wrote: > Config: Host sync'd to nearby stratum 1s. Jitter ~35 usec. gpsd 3.23 > gpspipe, gpspipe -R and ntpshmmon running simultaneously for several hours > > gpspipe -T '%s' --usec -r | sed 's|,.*||' > Min Max > (sec)(sec) > .132419 .168017 GPGBS > .132332 .167903 GPGGA > .132393 .167985 GPGSA > .389284 .549959 GPGSV > .132364 .167938 GPRMC > .132263 .167829 GPZDA I think that indicates the timing of GPGSV messages somehow impacts the SHM timestamping. That would be a bug in gpsd. > >>> Why do you need the SHM 0? You can use SHM 1 or SOCK. > Some cookbooks (e.g., > https://support.ntp.org/bin/view/Support/ConfiguringSHMRefclocks ) use both > SHM 0 and SHM 1 That might had been necessary with very old versions of gpsd (IIRC it originally required something to bring the system clock close to the PPS before it locked), but with more recent gpsd versions the configuration should be one of the following: 1) refclock SOCK 2) refclock SHM 1 3) refclock SHM 0 noselect + refclock PPS lock SHM0 I don't recommend using SHM 0 and SHM 1 at the same time. Typically, SHM0 is worse than a remote NTP server and makes falseticker detection less reliable. -- 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.
Re: [chrony-users] Chrony gets out of sync regularly
Config: Host sync'd to nearby stratum 1s. Jitter ~35 usec. gpsd 3.23 gpspipe, gpspipe -R and ntpshmmon running simultaneously for several hours gpspipe -T '%s' --usec -r | sed 's|,.*||' Min Max (sec)(sec) .132419 .168017 GPGBS .132332 .167903 GPGGA .132393 .167985 GPGSA .389284 .549959 GPGSV .132364 .167938 GPRMC .132263 .167829 GPZDA gpspipe shows that the data is sent in binary mode. I'll send some other details off-list. >>> Why do you need the SHM 0? You can use SHM 1 or SOCK. Some cookbooks (e.g., https://support.ntp.org/bin/view/Support/ConfiguringSHMRefclocks ) use both SHM 0 and SHM 1 On Wed, Mar 2, 2022 at 3:34 AM Miroslav Lichvar wrote: > On Tue, Mar 01, 2022 at 03:09:27PM -0600, Steven Sommars wrote: > > 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. > > Can you try the following command and compare the output when the > offset jumps? > > # gpspipe -T '%s' --usec -r | sed 's|,.*||' > > For example, with gpsd 3.23.1 and a ublox unit I have here I get: > > 1646208470.067774: $GPZDA > 1646208470.067792: $GPGGA > 1646208470.067806: $GPRMC > 1646208470.067811: $GPGSA > 1646208470.067814: $GPGBS > 1646208470.082703: $GPGSV > 1646208470.082721: $GPGSV > 1646208470.082726: $GPGSV > > The timing of the messages in my case is stable to about 20 > milliseconds. In the "super-raw" (gpspipe -R) output I can see it's > using the binary protocol. > > -- > 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. > >
Re: [chrony-users] Chrony gets out of sync regularly
On Wed, Mar 02, 2022 at 10:14:48AM +0100, Gabriele Coppi wrote: > At this point, I guess the easiest option would be to install gpsd 3.20 and > test it again Why do you need the SHM 0? You can use SHM 1 or SOCK. If you really need it (e.g. for >1Hz PPS), you can set the refclock offset to 0.4 and it should work fine, even with those jumps. -- 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.
Re: [chrony-users] Chrony gets out of sync regularly
On Tue, Mar 01, 2022 at 03:09:27PM -0600, Steven Sommars wrote: > 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. Can you try the following command and compare the output when the offset jumps? # gpspipe -T '%s' --usec -r | sed 's|,.*||' For example, with gpsd 3.23.1 and a ublox unit I have here I get: 1646208470.067774: $GPZDA 1646208470.067792: $GPGGA 1646208470.067806: $GPRMC 1646208470.067811: $GPGSA 1646208470.067814: $GPGBS 1646208470.082703: $GPGSV 1646208470.082721: $GPGSV 1646208470.082726: $GPGSV The timing of the messages in my case is stable to about 20 milliseconds. In the "super-raw" (gpspipe -R) output I can see it's using the binary protocol. -- 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.
Re: [chrony-users] Chrony gets out of sync regularly
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. > > > > >
Re: [chrony-users] Chrony gets out of sync regularly
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: image.png] 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. >> >>
Re: [chrony-users] Chrony gets out of sync regularly
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. > >
Re: [chrony-users] Chrony gets out of sync regularly
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. > > 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.
Re: [chrony-users] Chrony gets out of sync regularly
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: > > I am having some issues running Chrony with only GPS+PPS (coming from the > > GPS) on RPi 4. At the startup gpsd starts running with no particular > issue > > and I got GPS and PPS solution with no problem checking gpsmon. I have > > installed chrony to use the GPS and PPS as a time sources to keep the > clock > > in sync with those. Compared to the default chrony config file I > commented > > all the debian pool server and the rtcsync since the RPi does not have a > > RTC. I also added the following lines: > > > > 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 > > > The chronyc sources command shows that after a settling time the PPS > source > > is chosen as the best and the GPS is discarded. This situation is pretty > > stable for 17min and then gets out of sync for 17min and then gets in > sync > > again for 17min. During the out of sync, so when both sources are > > discarded, the sources still have a reach of 377. > > 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. > > -- > 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. > >
Re: [chrony-users] Chrony gets out of sync regularly
On Fri, Feb 25, 2022 at 12:10:40PM +0100, Gabriele Coppi wrote: > I am having some issues running Chrony with only GPS+PPS (coming from the > GPS) on RPi 4. At the startup gpsd starts running with no particular issue > and I got GPS and PPS solution with no problem checking gpsmon. I have > installed chrony to use the GPS and PPS as a time sources to keep the clock > in sync with those. Compared to the default chrony config file I commented > all the debian pool server and the rtcsync since the RPi does not have a > RTC. I also added the following lines: > > 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. > The chronyc sources command shows that after a settling time the PPS source > is chosen as the best and the GPS is discarded. This situation is pretty > stable for 17min and then gets out of sync for 17min and then gets in sync > again for 17min. During the out of sync, so when both sources are > discarded, the sources still have a reach of 377. 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. -- 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.
