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

--0000000000003c8aab064fa70ffe
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; From my perspective, the natural way to do a PPS-based SOCK for sawtoo=
th<br>
&gt; corrections is:<br>
&gt; <br>
&gt; - tv being the top of the UTC second to which the correction applies<b=
r>
&gt; - offset being the fractional part of the time of the pulse measured i=
n UTC<br>
<br>
I&#39;m not sure if that would work reliably. chronyd might reject the<br>
measurement as being from future.<br></blockquote><div><br></div><div>I cou=
ld delay the PPS-based SOCK message and deliver it at the same time as the =
serial-timing based SOCK message.=C2=A0</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
I think tv should be the timestamp from the extts event (if using a<br>
PHC) or pps assert/clear provided by the kernel (rounded to<br>
microseconds). Offset should be the difference to the top of the<br>
second indicated by the serial message and the sawtooth correction.<br></bl=
ockquote><div><br></div><div>So the basic idea would=C2=A0be that it would =
be like a refclock PPS or refclock PHC:extpps, but sawtooth-corrected?</div=
><div><br></div><div>There&#39;s another CM4/5 limitation relevant here: re=
ading the PHC is a very slow operation on the CM4/5 and timestamp events=C2=
=A0that occur during the read are lost. So to make things reliable one need=
s to schedule reads so that they don&#39;t happen at the same time as the s=
tart of a pulse. SatPulse does=C2=A0the PTP_SYS_OFFSET ioctl immediately af=
ter 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.</div><div><br></div><div>If a PHC is not available, then=
 I think the current serial timing SOCK refclock is sufficient. I don&#39;t=
 think sawtooth corrections will make a significant difference when using k=
ernel PPS.</div><div><br></div><div>If a PHC is available, the current SatP=
ulse refclock handles this and provides sawtooth-corrected samples to chron=
y.=C2=A0 So the question is what could be the advantages of an alternative =
approach.</div><div><br></div><div>1. An approach where SatPulse didn&#39;t=
 need to access the PHC would be attractive to me because it would reduce t=
he permissions needed by SatPulse and I also think it is a nice separation =
of concerns: SatPulse would then be concerning itself purely with the seria=
l messages from the GPS.</div><div>2. Currently SatPulse adjusts the PHC, s=
o won&#39;t work directly with chrony hardware timestamping, which needs a =
free-running PHC. (Will this still be the case with the multi-clock MR?)=C2=
=A0The easiest way to fix this is to make SatPulse aware of vclocks. I have=
 an issue for this (<a href=3D"https://github.com/jclark/satpulse/issues/26=
">https://github.com/jclark/satpulse/issues/26</a>), but I am not sure how =
to give a nice user experience (suggestions welcome).</div><div>3. SatPulse=
&#39;s PHC support is focused on synchronizing the PHC to the GPS PPS. Chro=
ny 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.</div><d=
iv><br></div><div>James</div></div></div>

--0000000000003c8aab064fa70ffe--

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