[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PPS in GPSD vs Chrony
From: |
Gary E. Miller |
Subject: |
Re: PPS in GPSD vs Chrony |
Date: |
Thu, 2 Jul 2020 15:45:27 -0700 |
Yo Miroslav!
On Thu, 2 Jul 2020 09:57:49 +0200
Miroslav Lichvar <mlichvar@redhat.com> wrote:
> There is a median filter (in chrony, ntp and ntpsec I presume)
I see no such thing in refclock_pps.c in ntpsec. Pretty much the same
code as i NTP Classic.
Sounds like a good idea.
> 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.
AFAIK ntpd does no averaging/filtering. Might be a good idea now that
our time sources are far more accurate than the measurement precision.
> > 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.
Even then you would need a very fast serial port, which modern receivers
can do, just not by default.
> In my
> case it was unreliable with a 32Hz PPS, so I rely on (close) NTP
> servers to get the PPS refclock running.
Classic chicken and egg problem.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpjGzvmvc4tv.pgp
Description: OpenPGP digital signature