Re: pps_capture() and pps_fetch()

On Wed, Jun 01, 2022 at 01:03:19PM +0200, Sebastian Huber wrote:
> Hello Poul-Henning,
> 
> On 01/06/2022 09:25, Poul-Henning Kamp wrote:
> > Sebastian Huber writes:
> > 
> > > I try to understand how the PPS synchronization works in FreeBSD. It
> > > seems that pps_capture() starts a transaction and pps_event() completes
> > > the transaction if nothing interfered in the meantime.
> > The answer to most of your questions are in ./i386/i386/elan-mmcr.c
> > 
> > The PPS capture in the Soekris 4501 used two hardware counters, counting at the same rate.
> > 
> > The first of the two were the timecounter, the other was started by the hardware signal.
> > 
> > Sometime later the hardware signals interrupt processing would happen.
> > 
> > By reading read both counters as close to instantaneously as possible, and compensated for the interrupt latency by subtracting the event-started counter from the timecounter.
> > 
> > (See also:http://phk.freebsd.dk/soekris/pps/)
> 
> thanks for the background information.
> 
> What I don't understand is why the th_generation is checked three times
> (pps_capture(): 1, pps_event(): 2) and not only once in pps_event() right
> before we use the captured time.

I am not sure about supposed use of the pps(9) API, but for me it looks
like generation rechecks cut potentially CPU-consuming computation in the
interrupt handler context.  For instance, pps_event() seems to be used _some_
time after pps_capture(), and needs to do a lot.  So there is a chance
that the data from pps_capture() is already not relevant due to timecounter
advance.

On the other hand, single read of the generation should be quite cheap,
the cache line should be hot and we spent it to avoid larger waste.  In
other words, doing it probably slighly improves system latency.

Note that I did not wrote the code and speculataion above is a speculation.