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.

Don't bother with self-censorship, AFAIC, the issues you are triggering are important ones, since RTDM is a critical piece of the Xenomai framework, and allowing users to leverage it efficiently will help us all. However, please don't top post and trim the old messages a bit more from your replies: unfortunately, my brain has a limited FIFO. TIA,

____________________________________________________________
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.


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...


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.

        

        
                
_______________________________________________________ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html


_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core



--

Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to