[chrony-users] Chrony configuration with GPS+direct PHC

[Kevin P. Fleming]

(apologize in advance for the length of this post, it's a bit of a
brain-dump <G>)

I've got a machine running Debian Testing, with Chrony 4.0-8 and GPSD
3.22-3. It has a U-blox NEO-M8N connected via USB (for NMEA/U-blox
messages only, fed into GPSD which then provides GPS time over SHM).
In addition, the PPS signal output from that module has been connected
to SDP0 on one of the Intel I210 NICs, so that it can be used as a PHC
input.

I've been looking for a few days for information about how to set this
up properly, but it's been challenging since everything I can find
assumes that the user wants to use PTP (generally via the linuxptp
project), but I don't... I'm just using the PHC as a
low-latency/low-jitter path to receive the PPS pulses.

Here's what I've got in chrony.conf now (for testing, so 'noselect' is
intentional):

refclock SHM 0 refid GPS noselect precision 1e-1 poll 8 filter 1000
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS pps precision 1e-7
poll 8 filter 1000
pool us.pool.ntp.org iburst

The 'precision', 'poll 8', and 'filter 1000' settings came from the
GPSD setup/tuning guide, to characterize the behavior of the GPS and
PPS refclocks.

After letting the system run for about 8 hours, this is the result:

'chrony sources'

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 8 377 278 +77ms[ +77ms] +/- 100ms
#x PPS 0 8 377 222 +52ms[ +52ms] +/- 3505us
^- time.cloudflare.com 3 10 377 315 +100us[ +100us] +/- 7210us
^* clock.nyc.he.net 1 10 377 360 -429us[ -516us] +/- 3100us
^- li432-123.members.linode> 2 10 377 300 -946us[ -946us] +/- 70ms
^- linode.ibendit.com 3 10 377 882 -1218us[-1302us] +/- 85ms

'chrony sourcestats'

Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 6 3 21m +3.896 3.216 +78ms 399us
PPS 7 5 25m -0.228 0.042 +52ms 7737ns
time.cloudflare.com 7 5 103m -0.139 0.210 -153us 176us
clock.nyc.he.net 11 8 172m -0.001 0.138 -438ns 312us
li432-123.members.linode> 8 5 120m -0.139 0.460 -1915us 535us
linode.ibendit.com 7 5 103m -0.173 0.426 -1160us 350us

As best I can tell, the GPS and PPS refclocks are quite stable (Std
Dev is very low), but the Offsets are a bit weird, and the PPS
refclock must have the wrong 'base time' because Chrony has decided it
is a falseticker.

If it helps, the PPS signal from the U-blox module is a 100ms pulse,
and I think that explains the '100ms' Last sample variation in the GPS
refclock. I can investigate whether it is possible to adjust the
offset of the pulse's leading edge related to the top-of-second to
eliminate that.

When Direct PHC is being used, how does the PHC's base clock get set?
Does Chrony do that? I'm not concerned about disciplining the PHC's
clock because its frequency appears to be very close to perfect now
:-)

I'm hoping to not have to add ptp4l/phc2sys/timemaster/etc. to this
configuration, since that will add complexity, and I can't quite
figure out to configure them to work in a mode where PTP is not
actually being used :-)

[Miroslav Lichvar]

Post by Kevin P. Fleming
refclock SHM 0 refid GPS noselect precision 1e-1 poll 8 filter 1000
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS pps precision 1e-7
poll 8 filter 1000
pool us.pool.ntp.org iburst

The I210 timestamps both rising and falling edge, so you need to set
the width option to 0.1 to ignore the wrong one.

If you enabled the refclocks log, you would probably see interleaved
samples around 0 ms and 100 ms. The median filter completely fails on
such a distribution, so you get a 50ms offset.

If you could set the pulse width to 500 ms (width 0.5) that would
maximize the PPS locking range. With the 100ms width you will probably
need to find a closer NTP server and/or set the precision/delay of the
SHM refclock to a smaller value and correct its offset.

Post by Kevin P. Fleming
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 6 3 21m +3.896 3.216 +78ms 399us
PPS 7 5 25m -0.228 0.042 +52ms 7737ns
time.cloudflare.com 7 5 103m -0.139 0.210 -153us 176us
clock.nyc.he.net 11 8 172m -0.001 0.138 -438ns 312us
li432-123.members.linode> 8 5 120m -0.139 0.460 -1915us 535us
linode.ibendit.com 7 5 103m -0.173 0.426 -1160us 350us
If it helps, the PPS signal from the U-blox module is a 100ms pulse,
and I think that explains the '100ms' Last sample variation in the GPS
refclock. I can investigate whether it is possible to adjust the
offset of the pulse's leading edge related to the top-of-second to
eliminate that.

