> If a PHC is available, the current SatPulse refclock handles this and
> provides sawtooth-corrected samples to chrony. So the question is what
> could be the advantages of an alternative approach.
But the SOCK samples are based on the system clock?
Yes.
In a test with a
config that has both "phc" and "ntp" sections, the offset seems to be
moving when I step either of the PHC or the system clock. It's not
clear to me what is going on there.
Here is how things currently work. In satpulsed's normal mode of operation, it aims to keep the PHC in sync with the GPS. It expects to be the only process adjusting the PHC (it should detect and report if anything else is changing the PHC, but it doesn't do that yet). It monitors the synchronization status and switches between different modes, which determine the clock quality that satpulsed reported to ptp4l; the main mode is "tracking", which is used when the PHC is in sync with the GPS. Immediately after reading each PHC timestamp, it uses PTP_SYS_OFFSET_EXTENDED/PRECISE ioctl to get a cross-sample. When in tracking mode, it generates a chrony sample from the cross-sample, assuming the PHC value in the cross-sample provides the true time.
I'd expect it to be independent
from the system clock. There is also an issue that satpulsed is still
controlling the clock. Could there be a new option to disable that in
order for chronyd to synchronize it?
Yes! For the last few days, I have been implementing a new mode of operation that does not synchronize the PHC. The samples sent to chrony are generated from cross-samples, as in the current syncing mode. It uses GPS messages to associate PHC timestamps with their true times and apply sawtooth corrections to timestamps. It then fits a local linear PHC-to-true-time mapping and evaluates it at the PHC value from the cross-sample.
It is configured just by putting `sync=false` in the `[phc]` section; there's also a new `[sample.phc]` that can configure various parameters of the sample generation algorithm. This is on the phc-sample branch, if you want to try it.
I think this will work a little bit better than the syncing approach when the you don't need the PHC to be synchronized:
- it is less stateful, and lets chrony do more of the work
- it starts up much quicker (about 5s vs 30s)
- avoids any possible conflict with chrony hardware timestamping
It preserves most features of the syncing mode:
- handles Intel dual-edge timestamping automatically
- handles all the CM4/CM5 quirks
- applies sawtooth corrections
Like the syncing mode, it requires 1PPS.
I have put in code to detect and handle PHC discontinuities, so I think it should also work with chrony disciplining the PHC, but my feeling is that this approach is not ideal for that, and another refclock which works along the lines you suggested here would work better:
> > I think tv should be the timestamp from the extts event (if using a
> > PHC) or pps assert/clear provided by the kernel (rounded to
> > microseconds). Offset should be the difference to the top of the
> > second indicated by the serial message and the sawtooth correction.
One question here: for the purpose of determining the difference, should the PHC be treated as being in TAI or UTC?
On the SatPulse side, I would imagine this being a separate path enabled by putting something like `clock="phc"` in the`[ntp]` section. I think it could be implemented reusing some of the code from the mode I just added.
P.S. it seems satpulsed doesn't currently work with /dev/gnss devices
(e.g. provided by some Intel NIC drivers). I'm getting this error:
ioctl(TCGETS) /dev/gnss0: inappropriate ioctl for device
The serial-specific ioctls need to be disabled in this case or their
errors ignored.
Thanks. I have put in a fix for this on master (and phc-sample), but it's a bit more complicated than just not doing the serial-specific ioctls: I have to switch over to using poll for timeouts rather the the VMIN/VTIME serial timeouts. I think Go's netpoller will work with /dev/gnss*, but I am not 100% sure. So it would be great if you could try it out.
James