Em Segunda 13 Março 2006 08:48, você escreveu:
>> Do you mean that rtdm_clock_read will always read a multiple of tickval
>> value? If so, I think it would be good to make it clear on its
>> documentation. "Get system time" isn't enough for getting this
>> information, IMHO.
>Please have a look at the two sentences of documentation I added to SVN
>(didn't make it into the release).

I did.

>I gave your scenario a try, and I was able to verify that
>rtdm_task_busy_sleep works correctly under both timer modes.

I cannot understand yet why it doesn't occur here, but I'll investigate if I
have the time to.

>Indeed, the
>behaviour of rtdm_clock_read may have been confusing due to lacking
>information, but it was also correct.

I liked the note, but I would include another one:
"When in periodic mode, the time resolution is limited to the tick set to the
system timer" or something like. Maybe:
"[If using periodic mode, note that ]The time resolution is limited by the
system timer tick". Well my English is not that good, so I think you could
give a better description, but I really need this note is very useful.

>>> Using something different
>>> (e.g. always TSC) would break applications specifying absolute times
>>> derived from the return values of other skins' functions.
>> I did not understand. I'm talking about using TSC only for these two
>> functions. I can not see why shouldn't it be possible... I mean, I think
>> the driver should not depend on the userspace program timer for these two
>> functions.
>>>> But the worst case is that sometimes I get "Should be near 84000: 0"
>>>> which clearly is a incorrect result.
>>> That might be a rounding issue somewhere, as the sleep than clearly did
>>> not wait at least one tick. Will have to check this when time permits.
>>>> After I run the latency program, the timer turns to be oneshot again and
>>>> everything goes right.
>>>> What can I do to solve this problem?
>>> Use oneshot mode in the meantime - or even longer ;).
>> That is what I'll gonna do, but I know it is not a definite solution.
>> Since I'm providing a framework, the user should decide which approach is
>> better for him/her, oneshot or periodic mode.
>>> Why do you prefer
>>> periodic mode for your application? Another workaround: reduce the tick
>>> interval.
>> I have some loops in my userspace programs that a common 100us tick would
>> satisfy them all. I think the overhead would be lower than using the
>> aperiodic oneshot mode... I'm not pretty sure about that. But that is not
>> the question. My application is just an use case of my framework (actually
>> I didn't even started building it). The final user should decide what is
>> the best approach for him/her, not me. So, I would prefer that the driver
>> be independent from the timer source chosen by the user program.
>I see your point. But when the user decides to pick a low-precision
>timer source to reduce overhead, (s)he has to live with the side-effect.
>There is no such thing like "user vs. kernel" timer source - it is
>always the same. Thus, also the precision of time stamping in drivers

Ok, I'll document this on my framework.

Thanks for the support,


Yahoo! doce lar. Faça do Yahoo! sua homepage.

Xenomai-core mailing list

Reply via email to