Measurement of interrupt latency

The term “interrupt latency” is widely used, but, like a lot of technical terms, its meaning is sometimes unclear. This is our first challenge – to define our terms. The second challenge is to make a meaningful measurement.

Most RTOS vendors quote interrupt latency figures for their products. However, they may be referring to either one of two time intervals. In both cases, they are talking about the delay before an interrupt is serviced, but there are two ways to see this:

1. System interrupt latency – the interval between the assertion of the interrupt signal and the starting of the code to process that interrupt. This is represented by the long orange arrow in the diagram below.
2. OS interrupt latency – the time overhead added by the RTOS to the “normal” processing of an interrupt. This is represented by the short arrow.

Many vendors use definition #2 because it looks good. Some even quote “zero latency”, which sounds even better. However, this value is not really very useful. #1 has much more practical significance.

Figures quoted by RTOS vendors may be useful, once the terminology is figured out, but remember the figure is dependent on a number of factors which may not align with your system design:

• which platform and interrupt controller is being used?
• clock speed
• cache configuration
• timer frequency
• what kind of memory is the RTOS running out of?
• was the kernel built optimized for speed?

Clearly it might be more useful to make the measurement yourself.

To measure short time intervals in any electronic system, you need an instrument. And the best tool for this kind of job is an oscilloscope. One approach is to use one pin on a GPIO interface to generate the interrupt. This pin can be monitored on the ‘scope. At the start of the interrupt service routine, another pin, which is also being monitored, is toggled. The interval between the two signals may be easily read from the instrument.

I can imagine that a software engineer may be appalled by the thought of using an oscilloscope, but this might be an ideal opportunity to liaise with your hardware design counterpart. Actually, such liaison might be a good idea anyway …

This entry was posted on Tuesday, December 19th, 2017 at 3:35 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.