Interrupt Latency: Worst-Case Interrupt Response Time

What Is Interrupt Latency?

Definition and real-time impact

Interrupt latency is the elapsed time between the electrical assertion of an interrupt signal and the first instruction of the interrupt service routine (ISR) executing on the CPU. It is not a single number baked into a datasheet—it's a distribution shaped by hardware state, software architecture, and whatever else the processor happened to be doing at the moment the interrupt arrived. For a motor-control loop closing at 20 kHz, a sensor fusion task sampling an IMU at 1 kHz, or a safety interlock that must open a contactor within 500 µs of a fault, this number is the difference between a system that meets its deadline and one that doesn't.

Latency vs. jitter vs. throughput

These three terms get conflated constantly, and the confusion causes real design mistakes. Latency is the delay for a single event. Jitter is the variation in that delay across repeated events—a system with 2 µs latency but ±1.8 µs jitter is often worse for control-loop stability than one with 5 µs latency and ±0.1 µs jitter. Throughput is how many interrupts per second the system can service without dropping or queuing events; it matters for high-rate sources (ADC conversion-complete, Ethernet RX) but says nothing about how long any individual event waited. A system can have excellent throughput and terrible worst-case latency simultaneously.

Why worst-case matters in safety-critical systems

Average-case latency numbers are useless for certification and for deadline-driven control. A system that responds in 3 µs 99.9% of the time but occasionally spikes to 400 µs because of a disabled-interrupt critical section will fail intermittently in the field, usually under load, usually at the worst time. Safety-critical design cares about the maximum value, provably bounded, under the worst combination of circumstances the hardware and software can produce—not the typical value an oscilloscope shows on a quiet bench.

Components of Total Interrupt Response Time

Hardware interrupt detection and assertion delay

Before software ever runs, the signal has to propagate through input synchronizers, edge/level detection logic, and the interrupt controller's priority arbitration. On a typical Cortex-M NVIC this is a handful of clock cycles; on systems with external interrupt controllers, debounce logic, or shared interrupt lines (common in older PCIe or legacy GPIO expanders), this stage can dominate. Check the specific MCU's interrupt controller timing in its reference manual rather than assuming it's negligible.

Context save time (stack, registers, program counter)

