From nobody Thu Jun 2 04:59:00 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 98F7B1B63780 for ; Thu, 2 Jun 2022 04:59:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDDMD1dZtz4lvc for ; Thu, 2 Jun 2022 04:59:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2524x1WC013382 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 2 Jun 2022 07:59:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 2524x0cY013381; Thu, 2 Jun 2022 07:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Jun 2022 07:59:00 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: Poul-Henning Kamp , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() Message-ID: References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4LDDMD1dZtz4lvc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.65 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.98)[0.981]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.959]; NEURAL_SPAM_LONG(0.63)[0.632]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N 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.