On 22.06.21 10:37, Philippe Gerum wrote: > > Jan Kiszka <[email protected]> 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
