[chrony-users] trying to get Chrony to work with gpsd/PPS GPS

[Bryan Seitz]

Listers,

I was using NTPD with the following configuration for the GPS (Garmin 18xLVC):

### /etc/ntp.conf
driftfile /var/lib/ntp/drift

server clock.fmt.he.net noselect
server ntp-1.vt.edu noselect
server clock.nyc.he.net noselect
server time-b.nist.gov noselect

# Garmin GPS 18 LVC
server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 time2 0.600 flag1 1 flag2 0 flag3 1 refid PPS

It would report offsets of about 0.001 with low jitter as well.

Trying to use the same unit with chrony + gpsd and this configuration:

# Internet sources
server clock.fmt.he.net noselect
server ntp-1.vt.edu noselect
server clock.nyc.he.net noselect
server time-b.nist.gov noselect

refclock SHM 0 offset -0.6 delay 0.5 refid NEMA noselect
refclock SHM 1 offset -0.6 precision 1e-9 lock NEMA refid PPS

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift



Yields wildly varying offsets :(

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? NEMA 0 4 377 9 +675ms[ +675ms] +/- 253ms
#* PPS 0 4 377 8 +7747ns[+8253ns] +/- 5644ns
^? clock.fmt.he.net 1 6 377 55 -600ms[ -600ms] +/- 35ms
^? ntp-1.ipv6.vt.edu 2 6 377 53 -601ms[ -601ms] +/- 35ms
^? clock.nyc.he.net 1 6 377 54 -600ms[ -600ms] +/- 7765us
^? time-b.nist.gov 1 6 377 55 -600ms[ -600ms] +/- 6549us

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? NEMA 0 4 377 10 +669ms[ +669ms] +/- 253ms
#* PPS 0 4 377 8 +2954ns[+2721ns] +/- 5613ns
^? clock.fmt.he.net 1 6 377 38 -600ms[ -600ms] +/- 35ms
^? ntp-1.ipv6.vt.edu 2 6 377 36 -601ms[ -601ms] +/- 36ms
^? clock.nyc.he.net 1 6 377 101 -600ms[ -600ms] +/- 7765us
^? time-b.nist.gov 1 6 377 37 -600ms[ -600ms] +/- 6610us

Chronyc tracking

Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Thu Sep 07 22:48:47 2017
System time : 0.000001081 seconds fast of NTP time
Last offset : +0.000000692 seconds
RMS offset : 0.000000814 seconds
Frequency : 22.380 ppm fast
Residual freq : +0.000 ppm
Skew : 0.010 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000015589 seconds
Update interval : 16.0 seconds
Leap status : Normal


GPSMon Screenshot:

Loading Image...

ntpshmmon output:

# Name Seen@ Clock Real L Prec
sample NTP0 1504824422.059456899 1504824422.059016714 1504824422.000000000 0 -1
sample NTP1 1504824422.400228108 1504824422.399984786 1504824423.000000000 0 -20
sample NTP0 1504824422.559968988 1504824422.059016714 1504824422.000000000 0 -1
sample NTP1 1504824422.900433425 1504824422.399984786 1504824423.000000000 0 -20
sample NTP0 1504824424.045028574 1504824424.044241505 1504824424.000000000 0 -1
sample NTP1 1504824424.400442519 1504824424.399978781 1504824425.000000000 0 -20
sample NTP0 1504824424.545348968 1504824424.044241505 1504824424.000000000 0 -1
sample NTP1 1504824424.900928345 1504824424.399978781 1504824425.000000000 0 -20
sample NTP0 1504824426.041318136 1504824426.041166576 1504824426.000000000 0 -1
sample NTP1 1504824426.400096238 1504824426.399988587 1504824427.000000000 0 -20
sample NTP0 1504824426.541773498 1504824426.041166576 1504824426.000000000 0 -1
sample NTP1 1504824426.900437395 1504824426.399988587 1504824427.000000000 0 -20
sample NTP0 1504824428.051476959 1504824428.050505815 1504824428.000000000 0 -1


Any help would be appreciated!

[Bill Unruh]

I think you are misreading. The offsets are in nanoseconds, not milliseconds.
So you pps is about 100 tp 10000 times better than all of your other sources.

And why do you have your PPS with an offset of .6 sec? Its offset is 0.





William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Bryan Seitz
Listers,
### /etc/ntp.conf
driftfile /var/lib/ntp/drift
server clock.fmt.he.net noselect
server ntp-1.vt.edu noselect
server clock.nyc.he.net noselect
server time-b.nist.gov noselect
# Garmin GPS 18 LVC
server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 time2 0.600 flag1 1 flag2 0 flag3 1 refid PPS
It would report offsets of about 0.001 with low jitter as well.
# Internet sources
server clock.fmt.he.net noselect
server ntp-1.vt.edu noselect
server clock.nyc.he.net noselect
server time-b.nist.gov noselect
refclock SHM 0 offset -0.6 delay 0.5 refid NEMA noselect
refclock SHM 1 offset -0.6 precision 1e-9 lock NEMA refid PPS

Why do you have a .6 offset for this? The PPS occurs exactly on the second and
has no offset.

Post by Bryan Seitz
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
Yields wildly varying offsets :(
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? NEMA 0 4 377 9 +675ms[ +675ms] +/- 253ms
#* PPS 0 4 377 8 +7747ns[+8253ns] +/- 5644ns
^? clock.fmt.he.net 1 6 377 55 -600ms[ -600ms] +/- 35ms
^? ntp-1.ipv6.vt.edu 2 6 377 53 -601ms[ -601ms] +/- 35ms
^? clock.nyc.he.net 1 6 377 54 -600ms[ -600ms] +/- 7765us
^? time-b.nist.gov 1 6 377 55 -600ms[ -600ms] +/- 6549us
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? NEMA 0 4 377 10 +669ms[ +669ms] +/- 253ms
#* PPS 0 4 377 8 +2954ns[+2721ns] +/- 5613ns
^? clock.fmt.he.net 1 6 377 38 -600ms[ -600ms] +/- 35ms
^? ntp-1.ipv6.vt.edu 2 6 377 36 -601ms[ -601ms] +/- 36ms
^? clock.nyc.he.net 1 6 377 101 -600ms[ -600ms] +/- 7765us
^? time-b.nist.gov 1 6 377 37 -600ms[ -600ms] +/- 6610us
Chronyc tracking
Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Thu Sep 07 22:48:47 2017
System time : 0.000001081 seconds fast of NTP time
Last offset : +0.000000692 seconds
RMS offset : 0.000000814 seconds
Frequency : 22.380 ppm fast
Residual freq : +0.000 ppm
Skew : 0.010 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000015589 seconds
Update interval : 16.0 seconds
Leap status : Normal
https://img.bsd-unix.net/screenshots/user1/2850Ab83e.png
sample NTP0 1504824422.059456899 1504824422.059016714 1504824422.000000000 0 -1
sample NTP1 1504824422.400228108 1504824422.399984786 1504824423.000000000 0 -20
sample NTP0 1504824422.559968988 1504824422.059016714 1504824422.000000000 0 -1
sample NTP1 1504824422.900433425 1504824422.399984786 1504824423.000000000 0 -20
sample NTP0 1504824424.045028574 1504824424.044241505 1504824424.000000000 0 -1
sample NTP1 1504824424.400442519 1504824424.399978781 1504824425.000000000 0 -20
sample NTP0 1504824424.545348968 1504824424.044241505 1504824424.000000000 0 -1
sample NTP1 1504824424.900928345 1504824424.399978781 1504824425.000000000 0 -20
sample NTP0 1504824426.041318136 1504824426.041166576 1504824426.000000000 0 -1
sample NTP1 1504824426.400096238 1504824426.399988587 1504824427.000000000 0 -20
sample NTP0 1504824426.541773498 1504824426.041166576 1504824426.000000000 0 -1
sample NTP1 1504824426.900437395 1504824426.399988587 1504824427.000000000 0 -20
sample NTP0 1504824428.051476959 1504824428.050505815 1504824428.000000000 0 -1
Any help would be appreciated!
--
Bryan G. Seitz
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Miroslav Lichvar]

Post by Bryan Seitz
# Garmin GPS 18 LVC
server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 time2 0.600 flag1 1 flag2 0 flag3 1 refid PPS

flag3 enables the kernel PPS discipline, which uses a 1-second update
interval. If you wanted to have something similar with chronyd, you
would need to shorten the polling by adding "poll 0" to the refclock
directive. I think in most cases with a serial PPS input that is too
short, so I'd suggest to try "poll 2" first.

Post by Bryan Seitz
refclock SHM 0 offset -0.6 delay 0.5 refid NEMA noselect
refclock SHM 1 offset -0.6 precision 1e-9 lock NEMA refid PPS

The second "offset -0.6" should be removed. Unless a wrong edge of the
PPS signal is used, the offset is typically just a few microseconds.

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Miroslav Lichvar

Post by Bryan Seitz
# Garmin GPS 18 LVC
server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 time2 0.600 flag1 1 flag2 0 flag3 1 refid PPS

flag3 enables the kernel PPS discipline, which uses a 1-second update
interval. If you wanted to have something similar with chronyd, you
would need to shorten the polling by adding "poll 0" to the refclock
directive. I think in most cases with a serial PPS input that is too
short, so I'd suggest to try "poll 2" first.

I believe that has the disadvantage of loosing the "popcorn" filter. Ie,
occassionally the server will server a time which is really wrong (by 10s of
usec, or msec or sec) about 40% of the times with are really off are thrown
away(really off means that they are furthest from the average.) to get rid of
those. Running with very short poll would mean that that does not work as
well. It is not clear at all why you would want to run with such a short poll
interval.

Post by Miroslav Lichvar

Post by Bryan Seitz
refclock SHM 0 offset -0.6 delay 0.5 refid NEMA noselect
refclock SHM 1 offset -0.6 precision 1e-9 lock NEMA refid PPS

The second "offset -0.6" should be removed. Unless a wrong edge of the
PPS signal is used, the offset is typically just a few microseconds.