Re: [gpsd-users] Disable or restart PPS in gpsd?

[Alexander Carver]

On 2014-09-03 12:50, Gary E. Miller wrote:
> Yo Alexander!
> 
> On Wed, 03 Sep 2014 00:18:40 -0700
> Alexander Carver <address@hidden> wrote:
> 
>> On 2014-09-03 00:13, Gary E. Miller wrote:
>>> Yo Alexander!
>>>
>>> On Wed, 03 Sep 2014 00:06:09 -0700
>>> Alexander Carver <address@hidden> wrote:
>>>
>>>> I'm having some trouble with PPS on version 3.6 in kernel 3.2
>>>
>>> Both those are petty old, you'll need to upgrade.
>>
>> The kernel is the latest image in Debian's stable branch.  There isn't
>> one available up from that.  I can replace gpsd with a tarball instead
>> of a package, not sure it will help in this case, though.
> 
> Just do not expect any patches on such an old gpsd.

Of course not.  As I said I can compile a new version which is fine by
me, I just can't go up on the kernel right now since a newer image is
not available in the stable branch.  I may at a later time investigate
the backports which I understand may potentially be up to 3.14.

> 
>>>> I get this once per second, as you can see, until I restart gpsd.
>>>> The problem is that gpsd is also creating the pps0 device which
>>>> ntpd is attempting to use as well.  Restarting gpsd alone without
>>>> restarting ntpd does not remove pps0 and instead recreates it as
>>>> pps1.  I have to restart both services to fix gpsd and restore
>>>> pps0.
>>>
>>> If gpsd is using the PPS then no need for ntpd to use PPS as well.  
>>> Avoid the confusion and just let gps handle the PPS fpr ntpd.
>>
>> It's not working properly which is why I'm resorting to ntpd's PPS
>> driver.  If there's even the slightest hiccup in the SHM(0) stream,
>> ntpd boots both SHM's and I'm left with nothing.  The SHM(1) stream
>> is also unstable (jitter) compared to the actual PPS signal.  Using
>> the PPS driver, the jitter is much better.  Also with the PPS driver,
>> the system will fall back to another source if gpsd fails to deliver
>> a timestamp properly and the PPS will continue ticking using the next
>> available source for numbering the seconds.  The problem then is my
>> logs fill up with once-per-second messages about the KPPS error until
>> I restart gpsd.
> 
> Sounds like you just want KPPS off in gpsd.  So just compile it without
> pps support.

If I disable KPPS in gpsd will it still create the pps0 device or will
it skip that part?  If it skips that, how do I share the port with
ldattach and gpsd?


> What sort of jitter difference are you seeing?

Jitter using the PPS ATOM driver is nominally 6 microseconds.  Jitter
using SHM(1) from gpsd is up to 5 milliseconds.  So about 1000 times
worse.  And this assumes that KPPS doesn't go belly up for some reason.

Right now, SHM(0) isn't even reporting, gpsd is spewing KPPS errors, but
ntpd's ATOM is happily ticking away with 1 microsecond jitter and less
than 5 microseconds offset.  I used another one of my machines as a
second preferred peer for seconds counting which is why ATOM is still
running even though SHM(0) is dead.  SHM(1) does not work at all if
ntpd's ATOM is configured and when I only use SHM(0,1) with no ATOM,
SHM(1) shows the bad jitter compared to ATOM's jitter.