Re: SatPulse: server-oriented alternative to gpsd for chrony

--0000000000007a0edf065144fa18
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 7, 2026 at 9:27=E2=80=AFPM Miroslav Lichvar <[email protected]=
m> wrote:

> In case you have some code ready for testing, the multi-clock MR [1]
> now has a "clock" option in the refclock directive to specify the
> target clock (by default it's the main system clock).
>

No code yet. Been busy getting 0.2 out the door.


> For a direct synchronization of the PHC on eth0 using a SOCK refclock
> chronyd can be configured like this:
>
> clock PHC:eth0 main
> refclock SOCK /var/run/refclock.sock clock PHC:eth0 poll 0
>
> It seems to be working nicely with ptp4l as a SOCK source (clock_servo
> set to refclock_sock).
>

This is very interesting. So the  PHC-based refclock_sock output you were
suggesting for SatPulse would be the same format as ptp4l produces with
clock_servo as refclock_sock? That would be nicely uniform.

I am wondering whether using PHC as the main clock could result in more
accurate time being served to clients compared to using the system clock as
the main clock, assuming you had PHC-based refclock_sock input from
SatPulse, hardware timestamping and no PTM, since you wouldn't have the
inaccuracy from translating between PHC and system clocks.

James

--0000000000007a0edf065144fa18
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, May 7, 2026 at 9:27=E2=80=AFPM Mi=
roslav Lichvar &lt;<a href=3D"mailto:[email protected]">[email protected]=
om</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
In case you have some code ready for testing, the multi-clock MR [1]<br>
now has a &quot;clock&quot; option in the refclock directive to specify the=
<br>
target clock (by default it&#39;s the main system clock).<br></blockquote><=
div><br></div><div>No code yet. Been busy getting 0.2 out the door.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For a direct synchronization of the PHC on eth0 using a SOCK refclock<br>
chronyd can be configured like this:<br>
<br>
clock PHC:eth0 main<br>
refclock SOCK /var/run/refclock.sock clock PHC:eth0 poll 0<br>
<br>
It seems to be working nicely with ptp4l as a SOCK source (clock_servo<br>
set to refclock_sock).<br></blockquote><div><br></div><div>This is very int=
eresting. So the=C2=A0 PHC-based refclock_sock output you were suggesting f=
or SatPulse would be the same format as ptp4l produces with clock_servo as =
refclock_sock? That would be nicely uniform.</div><div><br></div><div>I am =
wondering whether using PHC as the main clock could result in more accurate=
 time being served to clients compared to using the system clock as the mai=
n clock, assuming you had PHC-based refclock_sock input from SatPulse, hard=
ware timestamping and no PTM, since you wouldn&#39;t have the inaccuracy fr=
om translating between PHC and system clocks.</div><div><br></div><div>Jame=
s</div><div><br></div><div><br></div></div></div>

--0000000000007a0edf065144fa18--

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]