Date: Wed, 8 Jun 2022 10:15:55 +0200 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Konstantin Belousov <kostikbel@gmail.com>, hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() Message-ID: <8ced022c-518a-4a77-135f-37d58cde27e7@embedded-brains.de> In-Reply-To: <202206031847.253Il6Y2082105@critter.freebsd.dk> 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> <202206031847.253Il6Y2082105@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/06/2022 20:47, Poul-Henning Kamp wrote: > -------- > 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 enoug= h >>> to open any races, I think that is correct. >> >> Would a timecounter overflow within a time interval from th_generation= =3D20 >> to th_generation + 1 not be a bug in general? >=20 > No, that is precisely the problem timecounter/timehands were made to so= lve. >=20 > 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). >=20 > pps_capture() latches both the (current) timehand, and that timehand's = generation. >=20 > Even if the timehand is advanced 15 times before pps_event() finally ge= ts called, > the latched timehand can still be used to calculate the time of the eve= nt. I think this is how I understood how it works. >=20 > 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. Ok. >=20 > 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. This is what I tried to clarify. I think the requirement that the=20 timercounter does not overflow faster than an associated timehand gets=20 updated is applicable also to the functions getting the time, for=20 example using bintime_off(). This is probably related to the tc_min_ticktock_freq =3D max(1, tc->tc_frequency / (((uint64_t)tc->tc_counter_mask + 1) / 3)); code in tc_windup(). I don't understand the value "3" here, I guess it=20 should depend on timehands_count? --=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?8ced022c-518a-4a77-135f-37d58cde27e7>