Re: Large gpio interrupt latency

[Jan Kiszka <jan.kiszka@siemens.com>]

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).

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux