Re: [chrony-users] SatPulse: server-oriented alternative to gpsd for chrony

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Apr 14, 2026 at 12:13:11PM +0200, James Clark wrote:
> I am not sure I have understood what you have in mind. Could you explain
> what the tv and offset fields of the sock_sample would be?
> 
> 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 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.
Not sure about the signs, I always get it wrong on first try.

> For the sawtooth-corrected refclock SOCK that SatPulse produces at the
> moment, one of the complexities is that in some cases the sawtooth
> correction comes in a message before the pulse (UBX-TIM-TP) and in some
> cases it comes in a message after the pulse (UBX-TIM-TOS). This is made
> worse by the fact that on the CM4/5 the kernel delivers the PHC timestamp
> between 0 and 0.25 seconds after the pulse actuallly occurred.

This complexity would be better handled on the satpulse side :).
The additional delay of the SOCK sample due to waiting for UBX-TIM-TOS
is ok.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.