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.


Xenomai-core mailing list

Reply via email to