The core must push enough state onto the stack (or a dedicated shadow register bank) to allow the interrupted code to resume correctly later. Architectures with automatic hardware stacking (Cortex-M's exception entry) do this in fixed cycles; architectures requiring compiler-generated prologue code to manually push registers add variable overhead depending on how many registers the ISR touches.

Vector fetch and dispatch overhead

The CPU must look up the ISR address from the vector table and load the program counter. Vectored interrupt controllers do this in hardware in parallel with context save; non-vectored designs require a software dispatcher that reads a status register, computes an offset, and jumps—adding tens of cycles per interrupt.

ISR prologue and epilogue (entry/exit code)

Compiler-generated or manually written prologue/epilogue code saves additional registers beyond what hardware stacks automatically, sets up any needed memory banking, and on exit restores state and executes the return-from-interrupt instruction. This is pure software overhead and one of the most controllable factors in total latency.

Software interrupt priority masking and scheduling delay

Even after the hardware signals the interrupt, it won't be serviced if a higher-priority interrupt is active or if the core is inside a region where interrupts are masked. This is where worst-case numbers diverge sharply from average-case numbers.

Sources of Latency in RTOS and Bare-Metal Systems

Interrupt masking and critical sections

Any code that disables interrupts—to protect a shared data structure, a ring buffer, or a peripheral register sequence—adds directly to worst-case latency for every interrupt that arrives during that window. The worst-case latency bound for a given interrupt is, at minimum, the longest critical section in the entire system that masks it, plus the handler time of every higher-priority interrupt that could also fire.

Task preemption point delays

In an RTOS, an ISR can usually preempt a task immediately, but the task-level response (the work queued from the ISR to a handler task) is gated by the scheduler's preemption model. Non-preemptible scheduling points, voluntary-yield kernels, or tick-based schedulers with coarse resolution all add delay between "ISR posted a semaphore" and "handler task actually runs." Systems built on AUTOSAR OS distinguish this explicitly: a Category 1 ISR runs with minimal kernel involvement and the lowest latency, while a Category 2 ISR goes through the OS and incurs context-save and scheduling overhead—an architectural choice with direct latency consequences that should be made deliberately per interrupt source.

Cache and memory pipeline effects

A cache miss on the vector fetch, the ISR's first instructions, or stack memory can add dozens to hundreds of cycles unpredictably. Pipeline flushes on branch mispredicts during exception entry have a similar effect. These are major contributors to jitter even when average latency looks fine.

Atomic operations and lock contention

On multicore parts, interrupts contending for spinlocks or atomic read-modify-write instructions (LDREX/STREX-style exclusive access) can stall waiting for another core to release a bus lock, adding non-deterministic delay that single-core timing analysis won't catch.

RTOS scheduler overhead during context switch

If the ISR triggers a context switch (e.g., it unblocks a higher-priority task), the full scheduler path—ready-queue manipulation, stack switch, possibly a tick update—runs before that task's code executes. This cost varies by RTOS and must be measured, not assumed.

Measurement and Analysis Techniques

Hardware timestamp methods (GPIO toggle, debug ports)

The simplest reliable method: toggle a spare GPIO pin at interrupt entry and capture the external trigger-to-toggle time on a scope. Pair it with a toggle at ISR exit to measure handler duration separately from entry latency. Debug trace ports (ARM ETM/ITM, similar vendor equivalents) give cycle-accurate timestamps without consuming a pin, at the cost of needing a trace-capable debug probe.

Static worst-case execution time (WCET) analysis

Static WCET tools analyze the compiled binary's control flow graph, accounting for pipeline and cache effects, to produce a provable upper bound without running the code. This is the only approach that gives a certifiable worst case rather than an observed one, and it's required reading for any DO-178C or ISO 26262 timing argument.

Model-based timing verification

Formal scheduling models (rate-monotonic analysis, response-time analysis) compute worst-case task and interrupt response times from a model of priorities, periods, and execution times, letting you verify schedulability before hardware exists.

Oscilloscope and logic analyzer capture

For validating against the real hardware, a logic analyzer correlating the interrupt source signal with the GPIO-toggle method above, over millions of trigger events, is the practical way to catch the rare worst-case spike that static analysis might miss due to modeling assumptions.

Simulation and profiling tools

Instruction-set simulators and cycle-accurate profilers let you inject interrupts at arbitrary points in code execution—including inside critical sections—to find worst-case combinations that are hard to reproduce on real hardware.

Bounding and Predicting Worst-Case Latency

Blocking time analysis for nested interrupts

With nested, prioritized interrupts, the worst-case latency for a given priority level is the sum of: the longest lower-priority critical section that masks it, plus the total execution time of every higher-priority interrupt that could fire first, plus one instance of hardware/context overhead. This is why a system with many high-priority interrupt sources can produce surprisingly large worst-case bounds on its lowest-priority interrupt, even though each individual handler is short.

Interrupt priority assignment strategies

Assign priorities by deadline tightness, not by perceived importance. A rate-monotonic-style assignment—tightest deadline gets highest priority—gives a mathematically analyzable bound; ad hoc assignment does not.

RTOS conformance class impact on latency bounds

Conformance classes (as defined in AUTOSAR OS and similar standards) constrain which OS services are available from which interrupt category, which in turn bounds what overhead the kernel can impose. Choosing a lower conformance class trades flexibility for a tighter, better-documented worst-case latency bound.

Frequency and voltage scaling effects

Dynamic frequency/voltage scaling, common in power-sensitive designs, changes cycle time and therefore absolute latency. Worst-case analysis must use the lowest clock frequency the system can be running at when the interrupt occurs, including any clock-switch transition delay itself.

Safety margin and design headroom

A measured or computed worst case should never be treated as the design target. Standard practice is to budget to 50–70% of the deadline for worst-case latency, leaving headroom for silicon variation, temperature effects, and future code growth.

Practical Optimization Strategies

Minimizing ISR prologue and critical-section duration

Keep ISRs short, avoid unnecessary register saves (let the compiler know which registers are actually used), and shrink every interrupt-masked critical section to the minimum instruction count possible.

Deferred work patterns (bottom-half handlers)

Split the ISR into a minimal top half that acknowledges the hardware and captures data, and a deferred bottom half (task, workqueue, or software interrupt) that does the heavier processing outside the interrupt-masked context. This directly bounds the worst-case masking time contributed by that source.

Interrupt coalescing for high-frequency events

For high-rate sources like network RX or ADC streaming, batch multiple events into one interrupt (via hardware FIFO thresholds or timer-based coalescing) to trade a small amount of added per-event latency for a large reduction in total interrupt load—improving throughput and, often, worst-case latency for other interrupts.

CPU affinity and cache-aware interrupt routing

On multicore SoCs, pin latency-sensitive interrupts to a dedicated core and keep that core's cache warm by avoiding unrelated workloads on it, reducing the cache-miss jitter described earlier.

Hardware acceleration and DMA for offload

Move data movement out of the ISR entirely using DMA, and let the ISR only handle completion/error conditions. This shrinks handler execution time, which is one of the direct inputs to the blocking-time formula above.

Real-Time System Design Considerations

Deadline miss and system stability consequences

A missed deadline isn't always a crash—in a control loop it can mean an undamped oscillation, an overshoot that trips a mechanical limit, or a sensor sample used one cycle late, silently degrading accuracy until a fault threshold trips at an inconvenient moment.

Safety standards (ISO 26262, IEC 61508) latency requirements

Neither standard specifies a universal latency number; both require that the system's timing behavior be analyzed, bounded, and tested against the hazard analysis for the specific function. In practice this means documenting the worst-case latency derivation (static WCET plus blocking analysis) as part of the safety case, not just citing a measured oscilloscope trace.

Trade-offs between latency and throughput

Techniques that improve throughput—coalescing, batching, deeper FIFOs—generally increase per-event latency. Techniques that minimize worst-case latency for a critical interrupt—high priority, short critical sections elsewhere—can reduce overall system throughput by starving other work. These trade-offs should be made explicitly per interrupt source, not globally.

Testing and validation in production

Latency bounds derived at design time should be re-validated against production hardware and the final compiled binary, since compiler optimization settings, linker placement, and silicon revisions all shift the numbers. Scheduling this validation work alongside normal development—whether the team runs Scrum sprints or Kanban flow—keeps timing regression from being discovered only after field deployment.

Related reading

• NVIC: Priority Grouping, Preemption, Sub-Priority — interrupt priority and preemption.