Rodrigo Rosenfeld Rosas wrote:
> I really tried to not answer this message and finish the "endless thread" you 
> mentioned, but I couldn't resist. ;) Maybe this will be the last post from my 
> own on this thread and will begin writing in the new thread. See below, 
> please.

I see no problem in continuing it. I guess most subscribers already
created special deletion filter for its keywords anyway. ;)

> ____________________________________________________________
> Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu:
>> ...
>> Ok, your framework is effectively aiming for relative times here, that's
>> clear now. But your driver will deliver individual frames with absolute
>> timestamp, right?
> Right.
>> Then it's up to the user to NOT mix up these 
>> timestamps with dates obtained from the system clock. You will have to
>> state this clearly!
> Sure, of course. No problem with that.
>> Moreover, when considering the TSC as high-resolution timestamp source,
>> this is not applicable on SMP / multicore systems. Those tend to have
>> unsynchronised and drifting TSCs. So if the first picture was taken on
>> one CPU and the second on some other...
> Unfortunately I can not arguee on that for now since I know almost nothing 
> about SMP systems. I'll take a look on the topic and hopely soon I'll return 
> you what I think about it.

Then let me continue my sentence:

... the timestamps can not be used to calculate the delay between both
of them. The reason is that you are lacking the offset between both TSC
sources at the respective timestamp acquisition dates.

>>> I'm not talking especifically about this application, but giving you a
>>> general idea of what is not possible to do currently with RTDM if the
>>> application set the timer to periodic.
>> And as I have this general view in mind, I want to avoid that the TSC
>> issue gets exported via RTDM drivers to the user. That's already
>> problematic for the other skins, but having to write special notes all
>> over the documentation of dozens of driver using mixed clocks would be
>> very unhandy.
> I don't understand why adding a new function like this would change a lot the 
> documentation. I really can not see your worries... If you could give me a 
> practical example, maybe it would be easier for me...

A driver that reports TSC timestamps instead of system clock timestamps
to the user has to state this fact and its potential effects in periodic
mode - as long as both clocks are out of sync. My idea is now to
synchronise them and report corrected TSC-based timestamps via
rtdm_clock_read() when in periodic mode. No need for new functions, use
the old one, and all your problems would be solved automatically.

>> I see the need for having a high-resolution timestamp aside a
>> low-overhead and low-resolution timer now, 
> good, got an ally. ;)
>> and I think we need to look 
>> for a way to avoid its negative sides.
> First I need to understand better what exactly are the negative sides...
>> Not sure yet if it will be 
>> feasible, but I will come up with a new thread on this topic soon...
> Yes, I've seen. I'll discuss next messages there.
> Thank you,
> Rodrigo.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to