|Re: [chrony-users] kernel PPS troubleshooting|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
On Wed, Dec 11, 2013 at 10:11:48AM -0800, Bill Unruh wrote:
> On Wed, 11 Dec 2013, Miroslav Lichvar wrote:
> >When no source is selected, the PPS samples are ignored. If the SHM
> >source doesn't move to the acceptable range to overlap with the PPS
> >source in 8 polling intervals, the PPS source is marked as unreachable
> >and the SHM source is selected as the only available source.
> That sounds like a bug. PPS should always be part of the selection process. It
> is almost by definition the correct source. And certainly it could be argued
> that the PPS should be the selected source, not the nmea. Of course some
> people (me) us shm to deliver pps to chrony, so shm should not automatically
> be downgraded, but a kernel pps it seems certainly should not be downgraded.
I think it works as expected. When there is a PPS source and a SHM
source and they don't agree, what do you do? Pick the PPS source only
because it's from the PPS driver? The SHM source can be from a PPS
signal too (as is in your case). If it was configured with the prefer
flag, I'd probably agree.
> >The configured delay is included in the interval used in the source
> >selection algorithm, so increasing the value from 0.01 to 0.4 or
> >larger should fix the problem.
> A user should not have to do this or know this.
That would be nice, but I'm not sure how should chrony detect that the
source is a falseticker without comparing it to other sources.
The recommended configuration is to mark such sources with noselect
and use them only for PPS locking.
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.