Re: pps_capture() and pps_fetch()

From: Sebastian Huber <sebastian.huber_at_embedded-brains.de>
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/