Re: pps_capture() and pps_fetch()
- Reply: Poul-Henning Kamp: "Re: pps_capture() and pps_fetch()"
- In reply to: Poul-Henning Kamp: "Re: pps_capture() and pps_fetch()"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 08 Jun 2022 08:15:55 UTC
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 enough >>> to open any races, I think that is correct. >> >> Would a timecounter overflow within a time interval from th_generation=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 generation. > > 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. I think this is how I understood how it works. > > 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. > > 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 timercounter does not overflow faster than an associated timehand gets updated is applicable also to the functions getting the time, for example using bintime_off(). This is probably related to the tc_min_ticktock_freq = 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 should depend on timehands_count? -- 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ünchen Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/