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. > > Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core