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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Fri, Apr 17, 2026 at 07:26:22PM +0700, James Clark wrote:
> > > 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.

My concern was with tv being the reference time instead of local
system time, which wouldn't work if the system clock was significantly
ahead or behind the reference time. I just ran a quick test (with
current git head) in both cases and it seems to work and sync
correctly, so I guess it's ok as it is now.

> 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?

Yes, more like extpps in that it provides full timestamps, not just
PPS sub-second fraction, so there is only one SOCK refclock needed.

> 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.

In chrony the reads done by the PHC refclock driver and HW
timestamping are not scheduled to avoid the top of the second, so they
could collide. How long it takes, like milliseconds? Even if the
chance was 1:100, I'd not expect that to cause problems.

> 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.

Agreed.

> 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? 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. 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?

> 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.

That would need an extension to SOCK to convey the offset corrections
and chrony would need to know how to apply it. If you plan to keep the
ability to synchronize the PHC, this logic would be duplicated.

> 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?)

With the multi-clock feature chronyd can synchronize the PHC on its
own. That can be configured. It doesn't need to be free-running, but
it shouldn't be synchronized by something else. It should either be
chronyd controlling the clock or nothing controlling the clock.

In practice, what matters is that the clock is sufficiently stable
that chronyd doesn't lose its track. If the adjustments done by
satpulsed were slow enough (it seems the P/I constants are
configurable), I think NTP HW timestamping would work fine.

> 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).

IIRC the kernel cannot translate extpps events to a vclock, so that
would need to be developed first.

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.

-- 
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.