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

[Alexander Carver]

On 2014-09-03 13:10, Gary E. Miller wrote:
> Yo Alexander!
> 
> On Wed, 03 Sep 2014 12:59:41 -0700
> Alexander Carver <address@hidden> wrote:
> 
>>> 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 do not think there is anything in newer kernels to affect this.
> 
>>> 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?
> 
> Creating pps0 is how KPPS works.  No KPPS, then no pps0 from gpsd.
> 
>> If it skips that, how do I share the port with
>> ldattach and gpsd?
> 
> gpsd never uses ldattach.  Port sharing of a GPS is problematic as 
> autobaud and auto configure will get confused between two GPS clients.
> 
> Just have ntpd read the GPS by way of gpsd.

You misunderstand.  I need the pps device to allow ATOM to work.  The
other times are coming in from SHM(0).  So the GPSr is being read by
gpsd and passed over but the PPS portion just doesn't work well so I
need to share that single port with pps0 for ntpd and the rest (ttyS0)
for gpsd.  I'm not asking ntpd to do anything with the port.  I'm not
using the NMEA driver, I'm using ATOM.  The GPS isn't even NMEA, it's SiRF.

> 
>>> 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.
> 
> Something wrong with your setup then.  No way gpsd adds 1000x jitter.
> I routinely see around 1 microSec using gpsd and SHM().  Even better
> with chronyd.

There's very little setup that could go wrong.  There's no config file
for gpsd as you're very well aware.  It starts and goes and nothing else
to do.  For ntpd, I point it at SHM(1) and it should collect data.  It
does collect data (assuming ATOM is disabled, of course) but the jitter
is bad.  If I do not use SHM(1) and stick to ATOM, the jitter is much
better.


> 
> 
>> 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.
> 
> Likely because only one can use the port at a time.

Well yes I understand that to an extent.  SHM(0) plus ATOM actually does
work.  It's SHM(1) that has trouble which is why I'm using ATOM in the
first place.  ATOM does far better with jitter than SHM(1).  SHM(0)'s
jitter is going to be bad since it's just the time stamps from the GPS
itself without the aid of the PPS as that comes in by SHM(1).

> 
>>  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.
> 
> You gotta pick ntpd or gpsd to run the GPS.  You can't share and get
> good timing.

I'm not picking ntpd to run the GPS.  I'm using gpsd to run the GPS.
But gpsd is giving me terrible results for PPS via SHM(1) so I must
resort to having ntpd listen to pps0 using ATOM.  I'm still using SHM(0)
to get the regular GPS clock data for seconds numbering.  This is not an
abnormal configuration, it's discussed many times in various places but
PPS via gpsd is just not doing well in terms of stability.  PPS via the
pps0 device and sent to ntpd directly via ATOM does work fine.