Jan Kiszka <[email protected]> writes:
> 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). > 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. -- Philippe.
