First of all, thanks for all your inputs, this is of great help!

I think I have misunderstood RTnet, so I'm now reading up on it now.

I thought RTnet had it's own mac-layer, such that a real time network is established but only between real time machines. But what I need is to sniff on a standard UDP/IP Ethernet network (tapping the Ethernet network). But I have to make precise/deterministic time stamping (using the clock of the NIC or the clock of the CPU - doesn't matter).

But you say that this is possible via RT net by the use of rtcap?

Again thanks for your suggestions and help!

I will look into the RTnet again and not forget the factor drifting.

- Benjamin

Gilles Chanteperdrix wrote:

Jan Kiszka wrote:

Gilles Chanteperdrix wrote:

As far as I remember, however, the timestamping of each packet is done
in the Linux domain, so, if you want to get the real timestamp, you have
to modify rtnet to get the timestamp done in the Xenomai domain.

No, time stamping is actually done in the RTnet driver (it is a
by-product of RTmac/TDMA).


Ok, right, bad memory.

Unfortunately, that is not all, because if you get Xenomai's timestamp,
they drift when compared to Linux timestamps. But if you look only at
relative timestamps over short period of times, that is Ok.

Yes, timestamps will drift compared to a precise reference clock or even
the Linux host clock. But I'm optimistic we can fix this in the neat future.


Ok. Now I remember why I touched this: in secondary domain, while
copying the packet for the rtcap driver, I read Xenomai's real-time
clock and Linux' real-time clock, and subtracted to Linux' timestamp the
difference between Xenomai's timestamp and the packet timestamp. This
compensates for the drift.

However, I far as I understood, Benjamin wants to get timestamps using
the NIC's clock. So, the solution would be a bit different.