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

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

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

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. I personally do want this feature
long-term, definitely, but I do not see ATM it's going to be something
we can deliver for 2.6. Maybe we can split out the lower bits and
prepare I-pipe as well as the hal already.

Jan


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