Daniele Nicolodi wrote: > On 19/05/10 07:49, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Just like it seems to be the case for Steve (unless I misunderstood his >>> reply), it is very useful for us being able to time-stamp events in RT >>> context that need to be correlated with events stamped in non-RT >>> (including non-Xenomai) parts or even on other systems: (offline) data >>> fusion, logging, tracing. I even bet that this is currently the major >>> use case for synchronized clocks, only a smaller part already has the >>> need to synchronize timed activities on a common clock source. But there >>> is huge potential in the second part once we can provide a stable >>> infrastructure. >> I already had such issues, and I did not solve them by modifying Xenomai >> core. > > I'm using Xenomai for scientific data acquisition, so I'm quite > interested to the issue. Can I ask you to detail how you solved the issue?
In my case, I was working on network equipments, and we needed timestamping of rtnet packets to be synchronized with linux clock, to compare/merge them with timestamps of network packets captured in the Linux domain. An rtnet packet is passed to the Linux domain not longer after it has been captured (and timestamped) in Xenomai domain. So, I just corrected the Xenomai timestamp using the difference between xenomai timebase and Linux timebase at the time when the packet was passed to Linux domain. It turned out to be quite precise, and if it is not precise enough, some statistical method could probably be used to evaluate the drift and compensate for it. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core