gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Diagnosed]: Timeservice not running on Ubuntu 16.04


From: Dan Williams
Subject: [Diagnosed]: Timeservice not running on Ubuntu 16.04
Date: Fri, 5 Jun 2020 09:34:19 -0400

Yo Gary,

Summary:
I think I've diagnosed what the problems are, but not the fix. 
- User-space (plain) pps is not working, (reasons not clear)
- root-space (kernel) ppps is not working, due to something on our side.
Details follow.
 
> > What is your receiver? 

(you seem to have gotten the information you want here.) 

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.
GPSD is also well-known, and could similarly apply pressure, if desired.

Since that device is not publicly documented, there will be issues
hiding here.

Your gpspipe.log was not long enough to show any GSA.
 
I've attached a longer sample; this one is 3 seconds, and includes 3 GSA sentences.
 
Why buy a high end receiver and then only output low end data?


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 minimum working set. 
If we need more sentences, then just me know, and I'll configure them.
 
It is enabled by default, IFF your system supports it.  This is documented
in the build instructions.

Right. Well "IFF your system supports it" is the whole trick, isn't it?

The documentation is not particularly clear on this, and seems to conflate the two PPS methods  ("plain" and KPPS). 
It says that ppscheck is sufficient to verify that PPS is working, but ppscheck only runs against serial ports, and only verifies "plain PPS".  Meanwhile, "ppstest" verifies the KPPS variant, and this is not mentioned in the docs.
(I'm referring to https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_enabling_pps , Para 2.  I mean, it barely mentions what ppscheck, let alone what to look for. )

The source code comments, on the other hand, (at https://gitlab.com/gpsd/gpsd/-/blob/master/ppsthread.c#L9), mention user-space PPS and KPPS as explicitly two different methods.  

1. the howto mentions ppscheck in passing -- merely to use the ppscheck command, but not why or how.    (ppscheck checks TIOCM_CD, which is the first method, (aka "plain PPS", "user-space PPS"))
2. The howto doesn't mention the KPPS method at all -- neither ppstest, or the concept.

This is a relevant point, because _I followed the steps in that howto_ and the steps that it left out correspond to the exact situation we're in right now!   -- Both what's broken on our machine, and the configuration you're telling me to use.

This is consistent with comparing user-space with root gpsd.  The user space version (with -D6) shows this block every second:

...
gpsd:PROG: PPS:/dev/ttyS6 Assert ignored missing last_fixtime
gpsd:PROG: TPPS:/dev/ttyS6 ioctl(TIOCMIWAIT) succeeded, time: 1591307910.371319714,  state: 0
gpsd:PROG: TPPS:/dev/ttyS6 Clear, cycle: 999952, duration: 999027 @  1591307910.371319714
gpsd:PROG: PPS:/dev/ttyS6 Clear cycle: 999952, duration: 999027 @  1591307910.371319714
gpsd:PROG: PPS:/dev/ttyS6 Clear ignored missing last_fixtime
gpsd:PROG: TPPS:/dev/ttyS6 ioctl(TIOCMIWAIT) succeeded, time: 1591307910.372309853,  state: 64
gpsd:PROG: TPPS:/dev/ttyS6 Assert, cycle: 1000017, duration: 990 @  1591307910.372309853
gpsd:PROG: PPS:/dev/ttyS6 Assert cycle: 1000017, duration: 990 @  1591307910.372309853
gpsd:PROG: PPS:/dev/ttyS6 Assert ignored missing last_fixtime
...

(full output attached)

while the root invocation shows:

root@gt104:/opt/gpsd# ./gpsd -bnNs 115200 -D6 /dev/ttyS0  |& fgrep PPS
gpsd:PROG: PPS:/dev/ttyS0 chrony socket /var/run/chrony.ttyS0.sock doesn't exist
gpsd:PROG: KPPS:/dev/ttyS0 checking /sys/devices/virtual/pps/pps0/path,
gpsd:PROG: KPPS:/dev/ttyS0 checking /sys/devices/virtual/pps/pps1/path, /dev/ttyS0
gpsd:INFO: KPPS:/dev/ttyS0 RFC2783 path:/dev/pps1, fd is 6
gpsd:INFO: KPPS:/dev/ttyS0 pps_caps 0x1133
gpsd:INFO: KPPS:/dev/ttyS0 have PPS_CANWAIT
gpsd:INFO: KPPS:/dev/ttyS0 kernel PPS will be used
gpsd:PROG: PPS:/dev/ttyS0 thread launched
gpsd:INFO: PPS:/dev/ttyS0 ntpshm_link_activate: 1
gpsd:INFO: KPPS:/dev/ttyS0 kernel PPS timeout unknown error
gpsd:INFO: KPPS:/dev/ttyS0 kernel PPS timeout unknown error
gpsd:INFO: KPPS:/dev/ttyS0 kernel PPS timeout unknown error
gpsd:INFO: KPPS:/dev/ttyS0 kernel PPS timeout unknown error
...

I'm sure you notice how the user-spaceh run remains on "PPS_CANWAIT" / "TIOCMWAIT", while the root-space run selects "kernel PPS".
This would be fine, except our KPPS (the one which requires root) is not working.  (which is clearly out-of-scope for this list)

Question 1:   Running as a normal user _seems_ to select "plain PPS",  but I'm not seeing any output.  This may be due to the "missing last_fixtime"...  are these errors the problem?
gpsd:PROG: PPS:/dev/ttyS6 Clear ignored missing last_fixtime
gpsd:PROG: PPS:/dev/ttyS6 Assert ignored missing last_fixtime
 
Question 2: Does gpsd still support user space PPS, like the documentation seems to say?

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.

> 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"
 
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)

From "Running GPSD", Para 7:
https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_running_gpsd

> "In general, if you start gpsd as other than root, the following things will happen that degrade the accuracy of reported time:"
>
> "1. Devices passed on the command line will be unable to use KPPS 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 implies that user-space still interprets PPS, albeit at reduced accurary.  This is then explicity restated in bullet 1.

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

Attachment: gpspipe.3s.log
Description: Binary data

Attachment: gpsd.D6.root.log
Description: Binary data

Attachment: gpsd.D6.user.log
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]