Date: Fri, 03 Jun 2022 18:47:06 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Sebastian Huber <sebastian.huber@embedded-brains.de> Cc: Konstantin Belousov <kostikbel@gmail.com>, hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() Message-ID: <202206031847.253Il6Y2082105@critter.freebsd.dk> In-Reply-To: <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> 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> <c4fe6a08-24b6-522e-3963-cf03eb994496@embedded-brains.de> <202206030828.2538ScDg080165@critter.freebsd.dk> <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- 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= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202206031847.253Il6Y2082105>