Re: [Diagnosed]: Timeservice not running on Ubuntu 16.04

[Gary E. Miller]

Yo Dan!

On Fri, 5 Jun 2020 09:34:19 -0400
Dan Williams <dwilliams@nextdroid.com> wrote:

> I think I've diagnosed what the problems are, but not the fix.

When you understand the problem, the fix is easy.

> - User-space (plain) pps is not working, (reasons not clear)

They are clear:  permissions.  Unsupported mode.  And user error, see
below.

> - root-space (kernel) ppps is not working, due to something on our
> side. Details follow.

They are clear:  permissions.  Unsupported mode.  And user error, see
below.

> I'll just note that if we find shortcomings in the OxTS
> implementation, our company is a paying customer, and we could apply
> pressure behind relevant bug reports.

They need to start over.  The documented part of the binary protocol
is junk.  The undocumented parts are many.

> GPSD is also well-known, and could similarly apply pressure, if
> desired.

Oh, I wish.

> > Your gpspipe.log was not long enough to show any GSA.
> Besides this one?  

3 sats in view?  Ugh.  No alarm bells yet?

> I've also attached a longer, 3-second one, if you prefer.  

Not very useful when it tells you it is invalid:

$GPRMC,212009.00,V,4220.138940,N,07107.659525,W,0.225,191.959,040620,,,D*55
                ^^^

V there means "Invalid".  Navigating with no fix is ungood.  Time
keeping with no fix is also ungood.

> > That's just what it's _*configured*_ to.  It has a whole lot of
> > sentences,    
> but I just configured it to what I guessed was a minumum set.
> If we need more sentences, then just me know, and I'll configure it.  

The good stuff is in the binary.  The binary ip very primitive and error
prone.  Something that escaped from the '90s.  The control messages
undocumented.

About all to do better with is to add $PTCF, if that data is useful.
I'd need to add a decoder for it.

> Right well "IFF you system supports it" is the whole trick, isn't it?  

Yup,  KPPS is not supported:

$ ./gpsd -bnN -D6 /dev/ttyS6  |& fgrep PPS
gpsd:PROG: PPS:/dev/ttyS6 chrony socket /tmp/chrony.ttyS6.sock doesn't exist
gpsd:PROG: KPPS:/dev/ttyS6 checking /sys/devices/virtual/pps/pps0/path, 
gpsd:PROG: KPPS:/dev/ttyS6 checking /sys/devices/virtual/pps/pps1/path, 
/dev/ttyS6
gpsd:INFO: KPPS:/dev/ttyS6 running as 1001/1001, cannot open /dev/pps1: unknown 
error
gpsd:WARN: KPPS:/dev/ttyS6 kernel PPS unavailable, PPS accuracy will suffer

What perms are on your /dev/ppsX?  Usually root only, and you are not
running root, which is unsupported mode.

> As far as checking it -- the howto mentions "ppscheck"  (see second
> paragraph of
> https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_enabling_pps)
> My system passes this, and shows "TIOCM_CD" signals.  

And gpsd is seeing that:

gpsd:PROG: TPPS:/dev/ttyS6 ioctl(TIOCMIWAIT) succeeded, time: 
1591307909.371366779,  state: 0
gpsd:PROG: TPPS:/dev/ttyS6 Clear, cycle: 1591307909371366, duration: 
1591307909371366 @  1591307909.371366779

But since the NMEA says the fix is invalid, gpsd will not use it:

gpsd:PROG: PPS:/dev/ttyS6 Assert ignored missing last_fixtime

Which is correct behavior, because you started gpsd wrong.

> According to the comments at
> https://gitlab.com/gpsd/gpsd/-/blob/master/ppsthread.c#L9, user-space
> PPS and KPPS are the two methods.   ppscheck / TIOCM_CD uses the
> first method, "user-space PPS".      This is mentioned in the build
> output, but not in the -d5 output, below.  

Look again in the debug log.  Or above where I pasted the relevant part.

> So This looks like where the problem is -- running gpsd in user-space
> with -D6  shows this block every second:  

Ugh, did you miss the aprt about not running gpsd in user space?


> Question 2: Does gpsd still support user space PPS, like the
> documentation seems to say?

You misunderstand what "user spaee" means.  It measn running as root, but
not in the kernel.  Not in kernel == user space.

> Question 3: Should I send a patch/PR to add more detail to the doc
> about ppscheck and ppstest.   I can supply one if desired.

Patches and/or MRs always welcome.  Way down on my TODO list is to
improve the code.

> > That is the intended behavior?
> > Some parts of gpsd seem to defy expections, so intention hard to
> > prove. 
> 
> I'm not asking to read anyone's mind, I was just trying to distinguish
> between "working as intended" or "bug"

How about not working as documented?  gpsd needs root for timekeeping,
except in special cases that do not apply to you.

> > Whoops!  You forgot to run as root.  This is documented and
> > required to do PPS and SHM things.  Big show stopping mistake.
> >  
> 
> The documentation I'm reading (that same how-to) implies that gpsd
> may be run as a normal user. (as discussed above)

Yes, did you read it?  That pretty much says what is happening to you.

> > "1. Devices passed on the command line will be unable to use KPPS

See?

> > and  
> will fall back to the same plain PPS that all hotplug devices must
> use, increasing the associated error from ~1 uSec to about ~5 uSec."

Which it did, properly.  Except you had no fix.  So gpsd properly
rejected the PPS time.  Did you read the part about verifying you have a
good fix before proceeding to look at PPS?

> +/- 5 usec would be acceptable, if it worked.

It does, when you follow the directions.  Note there are more pitfalls
to non-root that you will eventually discover.  So run as root.

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

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpmpKV9x8d30.pgp
Description: OpenPGP digital signature