Re: pps_capture() and pps_fetch()

--------
Sebastian Huber writes:
> On 03.06.22 10:28, Poul-Henning Kamp wrote:
> >> The expensive part in pps_event() is after the th_generation checks. I
> >> think from a performance point of view, the checks can be reduced to
> >> just one th_generation check. I am more concerned if this would
> >> introduce a subtle functional change.
> > Assuming that your timecounter hardware does not roll over fast enough
> > to open any races, I think that is correct.
>
> Would a timecounter overflow within a time interval from th_generation=20
> to th_generation + 1 not be a bug in general?

No, that is precisely the problem timecounter/timehands were made to solve.

We keep a ring of "timehands"[1] and they are all remain valid until
they get reused (at which point their th_generation get incremented).

pps_capture() latches both the (current) timehand, and that timehand's generation.

Even if the timehand is advanced 15 times before pps_event() finally gets called,
the latched timehand can still be used to calculate the time of the event.

If the frequency is adjusted between pps_capture() and pps_event()
that introduces an error in the resulting timestamp, but since they are
supposed to be called "as fast as possible after each other", and since
stable-state frequency adjustments are supposed to be tiny, that error
can be ignored until you get well into Cesium territory.

So as long as your timecounter does not overflow faster than timehands
are updated, and you call pps_event() fast enough after pps_capture(),
you're fine.

Poul-Henning

[1] Originally the ring was ten timehands, based on some handwaving
about interrupt service times on PC hardware back then.  Thesedays
the size of the ring is set with a sysctl, defaulting to just two.
You may want to increase that a bit for pps-capture.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.