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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Wolfgang Mauerer wrote:
> [moved to xenomai-core]
> 
> Gilles Chanteperdrix wrote:
>> Wolfgang Mauerer wrote:
>>>> - gettimeofday should not have another timebase than
>>>> clock_gettime(CLOCK_REALTIME): in other word, the whole clock system
>>>> should be based on the ntp clock.
>>> Sorry, I'm not quite sure what you are talking about here. The NTP
>>> corrections are provided for the clock offered in the vsyscall page
>>> by Linux, so the clock is based on the NTP clock, isn't it? Or
>>> am I misparsing your statement?
>> Unless I misunderstood your patch, what you provide is:
>> gettimeofday which uses linux timebase
>> clock_gettime which uses Xenomai timebase unrelated to linux' timebase
>> This is unacceptable. What we want is a unique timebase.
> 
> okay, I see your point now. But this sound more like 3.0 stuff, doesn't
> it? The goal right now is just to have some code that generates
> synchronised, NTP corrected timestamps on Linux and Xenomai, not
> to rework the base timer handling.

We are going to open a 2.6 branch soon (we are migrating Xenomai to a
new hoster, and this job is almost finished). This will go to 2.6. And I
am not going to merge anything that would provide two different
timebases for CLOCK_REALTIME. That is too unnatural. There are a bunch
of natural things which will not work with this approach. It create many
ways to shoot oneself in the foot. So the answer is definitely no.

>> vread is a function pointer call, which:
>> - requires vsyscalls, currently only implemented on x86 (and maybe ppc)
>> - is function pointer call, so damn slow on low end hardware.
> 
> ... and fast as lightning on x86 when the call is made often, which
> is the important case when speed matters. So it makes sense on this
> platform.

rdtsc is even faster. It is just one instruction.
The generic solution is even faster than the architecture specific one.
So, please implement the generic one.

>> 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()...
> 
> Would having the synchronised time stamp feature (maybe by another name
> than gettimeofday()) conditionally compiled on x86 be acceptable?

No. We have a generic implementation at hand for a limited amount of
additional effort. Let us do things properly.

-- 
					    Gilles.