Re: [gpsd-dev] Port to QNX: PPS without SHM?

[Gary E. Miller]

Yo Norton!

On Tue, 5 Jan 2016 14:03:49 -0500
Norton Allen <address@hidden> wrote:

> On 1/5/2016 1:34 PM, Gary E. Miller wrote:
> > Yo Norton!
> >
> > Before I get into the meat of your email, you should take a look at
> > the gpsd time keeping and RasPi parts of the gpsd doc.  You have
> > missed some key concepts and jumped a bit too far in some odd
> > directions.  
> 
> I will do that. I think you are missing the biggest motivation for
> most of what I have done. This is to run on QNX, which does not
> support the SYSV IPC shared memory API that both gpsd and ntpd use. I
> would be happy to use NTPSHM, but that would seem to require quite a
> bit more porting effort in both programs in order to add support for
> POSIX shared memory.

But QNX does support POSIX shared memory:

http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/ipc.html#Shared_memory

Would it help if gpsd supported POSIX?

I can see that would be a bit more than you would want to do, but if
you can send us a patch to remove NTPSHM that would go part way there.


> In addition, the /dev/pps I am using (under QNX) does indeed allow
> more than one reader. QNX being a micro kernel OS, /dev/pps is
> implemented outside the kernel.

Well, just because you can, does not mean you should. gpsd uses NMEA
time to condition PPS time, which is not something ntpd can do properly,
if gpsd is getting the NMEA time.

It is best to let gpsd do the right thing and send the data on to ntpd.

> >>>> Any thoughts on what would be necessary to get PPS_ENABLE to work
> >>>> without NTPSHM_ENABLE?  
> > Not much point, gpsd json is new and problematic, keep the NTPSHM
> > for now.  You will find it a lot easier, less confusing, and less
> > buggy than the gpsd json driver.  
> 
> As stated, this is not really an option.

Not an easy way, you could port the shmget()s to shm_open()s.  I can
see why you would not go there.

> >> In particular, although I was originally
> >> unable to get ntpd to acknowledge the gpsd json data without gpsd
> >> receiving the PPS signal,  
> > Yes, gpsd needs to be the ne getting the PPS signal.  Do not pass
> > it directly to ntpd.
> >  
> >> I have since managed to get that working.
> >> ntpd is now looking at gpsd json as 'prefer' and directly
> >> at /dev/pps1 for PPS.  
> > That would be a bad thing.  You have now bypassed all that gpsd
> > does to clean up the PPS signal for you.  
> 
> ntpd does not seem to be having trouble with the PPS signal. What
> should I be looking at that would show the inherent limitations of my
> approach.

You will see problems with time convergence on startup.  Or during any
time slewing. ntpd may see the PPS and connect it to the wrong second.
ntpd could lock on off be one second, or possibly worse.

I would also worry about time just after a leap second.

Also by using prefer on the NMEA signal you are telling ntpd to
prefer the course time signl over the fine time signal.



> What is the value of having gpsd get the pps time if it doesn't
> actually produce a more precise output?

precision is not everything.  You can be precisely off by one second.
Properly rejecting bad time, allowing fast time slewing, and handling
leap seconds are also important.

> ntpd is capable of putting
> the coarse time signal together with the precise PPS already.

Sort of.

> Is
> every application that uses gpsd then required to handle and combine
> the two signals?

Yes, but that would be just ntpd and chronyd and theyy both do it correctly.

> >> Perhaps related, the ntpd refclock 46 documentation describes a
> >> secondary channel (e.g. 127.127.46.129) that would obtain PPS
> >> information from gpsd. I have not been able to get that to work.  
> > There is some confusion, the gpsd json driver and the gpsd ng driver
> > are one and the same thing.  
> 
> Yes, that is the one and only gpsd driver I am referring to.

If you are stuck with that, you are better off going to chronyd with
sockets.  Way to many knobs with bad defaults in that driver.

> >    And all ntpd drivers can have secondary
> > channels, all the way up to over 250 channels.  You would use a
> > secondary channel for your 2nd GPS, and a third channnel for your
> > 3rd GPS.  
> 
> I am specifically referring to the documentation on this page:
> 
>     https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver46.html

You specifically mentioned .129, which would be a secnd GPS.  This
is why the gpsd json driver is so hard to use, they use the same words
for totally different concepts and it confuses people.

To use the type 46 driver you send NMEA and PPS only to gpsd, then have
them sent to ONE instance of driver 46, and use mode word 2.  Which as
noted is experimmental because it is flakey.

> In the section labeled 'PPS secondary clock unit'. It's not just a 
> second NMEA channel, it's specifically for the PPS data. I am not 
> confused by the ability to have secondary channels. I was simply 
> pointing out that in my implementation, using this specific secondary 
> channel to obtain PPS data from gpsd did not work. This is very
> likely a fault with my implementation, but if someone were to say "oh
> yeah, that has never worked," then that would be useful information.

I'll say it: "it will never work the way you are trying to make it work."

The way to make it work is in the gpsd doc.


> >> can understand why that might be less desirable than having ntpd
> >> obtain the PPS data directly from /dev/pps1,  
> > Exactly wrong.  gpsd needs the data, and will pass on the
> > ntpd/chronyd/etc after cleaning it up.  
> 
> My experience is not consistent with that statement. I have managed
> to get ntpd to happily accept NMEA data from gpsd ng together with
> PPS data directly from /dev/pps even when gpsd is not configured to
> access the PPS channel.

Yeah, it can be happy steady state, but the problems are in the startup
conditions where there are many ways to fail.  There are also outlier
conditions that will confuse ntpd.  In many cases it can fail to
converge or ir can lock on the wrong second.

To really test you need to disconnect the GPS, bump the system clock
(both time and/or frequency), then restart the GPS and watch convergence.
There are cases where no matter what you do ntpd will never converge.

Steady state is easy, convergence is hard.  In these sort of tests
chronyd far outshines ntpd.


> > read /dev/pps1 at the same time!  You can stop trying now, it is a
> > kernel limitation.  
> 
> As stated, this is not your Linux kernel. I do not have that
> limitation.

I would really like to see a proof of that.  Just because two processes
can open /dev/pps1 at the same time does not mean it totally works.  A
good easy test would be like maybe running two instances of ppstest on
the same /dev/pps1.  Supporting RFC time for multiple instances would be
pretty tricky for a kernel to do.

> >> This is not an immediate problem for basic timekeeping, since ntpd
> >> is able to use the PPS signal directly, but there are plenty of
> >> reasons why other applications might want to receive time data
> >> from gpsd that is more precise.  
> > Yes, many reasons to have gpsd read PPS, not ntpd.  Just follow the
> > RasPi setup instructions in gpsd and you will work fine.  
> 
> I will definitely take a look at that, thanks.

You might also look at ar chronyd, depending on your use case.  ntpd
needs at least 3 good time sources for good operation and needs to
be run continuously.  chronyd does not have those limitations, plus
its socket protocol works easily.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpGmHnN30veL.pgp
Description: OpenPGP digital signature