Re: [Xenomai-core] Question about getting system time

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 4854 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Mauerer wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Wolfgang Mauerer wrote:
>>>>>>> On the one hand you make complicated code (which will be costly on low
>>>>>>> end hardware) to avoid shutting interrupts around a few assignments, but
>>>>>>> on the other hand you leave an architecture specific function pointer
>>>>>>> call where we want a fast behaviour on average (remember, we do all this
>>>>>>> to avoid a system call, which is only a few hundreds nanoseconds on your
>>>>>>> big iron x86), and where we have a generic fast replacement. Sometimes,
>>>>>>> I do not understand your logic.
>>>>>> But using the same argument, you could get rid of Linux vsyscall based
>>>>>> gettimeofday()...
>>>>> I do not see your point, the Linux code does not go a long way to make
>>>>> lockless code, it simply turns off interrupts around the gtod data
>>>>> update, which is really reasonable given the size of the masking
>>>>> section. The reading is lockless, the writing is not.
>>>>>
>>>> I was referring to the argument that system calls are so fast that
>>>> replacing gtod with a syscall-less version that uses function
>>>> pointer dereferencing instead does not make much of a difference.
>>> That is not what I said. I compared the weight of a function pointer
>>> call with the one of four asignments with irqs off. And yes syscalls are
>>> fast on x86, do the measurements yourself, you may be surprised.
>>>
>>>> Be it as it may, I need to check how far our budget can cover
>>>> the (much more comprehensive) modifications required for the
>>>> solution suggested by you. Let's see.
>>> I do not think there is that much work involved. The way I see it, we
>>> would need to replace our tsc reading function with one returning
>>> "ntp-corrected" tsc (that is, essentially a subset of the gettimeofday
>>> function you implemented, without conversion to ns and to CLOCK_REALTIME).
>>>
>>> Changes in this monotonic clock would trigger a recomputation of the
>>> next timer event date.
>>> Changes in monotonic to real-time conversion would trigger a call to
>>> xnpod_set_time.
>> If all works out well, it might be that simple. But this is timer/clock
>> stuff, the heart of the system, and easy to get subtly wrong.
>>
>> For that reason the plan was to gain more confidence in the externally
>> corrected clock source, collect experience in other use cases, and then
>> work on the core for its optional use.
>>
>> So far our customer is using this clock for important but not yet
>> critical jobs. Making it the RT clock source is of a different quality,
>> and for now without a use case.
> 
> To be quite frank about use cases, I do not really understand in what
> use case the patch Wolfgang sent is useful. An application can not use
> the timestamps returned by this gettimeofday syscall for anything
> useful. And if we talk about things breaking subtly, an application that
> would use these timestamps with Xenomai services would be subtly broken
> too.

Just like it seems to be the case for Steve (unless I misunderstood his
reply), it is very useful for us being able to time-stamp events in RT
context that need to be correlated with events stamped in non-RT
(including non-Xenomai) parts or even on other systems: (offline) data
fusion, logging, tracing. I even bet that this is currently the major
use case for synchronized clocks, only a smaller part already has the
need to synchronize timed activities on a common clock source. But there
is huge potential in the second part once we can provide a stable
infrastructure.

> 
> Avoiding the drift between Xenomai clock and Linux clock by making them
> synchronized by design, on the other hand, albeit probably solving a
> corner case, looks more useful, and some people asked for it (it looks
> to me like what Steve asked for is that, not to have a third timebase

It is surely more useful, but also more complex. Nothing unsolvable, but
asking for more care.

> accessible in real-time context, and Steve asked for a solution for
> powerpc, not for x86).

Even a "third clock" would have to be delivered for more archs than x86,
no question. We would basically need a generic but slow syscall variant
and per-arch syscall-less optimizations (where feasible).

> 
> So, my feeling about all this is that Wolfgang's patch is not useful for
> anyone else than your customer.
> 

I think your feeling is a bit too pessimistic on this general approach
and a bit too optimistic regarding the complexity of a complete
solution. But I wouldn't mind being proven wrong, specifically regarding
the latter. However, let's see if we can do some uncontroversial steps
in this direction.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]