Re: pps_capture() and pps_fetch()
- Reply: Poul-Henning Kamp: "Re: pps_capture() and pps_fetch()"
- In reply to: Konstantin Belousov : "Re: pps_capture() and pps_fetch()"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 03 Jun 2022 08:01:38 UTC
On 02.06.22 06:59, Konstantin Belousov wrote: > 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. I just ask because we may want to use this code in a spacecraft and every "if" increases the time to specify and test the implementation. 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. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/