Re: Large gpio interrupt latency

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 22.06.21 11:31, Philippe Gerum wrote:
>> 
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 22.06.21 10:37, Philippe Gerum wrote:
>>>>
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> On 22.06.21 09:49, Julien Blanc via Xenomai wrote:
>>>>>> Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a
>>>>>> écrit :
>>>>>>>
>>>>>>> With this in mind, assuming that we have previously sanitized the
>>>>>>> clock
>>>>>>> identifier, doing this:
>>>>>>>
>>>>>>> #define get_timestamp(__clock) \
>>>>>>> ({ (__clock) == CLOCK_MONOTONIC ? rtdm_clock_read_monotonic() :
>>>>>>> rtdm_clock_read(); })
>>>>>>>
>>>>>>> may end up being faster than:
>>>>>>>
>>>>>>> xnticks_t (*__get_timestamp)(clockid_t clock);
>>>>>>> #define get_timestamp(__clock)	__get_timestamp(__clock)
>>>>>>
>>>>>> Is really a runtime switch necessary ? Since relying on the realtime
>>>>>> clock is inherently broken, my understanding is that it should be kept
>>>>>> as compatibility purpose only.
>>>>>
>>>>> Again: The real-time clock is not a broken clock per se. It is the basis
>>>>> of many services (POSIX...) and - if managed properly - it is as sound
>>>>> clock to build upon. If you need absolute timestamps to calculate
>>>>> absolute timeouts (like users of the existing code do), this is the
>>>>> clock to go, also in future versions.
>>>>
>>>> Definitely correct, for timeout specs.
>>>>
>>>>> Also if you want to use
>>>>> PTP-sync'ed clocks across systems (TSN...), it is THE way to go. At that
>>>>> point, monotonic timestamps will lose relevance in practice.
>>>>>
>>>>
>>>> We are not there yet. So, let's all agree than we need both clock bases,
>>>> and a flexible way to select the current one.
>>>>
>>>
>>> What's still missing with Dovetail and a Linux-operated PTP sync for the
>>> main clocksource? Hardending of software-based sync paths? Where it's
>>> hw-based, that should already be fine (latest Intel SOCs).
>>>
>> 
>> Again, we have two use cases: absolute timeouts based on a common epoch
>> which may change, and delays. We do know PTP with hw-based support is an
>> efficient way to maintain consistency among users of the former,
>> nevertheless we still need to express/measure strict delays in other
>> cases. So, we do need both clocks.
>> 
>
> If you need cross-system event stamping, the unsync'ed monotonic clock
> is the wrong choice as well.
>

As usual, it's a trade-off, a risk assessment between observing
non-coherent SMP readings and warp jumps. This is a call an application
should be allowed to make, I see no reason to impose a solution
arbitrarily without knowing what the app actually wants to do.

> Again: What is missing to use PTP-sync'ed clock-realtime under Dovetail
> today?
>

Nothing when it comes to reading timestamps, via the NMI-safe
ktime_get_real_fast_ns() service (updates will be non-preemptible while
holding the seqlock).

-- 
Philippe.