On Wed, Sep 11, 2024 at 08:48:16PM -0700, Stephen Oneto wrote: > What I (probably incorrectly) infer from this statement is that the PPS > refclock will take the system time at the point of PPS assertion and the > SOCK refclock is responsible for telling chrony what UTC second that PPS > signal is associated with.
It is, but not directly. chronyd compares the offsets provided by the two refclocks. It needs to work even when the system clock is not synchronized yet. > If such is the case, does this mean I can simply send the GPS fix time > (i.e. the UTC second that it will be at the next PPS assertion) once per > second over the socket in advance of the PPS assertion while the PPS > refclock is locked to this SOCK refclock? Would I just leave the offset as > 0 since chrony would be using the PPS timestamp generated by the PPS > refclock as the time to compare the fix time with? The SOCK sample time should be the system time when the message containing the fix time is received and the offset should be the difference between the fix time and sample time. You say UTC second at the next PPS assertion. I don't know if that is specific to your receiver. Usually the message follows the pulse, at least in NMEA and similar. If the message comes earlier, the offset option of the SOCK refclock would need to be negative. I'd suggest to start with the SOCK refclock alone and only when that works well (within few tens of milliseconds?), add the PPS refclock. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
