[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PPS in GPSD vs Chrony
From: |
Miroslav Lichvar |
Subject: |
Re: PPS in GPSD vs Chrony |
Date: |
Thu, 2 Jul 2020 09:57:49 +0200 |
On Wed, Jul 01, 2020 at 11:21:46AM -0700, Gary E. Miller wrote:
> > If the poll rate stays at 1Hz then why does a higher "PPS" help?
> > Maybe it keeps chronyd (I assume you are using chronyd) fresh in the
> > CPU cache and running on its own core. This is an odd one.
There is a median filter (in chrony, ntp and ntpsec I presume)
between the internal refclock driver's polling and the main configured
polling interval. If the poll was 3 (8 seconds) and the PPS driver
provided 1 sample per second (the normal case), on each poll there
would be 8 samples to process. When the PPS rate is increased, and the
driver can be configured to collect all those samples (I'm not sure
about ntp/ntpsec), the median becomes more stable and as a result the
synchronized clock should be more stable too. You could do the
filtering in gpsd for >1Hz PPS to not require the SHM receiver to
collect the samples at a higher rate. It would be just getting better
samples.
> Hmm, how does the time daemon (gpsd, chonryd, ntpd) know which of the
> 32 pulses is the top of the second? NMEA time is very unlikely to be
> better than 30 ms.
Yeah, that's tricky. The binary protocols should be more stable. In my
case it was unreliable with a 32Hz PPS, so I rely on (close) NTP
servers to get the PPS refclock running.
--
Miroslav Lichvar