[Top][All Lists]

[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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]