| Re: [chrony-users] gpsd, pps and chrony |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, 21 Mar 2011, Miroslav Lichvar wrote:
On Mon, Mar 21, 2011 at 09:16:50AM -0700, Bill Unruh wrote:
Maybe an NMEA source should not be regarded as a stratum 0 clock but rather as
a stratum 1. Its error ( many ms) is far greater than the PPS. Although even
with that error that does not make up for the huge (300 ms or greater) delay
from the nmea.
I'm not sure how would increasing stratum help here. The falseticker
detection ignores the stratum of the sources. Also, chrony doesn't know
if it's an NMEA source or not, the SHM protocol doesn't provide such
information.
Yes, I thought of that afterwards, that both are SHM sources, and there is no
way the system can know what is feeding the data to that shm memory segment.
It could be a Rubidium clock, a GPS PPS, and NMEA or a mechanical metronome.
I cannot remember if chrony allows an offset fudge as ntpd does--ie telling
chrony that this particular source is always 300ms off.
Certainly pairing the nmea with the PPS is the only proper thing to do,
although apparently the GPS18x has a firmware bug that causes the nmea to come
out over a second after the PPS, which screws up that association.
Yes, that's unfortunate. I'm keeping an older firmware in mine until
a fixed one is released. In gpsd it's not possible to adjust for the
large delay, so SHM 0 refclock with adjusted offset + PPS refclock is
probably the only reliable configuration with the broken firmware.
BTW, the soon to be released gpsd supports kernel PPS timestamping and
also the chrony SOCK protocol, which means that to get PPS samples
with nanosecond resolution the PPS refclock won't be necessary.
I really do not like kernel PPS. I think it is far better to have everything
going through the same route-- namely chrony or ntpd, and not have some time
sources disciplining the clock via ntpd and others via the kernel. It feels
like running chrony and ntpd at the same time.
A gps receiver which delivers the nmea over 1 sec after the time it is
supposed to refer to is just broken, and especially one which is inconsistant
in the second it refers to . I guess one could say that anything that comes in
within 1.1sec of a pulse should refer to that pulse since nmea almost always
come on something like 300ms late. But it is a pretty horrible kludge.
If there is going to be a fix, it should be within gpsd, and not within chrony
or ntpd.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.