SHM 0 from gpsd is supposed to be the message-based timing, not PPS.
That 100 ms is probably the configured precision. You should set the
offset option to 0.078 to correct the offset though.

Post by Kevin P. Fleming
When Direct PHC is being used, how does the PHC's base clock get set?
Does Chrony do that? I'm not concerned about disciplining the PHC's
clock because its frequency appears to be very close to perfect now
:-)

chronyd doesn't touch it. It just tracks its offset. If you needed the
PHC to be synchronized, that would be a problem :).
--
Miroslav Lichvar

[Kevin P. Fleming]

Post by Miroslav Lichvar
If you could set the pulse width to 500 ms (width 0.5) that would
maximize the PPS locking range. With the 100ms width you will probably
need to find a closer NTP server and/or set the precision/delay of the
SHM refclock to a smaller value and correct its offset.

Thanks! That made a big difference :-) With the pulse width in the
receiver set to 500ms, and the chrony configuration:

refclock SHM 0 refid GPS precision 1e-1 offset 0.065
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS width 0.5 precision 1e-7

Chrony is quite happy with the PPS refclock now, but not so happy with
the GPS refclock; I'll have to discuss that with the gpsd team.

***@edge21-b:~# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#- GPS 0 4 377 13 -3989us[-4040us] +/- 100ms
#* PPS 0 4 377 8 +23ms[ +23ms] +/- 17ms
^- linode1.ernest-doss.org 3 10 173 292 -29ms[ -29ms] +/- 65ms
^+ dynamic-75-76-123-222.kn> 2 10 377 179 -27ms[ -27ms] +/- 57ms
^+ voipmonitor.wci.com 2 10 377 12 -25ms[ -25ms] +/- 45ms
^- 216.228.192.52 3 10 377 21 -32ms[ -32ms] +/- 155ms

***@edge21-b:~# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 10 6 143 -16.475 87.303 -3134us 2502us
PPS 6 4 81 +0.015 0.127 +23ms 940ns
linode1.ernest-doss.org 6 4 103m +0.111 0.505 -29ms 274us
dynamic-75-76-123-222.kn> 11 5 172m -0.326 0.325 -31ms 758us
voipmonitor.wci.com 7 5 103m +0.243 0.739 -25ms 524us
216.228.192.52 10 7 154m +0.005 0.071 -32ms 145us

[Miroslav Lichvar]

Post by Kevin P. Fleming
refclock SHM 0 refid GPS precision 1e-1 offset 0.065
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS width 0.5 precision 1e-7
Chrony is quite happy with the PPS refclock now, but not so happy with
the GPS refclock; I'll have to discuss that with the gpsd team.

It looks ok to me. The message-based refclock is normally not expected
to be very stable or accurate, which is why it's recommended to
disable it for timekeeping by the noselect option and only use to
"lock" the PPS refclock.
--
Miroslav Lichvar

[Kevin P. Fleming]

Post by Miroslav Lichvar

Post by Kevin P. Fleming
refclock SHM 0 refid GPS precision 1e-1 offset 0.065
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS width 0.5 precision 1e-7
Chrony is quite happy with the PPS refclock now, but not so happy with
the GPS refclock; I'll have to discuss that with the gpsd team.

It looks ok to me. The message-based refclock is normally not expected
to be very stable or accurate, which is why it's recommended to
disable it for timekeeping by the noselect option and only use to
"lock" the PPS refclock.

Alright, I've made that change too. As long as I can manage to get
proper time out of this system even when there are no external NTP
servers reachable, I'm in good shape :)

[Kevin P. Fleming]

Post by Kevin P. Fleming

Post by Miroslav Lichvar

Post by Kevin P. Fleming
refclock SHM 0 refid GPS precision 1e-1 offset 0.065
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS width 0.5 precision 1e-7
Chrony is quite happy with the PPS refclock now, but not so happy with
the GPS refclock; I'll have to discuss that with the gpsd team.

It looks ok to me. The message-based refclock is normally not expected
to be very stable or accurate, which is why it's recommended to
disable it for timekeeping by the noselect option and only use to
"lock" the PPS refclock.

