1

I read two different definition for 'interrupt latency' in RTOS.

  1. "In computing, interrupt latency is the time that elapses from when an interrupt is generated to when the source of the interrupt is serviced" (source: https://en.wikipedia.org/wiki/Interrupt_latency )

  2. "The ability to guarantee a maximum latency between an external interrupt and the start of the interrupt handler." (source: What makes a kernel/OS real-time? )

Now, my question is what is the correct definition of 'interrupt latency'?

For example:

External Interrupt occurrence time stamp: 00 hr:00 min:20 seconds
Time stamp when execution is jumped inside the ISR: 00 hr:00 min :25 seconds
Time stamp when execution exits ISR after servicing: 00 hr:00 min :43 seconds

Now what is the interrupt latency time? Is it 5 seconds? or 23 seconds?

Community
  • 1
  • 1
RRON
  • 1,037
  • 3
  • 12
  • 32

1 Answers1

1

I think the first definition is correct, but you have misunderstood how interrupts work in practice and what it means by "serviced".

The control flow is three stage HW interrupt -> interrupt service routine -> process. The ISR usually is very short and merely clears the source of the interrupt and marks a process as ready to be run.

An example is you have a process that calls read to access data on disk. This process will block until the disk has performed the IO. Once the IO occurs the HW raises an interrupt to notify the CPU which goes in to the ISR, clears the interrupt and then sets the process that was blocked as able to be scheduled.

Why is this the interrupt latency that needs to be measured? Because this is where the actual processing required is doing the work. And if the interrupt needs a response with in a specified time (i.e. it is a real time system) then we need to know the time from an interrupt until we start processing that response. Which means we need to know the latency from the interrupt until our real time process gets scheduled.

Clifford
  • 88,407
  • 13
  • 85
  • 165
dave
  • 4,812
  • 4
  • 25
  • 38
  • Yes, you are right, I misunderstood the term 'serviced'. From your reply if I understand correctly, can I say "Interrupt latency is the time taken by kernel to clear the interrupt and unblock the blocked (on this interrupt) thread" ? – RRON Oct 08 '15 at 04:55
  • 4
    @Benvin : I would say not. The interrupt latency is only the time between the interrupt event and the start of the interrupt handler. The time taken to context switch to a task is *context switch time* and is determined by your RTOS implementation, and the time taken to execute the interrupt handler is within your control (i.e. you write the code - it is as fast and as deterministic as you make it). The time taken from interrupt to handler thread execution may well be important and need to be deterministic, but that is not *interrupt latency*. – Clifford Oct 20 '15 at 19:00