Date: Fri, 3 Jun 2022 10:01:38 +0200 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: Konstantin Belousov <kostikbel@gmail.com> Cc: hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() Message-ID: <c4fe6a08-24b6-522e-3963-cf03eb994496@embedded-brains.de> In-Reply-To: <YphDlMyWxDWvJo5Q@kib.kiev.ua> References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <e1093df0-c719-0421-3e96-c6d7df861a51@embedded-brains.de> <YphDlMyWxDWvJo5Q@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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() comple= tes >>>> 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, count= ing at the same rate. >>> >>> The first of the two were the timecounter, the other was started by t= he 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-star= ted 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 time= s >> (pps_capture(): 1, pps_event(): 2) and not only once in pps_event() ri= ght >> before we use the captured time. >=20 > 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 t= he > 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 timecou= nter > advance. >=20 > 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. >=20 > Note that I did not wrote the code and speculataion above is a speculat= ion. I just ask because we may want to use this code in a spacecraft and=20 every "if" increases the time to specify and test the implementation. The expensive part in pps_event() is after the th_generation checks. I=20 think from a performance point of view, the checks can be reduced to=20 just one th_generation check. I am more concerned if this would=20 introduce a subtle functional change. --=20 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=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c4fe6a08-24b6-522e-3963-cf03eb994496>