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