Reading 'Life With Adeos' casts some light over the whole interrupt question. However I have some further questions.

Why is it that the 'host interrupts' that you (Jan) mention below, can stall and cause jitter in the xenomai threads, when the host interrupts have not been given xenomai domain priorities? If such a host interrupt is played, Life With Adeos makes it sound that this interrupt is preemptable, given an interrupt with higher priority occurs.

Is it true that when RTcap is enabled, then every incoming frame will play an interrupt of highest possible priority (real time nucleus), as to timestamp the incoming frame?

Is it true, that when a TDMA synchronization frame arrives, this will also play an interrupt of highest possible priority (real time nucleus), as to calculate the offset between local and global clock?

Thanks for any hints to the above,

Benjamin


Jan Kiszka wrote: 
Jan Kiszka wrote:
  
Benjamin Biegel wrote:
    
Thanks Jan

We use this setup: Two computers are RTnet-slaves synchronized to provide them common time. These two computers also have a second NIC which tap a target Ethernet network using RTcap. In this way we can measure Ethernet travel times on the target network.

This works well. The only problem is that we don't know exactly how to handle if a TDMA sync arrives at the same time as RTcap captures a frame on the target network.

We ran a test where we only read the system time from kernel space using rt_timer_read(). This reading and saving to a file takes approximately 1 us. However this time increases to approx 16 us when the reading is made when a synchronization TDMA packet is being handled.

We would like to detect when this happens so we can discard the frame travel times that collide with the TDMA sync.

I hope this makes sense
      
Note that the synchronization accuracy via TDMA is not in the order of a
few microseconds, rather a few 10 us. That's because no clever approach
to compensate jitters of the reception interrupt is applied. So your
worrying about the jitter caused by the second NIC actually has to be
extended by worries about jitter of other host interrupts. They might be
smaller as I-pipe will suppress non-RT IRQs far more quickly, but they
are more and can line up and cause larger jitters as well.

If you want to get rid of most of them: use a multicore box and isolate
the RTnet NIC IRQ on a dedicated core. All Linux IRQs except for the
timer IRQ can then be avoided.
    

Well, there are actually more unavoidable Linux IRQs: You may still see
occasional rescheduling IRQs, and some other IPIs may be unavoidable
with current Linux as well. So no perfect world here, but at least some
sources of IRQ jitters can be avoided.

Jan