--- Jan Kiszka <[EMAIL PROTECTED]> escreveu:
> ...
> >> 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 understood that. What I've said is that I do not have enough knowledge about
SMP systems for
suggesting you a way of dealing with this kind of problem.
> > ...
> > 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.
That I understand. But I couldn't figure out which changes should be made to
documentation for
adding this function. Of course, as usual, the programmer will need to know
what (s)he is doing. A
single note explaining the situation in the rtdm_clock_read_tsc() function
would suffice in my
opinion. I do not think that adding this function would imply in any confusion
for developers.
> 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.
What do you mean by "corrected TSC-based timestamps"? How would be this
mechanism? Which
resolution would it give?
I think you are meaning that:
On RTDM load, there is an automatic calculation of the offsets between the TSC
of each CPU and the
Xenomai timer. Then, rtdm_clock_read() would change it behaviour to returning a
higher precision
time read, based on TSC and correcting them with the stored offsets. Is that
right?
Rodrigo.
_______________________________________________________
Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça.
http://br.messenger.yahoo.com/
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
