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


Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. 

Xenomai-core mailing list

Reply via email to