| Re: [chrony-users] Synchronizing clock with GPS with PPS |
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]
I do not use gpsd for the pps. I use the serial port to read the interrupt modprobe ppl-ldisk ldattach 18 /dev/ttyS0 Now I have no idea what kind of device a ttyAMA0 is (USB emulation of a serial port?) Sticking another program (gpsd) between the device and the kernel does not seem like a great idea to me. But then I do not use something like a Rasberry. William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273 Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/ On Tue, 15 Sep 2020, Ryan Govostes wrote:
Seems like gpsd hardcodes /dev/ttyAMA0 as “oh you’re using a Raspberry Pi HAT” and then
uses /dev/pps0, which would be the GPIO PPS source. Otherwise it searches sysfs to find
the PPS device for the given NMEA device.
The reason it has to have that hardcoded is because the kernel pps-gpio driver does not
populate the `path` for the corresponding serial device with the NMEA feed. (Perhaps it
should let you override it if that GPIO PPS source corresponds with a separate device.)
https://github.com/torvalds/linux/blob/master/drivers/pps/clients/pps-gpio.c
Since I’m using /dev/ttyAMA1, that hack doesn’t trigger.
I’ll file a bug against gpsd for this case.
Ryan
On Sep 15, 2020, at 4:33 PM, Ryan Govostes <rgovostes@xxxxxxxx> wrote:
I can confirm that /dev/ttyAMA1 streams incoming NMEA messages. I can confirm
/dev/pps0 is a working PPS device.
I can confirm that gpsd is configured to access /dev/ttyAMA1 and when I launch it
with
sudo gpsd -n -N -D3 -F /tmp/gpsd.sock /dev/ttyAMA1
I see it getting a satellite fix, suggesting it is receiving NMEA messages just
fine, although it has the /dev/pps1 error messages as below.
If I use `strace` on gpsd, then I see that it connects to
/var/run/chrony.ttyAMA1.sock (/var/run being a symlink to /run it should be OK):
connect(8, {sa_family=AF_UNIX, sun_path="/var/run/chrony.ttyAMA1.sock"}, 30) = 0
I never see it reading or writing file descriptor 8, so it clearly is not sending
anything to chronyd.
It appears that /dev/pps1 is created some time after gpsd starts.
/sys/devices/virtual/pps/pps1 appears and the path file contains the text
/dev/ttyAMA1. gpsd scans through all of these pps/*/path files to find the one
matching the NMEA device it is configured for, so that’s why it ends on
/dev/pps1.
I still don’t know who exactly is creating /sys/devices/virtual/pps/pps1 — strace
doesn’t put the blame on either chronyd or gpsd, but otherwise this is a vanilla
system I installed just a few days ago.
Ryan
On Sep 15, 2020, at 4:05 PM, Avamander <avamander@xxxxxxxxx> wrote:
Check what you have specified in the list of devices to be used.
I personally couldn't convince gpsd to use pps1 instead of pps0, but
you might be having the opposite issue :S
What actually is pps1 on your system? It might play a role.
On Tue, Sep 15, 2020 at 11:02 PM Ryan Govostes <rgovostes@xxxxxxxx>
wrote:
I’m not sure. Its logs look OK, but it prints out:
gpsd:INFO: KPPS:/dev/ttyAMA1 RFC2783 path:/dev/pps1, fd is 9
Note that /dev/pps1 is _not_ the PPS device I expect to use. This
device only appears while gpsd is running so it appears to be created
by it? ppstest only reports timeouts for this one, while pps0
continues to work as expected.
More context:
gpsd:INFO: KPPS:/dev/ttyAMA1 RFC2783 path:/dev/pps1, fd is 9
gpsd:INFO: KPPS:/dev/ttyAMA1 pps_caps 0x1133
gpsd:INFO: KPPS:/dev/ttyAMA1 have PPS_CANWAIT
gpsd:INFO: KPPS:/dev/ttyAMA1 kernel PPS will be used
…
gpsd:INFO: KPPS:/dev/ttyAMA1 kernel PPS timeout Interrupted
system call
…
gpsd:INFO: KPPS:/dev/ttyAMA1 kernel PPS timeout Connection
timed out
Ryan
On Sep 15, 2020, at 3:57 PM, Avamander
<avamander@xxxxxxxxx> wrote:
However, `chronyc` does not report any
updates being received from this source.
If you aren't seeing anything on SHM1 either, then gpsd
still has issues with reading the PPS source. Check its
logs.
On Tue, Sep 15, 2020 at 10:56 PM Ryan Govostes
<rgovostes@xxxxxxxx> wrote:
Ah OK, I guess the part that was not clear to me was that
chronyd _creates_ this socket when configured with
refclock SOCK, rather than simply connecting to it.
When I configured this and restarted chronyd and then
gpsd, it did create the socket file. However, `chronyc`
does not report any updates being received from this
source.
I did not find an AppArmor profile that is currently
being enforced on gpsd.
I did notice that AppArmor was preventing chronyd from
creating /run/chronyd.pps0.sock, so I corrected that and
switched the configuration to:
refclock SOCK /run/chrony.ttyAMA1.sock refid GPS
precision 1e-1
refclock SOCK /run/chrony.pps0.sock refid PPS
precision 1e-7
However I still do not receive any updates.
Ryan
On Sep 15, 2020, at 3:20 PM, Avamander
<avamander@xxxxxxxxx> wrote:
but also I don’t see that socket
you’re referencing being created.
I don’t see any AppArmor logs
that seem to indicate anyone was
prevented from creating this
file.
Have you actually told chrony to create it?
for a while but the PPS never
updated:
Yes, this is exactly why I suggested you
check the AppArmor policy itself. When the
pps device is inaccessible gpsd gives some
vague error about the pps device and that's
it. Open gpsd's log and verify it hasn't
thrown an error about the pps device during
startup.
I couldn’t readily find much
documentation on SHM 0 vs SHM 1.
Yes, this is awfully documented online.
On Tue, Sep 15, 2020 at 10:08 PM Ryan
Govostes <rgovostes@xxxxxxxx> wrote:
Below Bill argued against using
/var/run/chrony.ttyAMA0.sock, but also I
don’t see that socket you’re referencing
being created. I don’t see any AppArmor logs
that seem to indicate anyone was prevented
from creating this file. Perhaps the version
is too old?
I couldn’t readily find much documentation on
SHM 0 vs SHM 1. I did find this, which
suggests using SHM 1 instead of having chrony
go directly to the PPS device, as in:
refclock SHM 0 refid GPS precision
1e-1
refclock SHM 1 refid PPS precision
1e-7
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpsd.gitlab.io%2Fgps
d%2Fgpsd-time-service-howto.html%23_feeding_chrony_from_gpsd&data=02%7C01%7Crgovos
tes%40whoi.edu%7C86536cbb401c44a3c5cc08d859b6a884%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7
C0%7C0%7C637357988356257028&sdata=N%2B8IAnmUrjXdPylbVOLjEXRfEGbG1QrLbGrToTbRHLU%3D
&reserved=0
I restarted chronyd with this configuration
and watched `chronyc sources` for a while but
the PPS never updated:
210 Number of sources = 2
MS Name/IP address Stratum
Poll Reach LastRx Last sample
===============================================================================
#* GPS 0 4
377 22 +1104us[+4464us] +/- 100ms
#? PPS 0 4
0 - +0ns[ +0ns] +/- 0ns
I disabled systemd-timesyncd as you
suggested, thanks.
Ryan
On Sep 15, 2020, at 2:42 PM,
Avamander <avamander@xxxxxxxxx>
wrote:
First, disable systemd-timesyncd
if you're using chrony: sudo
systemctl disable --now
systemd-timesyncd
Second, enable chrony, pretty
sure it isn't enabled by default
after install: sudo systemctl
enable chrony
Why do you want to SHM 0
(non-PPS-corrected) NMEA time,
instead of SHM 1 or
/var/run/chrony.ttyAMA0.sock?
On Tue, Sep 15, 2020 at 9:36 PM
Ryan Govostes
<rgovostes@xxxxxxxx> wrote:
Thanks, I removed the offset and
delay so the reference clock
configuration is now:
refclock SHM 0 refid GPS
precision 1e-1
refclock PPS /dev/pps0
refid PPS
My intention is to have GPS set
the system date and time and then
have the PPS signal keep it from
drifting.
After applying this, I ran again
and am now getting:
MS Name/IP address
Stratum Poll Reach LastRx
Last sample
===============================================================================
#x GPS
0 4
377 16 +587us[ +587us] +/-
100ms
#x PPS
0 4
160 82 -128ms[ -128ms] +/-
759ns
The #x suggests that “time may be
in error.” However I am still
seeing gpsd work (monitored via
cgps) and the PPS device still
appears to be working (according
to ppstest).
Furthermore timedatectl suggests
that the system clock is not
synchronized:
$ timedatectl status
Local time: Tue 2020-09-15
18:34:48 UTC
Universal time: Tue
2020-09-15 18:34:48 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC,
+0000)
System clock synchronized:
no
systemd-timesyncd.service
active: yes
RTC in local TZ: no
What appears to be the problem?
Ryan
On Sep 15, 2020, at
12:47 PM, Bill Unruh
<unruh@xxxxxxxxxxxxxx>
wrote:
William G. Unruh __|
Canadian Institute
for|____ Tel:
+1(604)822-3273
Physics&Astronomy
_|___ Advanced
Research _|____ Fax:
+1(604)822-5324
UBC, Vancouver,BC _|_
Program in Cosmology
|____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1
____|____ and Gravity______|_ https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theory.p
hysics.ubc.ca%2F&data=02%7C01%7Crgovostes%40whoi.edu%7C86536cbb401c44a3c5cc08d859b
6a884%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357988356257028&sdata=EkXZPl
y9ps2U3qVb7qot7CxssLBlwUCyqTblGkx8FKo%3D&reserved=0
On Tue, 15 Sep 2020,
Ryan Govostes wrote:
Hi all,
I am
setting
up
chronyd
on an
embedded
Linux
device to
synchronize
the
system
clock
using a
GPS
module.
The GPS
device
sends
NMEA
strings
over the
character
device
/dev/ttyAMA1
and I
have also
configured
/dev/pps0,
both of
which
appear to
be
working
OK.
The
system is
running
Ubuntu
18.04 and
the
latest
package
versions
are
chronyd
3.2 and
gpsd
3.17.
I
configured
gpsd to
listen to
the
serial
device
and then
added
these
lines to
my
chrony.conf:
refclock
SHM 0
refid GPS
precision
1e-1
offset
0.9999
delay 0.2
Why those figures for
ooffset? That is 1
sec offset. NMEA is
not that bad.
refclock
PPS
/dev/pps0
refid PPS
When I
run
`chronyc
sources`
they both
seem to
be kind
of
working:
210
Number of
sources =
2
MS
Name/IP
address
Stratum
Poll
Reach
LastRx
Last
sample
===============================================================================
#-
GPS
0
4 377
12
+128ms[
+128ms]
+/-
200ms
#*
PPS
0
4 377
12
+6ns[
+119ns]
+/-
203ns
However
it looks
like the
GPS
source is
“not
combined”.
Is this a
degraded
state,
e.g., it
is using
one of
these two
sources?
Why would one want to
combine GPS with PPS.
PPS is good to the
nanosecond
level. GPS toabut 100
ms -- that is almost
a million times
worse. It would be
like combining your
wristwatch with some
clock which says "its
spring so it must be
April".
Also, I
am not
sure why
the
LastRx
from the
PPS (or
frankly
either)
ticks
upwards
so
long—shouldn’t
it
constantly
be
receiving
updates?
Yout tell it that
POLL is 4 which means
16 seconds. So every
16 seconds that
clock is read. The
driver massages the
input ( once a
second) to get rid of
obvious outliers but
reports to chrony
once every 16
seconds. Note it is a
bad
idea to reduce the
poll even further.
Then obvious ouliers
are not thrown out,
and the ability to
determine the rate of
the clock is
degraded.
I am just
using the
precision
/ offset
/ delay
figures
that
several
examples
use. Is
there
documentation
on
calibrating
these
values?
Get rid of the offset
and delay. The GPS is
useless except for
setting actual
number of the
seconds.
Finally,
I read
that
using
Unix
sockets
rather
that
shared
memory is
preferable,
but my
chronyd
does not
seem to
create
those
sockets.
Why is it better?
Leave things as they
are. With PPS your
time will be
accurate to
microseconds just as
things are now. Do
you need any better
time?
If you do need time
to nanoseconds, then
you will really have
to throw away
your computer (its
ability to read
interrupts is only at
the microsecond
level) and begin
compensating for
propagation delays in
your gps unit, and
also the sawtooth
offset on the ns
level due to your gps
receiver innards. But
then, why would you
want to know the time
to 1 billionth of a
second?
??????칻 ???&???zf?????????k???|???????????????z???\??????'???۱}?????????*+????????????칻 ???&ފ{az˛??????-??????zZ^?????????r???+???z???+z????????????!????????????_jh???ʊ??????+a???
?? ??i???{az˛??????-N???.nW???????????????+-??????-z???!????????????_jh???ʊ
| Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |