From nobody Fri Jun 03 18:47:06 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 858E11B55A56 for ; Fri, 3 Jun 2022 18:47:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 4LFBgw3KFYz4jHL for ; Fri, 3 Jun 2022 18:47:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B2E7F89298; Fri, 3 Jun 2022 18:47:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 253Il7St082106 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jun 2022 18:47:07 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 253Il6Y2082105; Fri, 3 Jun 2022 18:47:06 GMT (envelope-from phk) Message-Id: <202206031847.253Il6Y2082105@critter.freebsd.dk> To: Sebastian Huber cc: Konstantin Belousov , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <202206030828.2538ScDg080165@critter.freebsd.dk> <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> 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-ID: <82103.1654282026.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 03 Jun 2022 18:47:06 +0000 X-Rspamd-Queue-Id: 4LFBgw3KFYz4jHL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N -------- 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=3D= 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 gen= eration. 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= .