Re: [Xenomai-core] RTDM and Timer functions

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

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

Rodrigo Rosenfeld Rosas wrote:
> Em Segunda 13 Março 2006 15:33, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu:
>>>> Jan Kiszka wrote:
>>>>>> Sometimes the result is "Should be near 84000: 100000", that is kind of
>>>>>> correct, since the tickval is 100000, although I think that those
>>>>>> functions in the RTDM driver context should be independent of the tick
>>>>>> value set by the user program... Maybe using oneshot in the driver
>>>>>> calls and periodic in the application... I really don't know what would
>>>>>> be the best approach here...
>>>>> rtdm_clock_read always uses the nucleus clock. Using something different
>>>>> (e.g. always TSC) would break applications specifying absolute times
>>>>> derived from the return values of other skins' functions.
>>>> Maybe adding a service to RTDM would allow users to measure short time
>>>> intervals with RTDM using the TSC ?
>>>>
>>>> The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
>>>> skins have a way to do this.
>>> This would fit great for my needs (and most developers I think)!
>> Will think about it. Actually, I'm not a big fan of this. It creates the
>> risk that someone feeds the output of this service into (incompatible)
>> timed RTDM services.
> 
> Sorry, I couldn't see a practical usage of this. Could you give an example?
> 
>> Even worse, this would work for aperiodic mode but fail for periodic.
> 
> Actually it is only necessary on periodic modes as it already works for 
> aperiodic mode.
> 
>> We would definitely need a good name for it,
>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
>> adding an argument (otherwise, I would have to fix too many drivers on
>> my own... :-/).
> 
> That is the idea, I think. I agree that rtdm_clock_read() should be kept as it 
> is (the API/definition). No body is asking you to change it. Adding 
> rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain 
> coherency with other skins.

Thinking about this more thoroughly, a few questions popped up for me:

o When we call it rtdm_clock_read_tsc(), we should actually return the
  raw TSC values, shouln't we? But then we also need conversion
  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
  convert to nanoseconds on return? POSIX and Native are different in
  this regard.

o What would be the core rationale behind it, having a high-resolution
  time stamp? What are the primary use cases? I'm asking for this so
  that I can clearly differentiate between this new service and the
  existing one in the docs. Also, giving an abstract description would
  leave more options to the actual implementation on other archs or
  platforms.

Jan


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