Alright, I've made that change too. As long as I can manage to get
proper time out of this system even when there are no external NTP
servers reachable, I'm in good shape :)

Unfortunately that was not successful; Chrony locks onto the PPS
refclock for a few seconds, then changes to an external server and
marks the PPS refclock as 'x'. Should I add a 'lock' directive to the
PPS refclock to force it to be combined with the GPS refclock?

If it's useful, I've posted a refclocks log at
https://km6g.us/1-refclocks-log.txt.

[Miroslav Lichvar]

Post by Kevin P. Fleming
Unfortunately that was not successful; Chrony locks onto the PPS
refclock for a few seconds, then changes to an external server and
marks the PPS refclock as 'x'. Should I add a 'lock' directive to the
PPS refclock to force it to be combined with the GPS refclock?
If it's useful, I've posted a refclocks log at
https://km6g.us/1-refclocks-log.txt.

It looks like the GPS is still generating a PPS signal with 100ms
width. Maybe that setting to 500ms was not saved to EEPROM and it was
reset back after power cycle?

Enabling the lock option would be recommended, but that is not related
to the PPS width problem.
--
Miroslav Lichvar

[Kevin P. Fleming]

Post by Miroslav Lichvar

Post by Kevin P. Fleming
Unfortunately that was not successful; Chrony locks onto the PPS
refclock for a few seconds, then changes to an external server and
marks the PPS refclock as 'x'. Should I add a 'lock' directive to the
PPS refclock to force it to be combined with the GPS refclock?
If it's useful, I've posted a refclocks log at
https://km6g.us/1-refclocks-log.txt.

It looks like the GPS is still generating a PPS signal with 100ms
width. Maybe that setting to 500ms was not saved to EEPROM and it was
reset back after power cycle?
Enabling the lock option would be recommended, but that is not related
to the PPS width problem.

Thanks, I'll investigate both. Your help has been very much appreciated :)

[Kevin P. Fleming]

Post by Miroslav Lichvar

Post by Kevin P. Fleming
Unfortunately that was not successful; Chrony locks onto the PPS
refclock for a few seconds, then changes to an external server and
marks the PPS refclock as 'x'. Should I add a 'lock' directive to the
PPS refclock to force it to be combined with the GPS refclock?
If it's useful, I've posted a refclocks log at
https://km6g.us/1-refclocks-log.txt.

It looks like the GPS is still generating a PPS signal with 100ms
width. Maybe that setting to 500ms was not saved to EEPROM and it was
reset back after power cycle?
Enabling the lock option would be recommended, but that is not related
to the PPS width problem.

Just to close out this thread: my initial attempt to configure the
timepulse (from a u-Blox M8N) was not successful, but the second
attempt was. The PPS refclock now shows up only once per second in the
reflocks log.

With that change made, and this configuration in chrony.conf:

refclock SHM 0 refid GPS precision 1e-1 offset 0.055 noselect
refclock PHC /dev/ptp3:extpps:nocrossts refid PPS width 0.5 lock GPS
precision 1e-7
pool us.pool.ntp.org iburst

I have these results:

***@edge21-b:~# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 4 377 15 +38ms[ +38ms] +/- 100ms
#* PPS 0 4 377 14 -15ns[ -45ns] +/- 1227ns
^- clock.fmt.he.net 1 10 377 568 -597us[ -588us] +/- 36ms
^- t2.time.gq1.yahoo.com 2 10 377 653 -718us[ -705us] +/- 37ms
^- 45.15.168.198 2 10 373 678 +795us[ +809us] +/- 52ms
^- tick.srs1.ntfo.org 3 10 377 443 -1316us[-1312us] +/- 212ms

***@edge21-b:~# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
GPS 10 8 144 -129.155 142.247 +29ms 4121us
PPS 6 3 81 -0.000 0.002 -1ns 12ns
clock.fmt.he.net 29 15 378m +1.124 0.081 +178us 811us
t2.time.gq1.yahoo.com 17 11 275m +1.111 0.182 +1929us 914us
45.15.168.198 9 4 154m +0.994 0.288 +3233us 468us
tick.srs1.ntfo.org 6 3 86m +1.319 3.044 +1241us 1371us

The SHM refclock shows a variable offset on top of the 55ms that I've
included in the configuration, but it's well within the 200ms
threshold for locking to the PPS refclock.