Share this article:
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:
- 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.
- 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…
Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC317″ at checkout.
About the Author
You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here:
Computing functionality is ubiquitous. Today this logic is built into almost any machine you can think of, from home electronics and appliances to motor vehicles, and it governs the infrastructures we depend on daily — telecommunication, public utilities, transportation. Maintaining it all and driving it forward are professionals and researchers in computer science, across disciplines including:
- Computer Architecture and Computer Organization and Design
- Data Management, Big Data, Data Warehousing, Data Mining, and Business Intelligence (BI)
- Human Computer Interaction (HCI), User Experience (UX), User Interface (UI), Interaction Design and Usability
- Artificial intelligence (AI)