> From my perspective, the natural way to do a PPS-based SOCK for sawtooth
> corrections is:
>
> - tv being the top of the UTC second to which the correction applies
> - offset being the fractional part of the time of the pulse measured in UTC
I'm not sure if that would work reliably. chronyd might reject the
measurement as being from future.
I could delay the PPS-based SOCK message and deliver it at the same time as the serial-timing based SOCK message.
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.
So the basic idea would be that it would be like a refclock PPS or refclock PHC:extpps, but sawtooth-corrected?
There's another CM4/5 limitation relevant here: reading the PHC is a very slow operation on the CM4/5 and timestamp events that occur during the read are lost. So to make things reliable one needs to schedule reads so that they don't happen at the same time as the start of a pulse. SatPulse does the PTP_SYS_OFFSET ioctl immediately after the timestamp event is delivered. So overall I prefer an approach where the same process is both reading the external timestamp and doing the PTP_SYS_OFFSET ioctls.
If a PHC is not available, then I think the current serial timing SOCK refclock is sufficient. I don't think sawtooth corrections will make a significant difference when using kernel PPS.
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.
1. An approach where SatPulse didn't need to access the PHC would be attractive to me because it would reduce the permissions needed by SatPulse and I also think it is a nice separation of concerns: SatPulse would then be concerning itself purely with the serial messages from the GPS.
2. Currently SatPulse adjusts the PHC, so won't work directly with chrony hardware timestamping, which needs a free-running PHC. (Will this still be the case with the multi-clock MR?) The easiest way to fix this is to make SatPulse aware of vclocks. I have an issue for this (
https://github.com/jclark/satpulse/issues/26), but I am not sure how to give a nice user experience (suggestions welcome).
3. SatPulse's PHC support is focused on synchronizing the PHC to the GPS PPS. Chrony samples are a by-product of this. If I was implementing something where the only goal was to provide refclock SOCK samples based on a free-running PHC, it would be quite a bit different. Maybe it would work better.
James