Quantifying the Latency and Possible Throughput of External Interrupts on Cyber-Physical Systems

Quantifying the Latency and Possible Throughput of

External Interrupts on Cyber-Physical Systems

O. Horst]Oliver Horst
J. Wiesböck]Johannes Wiesböck

fortiss GmbHResearch Institute of the Free State of Bavaria
Guerickestr. 25

horst<EMAIL_ADDRESS>
R. Wild]Raphael Wild
U. Baumgarten]Uwe Baumgarten

Technical University of Munich
Department of Informatics
Boltzmannstr. 3

raphael.wild<EMAIL_ADDRESS>
An important characteristic of cps is their capability to respond, in-time, to events from their physical environment. However, to the best of our knowledge there exists no benchmark for assessing and comparing the interrupt handling performance of different software stacks. Hence, we present a flexible evaluation method for measuring the interrupt latency and throughput on ARMv8-A based platforms. We define and validate seven test-cases that stress individual parts of the overall process and combine them to three benchmark functions that provoke the minimal and maximal interrupt latency, and maximal interrupt throughput.

§ DATA AVAILABILITY STATEMENT

A snapshot of the exact version of the prototyping platform toki <cit.> that was used to conduct the presented measurements is available on Zenodo <cit.>. The snapshot also contains the captured, raw STM trace data and scripts to produce the presented figures. The latest version of toki can be obtained from <cit.>.

§ INTRODUCTION

cps are characterized by the fact that a computer system works together with a physical environment, or rather controls it. A specific characteristic of such control systems is their necessity to provide short and predictable reaction times on events in the physical world, to guarantee a good control quality <cit.>. Both properties are likewise essential for modern systems, such as tele-operated-driving <cit.>, and classic systems, such as the control of internal combustion engines <cit.>.

An important aspect of the achievable reaction time is the interrupt handling performance in both dimensions the interrupt handling latency and throughput capabilities of a system. Especially the effect of the utilized software stack has not yet been comprehensively assessed. Such a systematic evaluation would, however, facilitate the development and selection of cps software stacks for particularly latency-sensitive or throughput-hungry use-cases.

Previous studies in this field mainly conducted measurements with the help of external measurement devices <cit.>, which requires an in-depth understanding of the hardware to obtain precise measurements <cit.>. This expert knowledge, however, is reserved for the soc and processor ip vendors. Hence, we see the need for a measurement method that allows to accurately measure and properly stress the interrupt handling process of today's soc without expert knowledge. Accordingly, we present a flexible interrupt performance measurement method that can be applied to ARMv8-A ip-core based platforms that provide a physical trace-port. As we see an increasing market share of ARM based systems <cit.> and their wide adoption in automotive cps <cit.> we strongly believe that our method helps in analyzing a multitude of relevant systems.

We specify three benchmark functions based on the assessment of ten combinations out of seven distinctive test-cases. Whereby each test case was chosen to stress a dedicated part of the ARM interrupt handling process. The effectiveness of the test-cases and benchmark functions is demonstrated on a Xilinx ZCU102 evaluation board <cit.> with two different software stacks.

In summary, we contribute

itemjoin=, ,
itemjoin*=, and ,

* a precise method to measure the interrupt performance of complex ARM based soc without expert knowledge

* a set of benchmark functions that provokes the best and worst interrupt latency and maximal throughput on a given ARMv8-A hardware and software combination

The rest of this is structured as follows: <Ref> describes the interrupt handling process on ARMv8-A platforms with a gic version 2, <ref>
presents the measurement setup and procedure of the envisioned evaluation method, <ref> discusses the proposed test-cases and benchmarks along with the measurement results, <ref> gives an overview on related work, and <ref> concludes the .

§ INTERRUPT HANDLING PROCEDURE ON ARMV8-A PLATFORMS

<cit.> define an interrupt as an event that causes a change in the execution flow of a program sequence other than a branch instruction. Its handling process starts with the activation through a stimulus and ends with the completion of the isr, which is called in consequence and processes the stimulus. Until the isr is executed several steps are undergone in hardware to cope for example with simultaneously arriving irq and masking of certain requests. In the following, we explain this process for ARMv8-A platforms, as specified in the gic architecture specification version 2 <cit.>. In <ref> this information is used to design suitable test cases.

The gic architecture specification differentiates among four types of interrupts:

itemjoin=, ,
itemjoin*=, and ,
after= interrupts.

* peripheral

* software-generated

* virtual

* maintenance

In the course of this we focus solely on measuring interrupts triggered by external stimuli, the peripheral interrupts. They can be configured as edge-triggered or level-sensitive. This means that the corresponding interrupt is recognized either once on a rising edge in the input event signal, or continuously as long as the signal has a certain strength.

The gic supervises the overall interrupt routing and management process up to the point that the isr is called. <Ref> shows the gic architecture and the signaling path for the selected measurement hardware, the zynqmp. The gic manages all incoming event signals of the system and consists out of a central Distributor and a CPU interface per processor core. The Distributor manages the trigger-type of each interrupt, organizes their prioritization, and forwards requests to the responsible CPU interface. The CPU interfaces perform the priority masking and preemption handling for their associated core.

Repeatedly, per CPU interface executed selection and signaling process of the gic for handling triggered irq.

The timeline of the various steps in the interrupt handling process are illustrated in <ref>. The handling process of a certain irq begins with the arrival of an event signal at the Distributor (step 1). In case the signal matches the configured trigger type, the actual handling process is triggered through the recognition of a new irq (step 2), which eventually leads to the execution of the isr (step 9).

After being recognized (step 2), the Distributor may select and forward the irq to the responsible CPU interface according to the process depicted in the upper half of <ref>. This selection process (step 3) is executed repeatedly and potentially in parallel for each CPU interface. When the next hppi is identified the Distributor forwards the request to the currently inspected CPU interface (step 4). The CPU interface filters incoming requests according its configuration and the process shown in the lower half of <ref>. As a result the CPU interface may signal a pending irq to its associated core (step 5).

Overall steps of the interrupt handling process on ARMv8 platforms with a gic version 2 and an ARMv8-A architecture profile core.

Subsequent to the signaling of a new irq, on an ARMv8-A architecture <cit.>, the core acknowledges the signaled irq by reading its id (step 6), which marks the irq as active within the gic (step 7). Meanwhile, the processing core jumps to the vector table entry indicated by the id of the current irq (step 8), which leads to the execution of the isr (step 9). Individual software stacks might add additional steps before the isr finally starts.

Besides the regular interrupt requests described above, the gic architecture version 2 (gicv2) also supports the prioritized and more secure fiq, however, these lay out of the focus of this . Furthermore, it shall be noted that the regular interrupt processing path was not affected by the latest updates to the gic architecture (version 3 and 4). Hence, we strongly believe that the presented benchmark functions would be still valid for the updated architectures.

§ PROPOSED EVALUATION METHOD

With respect to the interrupt performance of a hardwaresoftware combination two properties are most relevant: the irq latency and throughput. Considering the process shown in <ref>, we define the irq latency as the time between a signaled event (step 1) and the call to the corresponding isr (step 9). As throughput we understand the number of completed isr per time unit.

§.§ Measurement Setup

Chosen measurement setup, with four PL2PS interrupts generated by the pl according to the configuration signaled by the ps via its emio. The generated interrupts, executed instructions, and global timestamps are recorded through the stm and etm. The captured trace is read via an ARM DSTREAM unit.

Our measurements utilize a Xilinx ZCU102 <cit.>, with the toki prototyping platform <cit.>, and an ARM DSTREAM <cit.> hardware trace. We have chosen the zynqmp, as it features an in-built pl and versatile tracing capabilities. <Ref> illustrates the chosen hardware setup. The zynqmp is divided into the pl and ps. The ps provides two processor clusters, the apu with four ARM Cortex-A53 cores and the rpu with two ARM Cortex-R5 cores. Both clusters have their own interrupt handling infrastructure, but we focus on the apu's only.

The ARM CoreSight <cit.> tracing capabilities of the zynqmp allow to record events, such as taken branches, external interrupts, and software events on a common timeline defined by system-wide timestamps. The stm and etm record the various events in hardware, without altering the behavior of the executed code, neither in a temporal nor semantic sense. Only software driven events require a register write operation and thus marginally influence the timing of the executed code. CoreSight is part of all newer ARM processor ip and can be utilized as soon as the used hardware features a physical JTAG- and trace-port. The latter is typically available on evaluation boards used for prototyping professional applications.

In addition to the in-built hardware features, we deploy a custom interrupt generation block into the pl. The block allows to simultaneously stimulate apu interrupts, following a generation pattern defined by a logical-high and -low phase, and trace them in the stm. This could also be realized with an external fpga or a signal generator, to support additional platforms. The pin multiplexing configuration of the target platform only has to ensure that triggered input lines are also connected to a stm hardware event channel.

§.§ Measurement Procedure

Based on the measurement setup, we propose two measurement procedures, one per measurement type (latency and throughput), utilizing two different configurations of the interrupt generation block. Both procedures use apu core 0 to take measurements and the other cores as stimulation sources, where needed.

We conduct our measurements on two software stacks: (i) a bare-metal, and (ii) a FreeRTOS based system. Both software stacks are provided by the toki build- and test-platform <cit.>, and utilize a driver library provided by Xilinx <cit.>. This library already features an interrupt dispatching routine
that multiplexes the processor exception associated with regular interrupts on the target.

The bare-metal stack is an unoptimized piece of code that features neither a scheduler, nor a timer tick. It could clearly be optimized, however, it is unclear how much a fully optimized assembler version of the stack would impact the presented results.

Thanks to its Yocto <cit.> based build-system, toki can easily be executed to include Linux based software stacks and with that the presented test setup. Completely different software stacks and hardware platforms can be evaluated with the given setup, when they provide (i) a libc function interface, and (ii) drivers for interacting with the caches, stm trace, and gic on that platform.

§.§.§ Throughput

In case of a throughput evaluation, we configure the interrupt generation block to continuously signal the PL2PS interrupts for 9.75 and then wait for another 250 on a rotating basis. We call each repetition of this pattern a stimulation phase. Core 0 is configured to handle the signaled ppi on a level-sensitive basis and the corresponding isr does nothing despite emitting a stm software event, executing a 8 store instruction. Hence, the time spent in each isr and with that the possible reduction of the maximum throughput is negligible.

For each throughput measurement we capture a 120 trace and evaluate the contained stimulation phases. The throughput ($\mu$) in each stimulation phase ($i \in [0,19]$) is obtained from the traced measurement samples by counting the isr generated stm-software-events between the rising-edge stm-hardware-event of the ($i$)th and ($i$+$1$)th stimulation phase and dividing it with the length of one logical-high-phase. The set of throughput values considered for the evaluation in <ref> is then given by $M = \{\, \mu(i) \;|\; i \in [0, 19] \,\}$.

§.§.§ Latency

The latency evaluation is conducted with an alternating scheme of a 1 PL2PS interrupt trigger and a 4 pause. The interrupt generation block is configured accordingly. Again we refer to each repetition of this scheme as a stimulation phase. In contrary to the throughput measurement, however, core 0 is configured to handle the signaled ppi on a rising-edge basis. Thus, every stimulation phase provokes only one interrupt. The corresponding isr is the same as for the throughput measurements.

The results for the latency measurements are obtained by evaluating 30 trace captures. The interrupt latency $\Delta t_\mathsf{latency}(i)$ induced by each stimulation phase $i \in [0, 2399]$ is given by $\Delta t_\mathsf{latency} = B - A$, with $A$ representing the point in time where the interrupt was stimulated and $B$ the point where the corresponding isr was started. Both points can be obtained from the captured trace. $A$ is given by the timestamp of the stm hardware event associated with the rising-edge of the PL2PS interrupt signal. $B$, on the other hand, has to be determined and defined for every analyzed software stack individually. In the course of this we utilize  the timestamp of a stm event generated within the interrupt handler of our benchmark application  that runs on top of the evaluated software stacks.

Similar to the throughput values, the set of latency values considered in <ref> is given by $X = \{\, \Delta t_\mathsf{latency}(i) \;|\; i \in [0, 2399] \,\}$.

§.§ Precision and Limitations

In our measurement setup, we configure the pl, trace port, and timestamp generation clock to oscillate at 250. Hence, two consecutive timestamp ticks lay 4 apart from each other. Since each sampled event in the etm and stm is assigned a timestamp, our measurement precision corresponds exactly to the system timestamp resolution, 4. This is an order of magnitude smaller than the interrupt latency measured in a previous study for the same hardware platform  <cit.> and a quarter of the measured minimal interrupt latency of an ARM real-time core <cit.>.

Even though state of the art oscilloscopes provide a sampling rate of up to [per-mode=symbol]20 <cit.>, which corresponds to a measuring precision of 0.05, the actual precision in case of interrupt latency measurements might be considerably lower. The reason for this is that the oscilloscope can only measure external signals of a processor. Thus, in-depth knowledge of the internal structure of the hardware and executed instructions during a measurement is required to utilize the full precision of the oscilloscope. This makes it less suited for the evaluation of different hardware platforms and software stacks. The CoreSight based measurement setup, on the other hand, supports a flexible placement of the measurement points within and outside of the processor and does not require any expert knowledge about the hardware or software.

Besides the measurement precision and flexibility, we also need to ensure that the presented measurement setup is sane and triggered interrupts can actually be recognized by the processor. According to the zynqmp technical reference manual <cit.>, a signal pulse that shall trigger a PL2PS interrupt needs to be at least 40 wide to guarantee that it is recognized as such. Hence, the presented stimulation scenarios for the two measurement procedures ensure that all triggered interrupts can be recognized.

The disadvantage of the presented measurement approach, however, is that it is only applicable for ARM based platforms with a dedicated JTAG- and trace-port. Given ARM's 40% share of the semiconductor market for ip designs <cit.> and the wide availability of suitable evaluation boards, we believe this is an acceptable drawback. An additional limitation is that valid measurements can only be obtained for the interrupt with the highest priority among the active ones, but this applies to any kind of measurement setup.

§ CONSTRUCTING A BENCHMARK

Properties of the evaluated test-cases and benchmarks used to compare the interrupt latency (L) and throughput (T).

to |X[1.9,l]|X[.8,c]|X[.4,c]|X[.4,c]|X[.8,c]|X[.8,c]|X[.8,c]|>X[.26,c]|>X[.26,c]|>X[.26,c]|

2=Targeted Component
2=Enabled Interrupts
2=Cache Config
2=Enabled Cores

L     T
Lmin     Lmax

T1: Baseline
X     X
1     Disabled     1

T2: Caches enabled
X     X
1     Enabled     1
X         X

T3: Caches invalidated
1     Invalidated     1

T4: Enabled interrupts
2–181     Disabled     2

T5: Order of priorities
15     Disabled     2

T6: Parallel interrupt handling
X     X
1     Disabled     2, 3, 4
X     X

T7: Random memory accesses
1     Disabled     4

Latency measured with T1–T7 (sfig:results:latency-overview) and B-Lmin and B-Lmax (sfig:results:latency-b_min-sfig:results:latency-b_max). sfig:results:latency-overview uses a symlog scale with a linear threshold of 2496, sfig:results:latency-b_min uses a symlog scale with a linear threshold of 240, and sfig:results:latency-b_max uses a linear scale.

Throughput measured with T1, T2, T6, and B-Tmax. sfig:results:throughput-overview compares the median of all measurements on a linear scale and sfig:results:throughput-details illustrates the measured throughput ranges on a symlog scale with a linear threshold of 1, normalized to a 500 range around the highlighted median.

In order to create a benchmark for comparing the interrupt latency and throughput across platforms and software stacks, we have designed seven test-cases specifically tailored to stress the ARMv8-A interrupt handling process. To judge their suitability for an overall benchmark, we measure their performance with the two software stacks described in <ref> on top of the zynqmp discussed in <ref>. By comparing the impact of each test-case with respect to the baseline performance of the two systems, we compose three benchmarks out of the test-cases and show their suitability by applying them to the same system configurations.

§.§ Evaluated Test-Cases

Given the interrupt handling process in <ref>, we conclude that the time spent in the process can be influenced by: the core, caches, memory, and gic. We have designed seven test-cases that aim to reveal the influence of different configuration settings related to the aforementioned components onto the temporal behavior of the interrupt handling process. However, we do exclude the core from our considerations by only measuring interrupts with the highest priority and not computationally loading the measured core. The measurements for all test-cases follow the scheme presented in <ref>, unless indicated otherwise. Depending on the goal of each test-case they are either applied only for latency measurements or both latency and throughput measurements. The proposed test-cases and their targeted components are summarized in <ref>, and <ref> present the results of our measurements. The presented results are based on 848–6000 measurement samples per latency measurement and 11–12 samples per throughput measurement. The remainder of this section elaborates on the intended influence of the listed test-cases on the interrupt handling process.

§.§.§ T1: Baseline

T1 is intended to provide a reference point to compare the other test-cases to and rate their impact. Hence, T1 assess the interrupt latency and throughput of a system in the most isolated way, with only one core and interrupt enabled and caches disabled. Hence, T1 only enables the emio pin driven interrupt and routes it to core 0. As isr the default handler, described in <ref>, is used. T1 is evaluated for its latency and throughput performance.

§.§.§ T2: Caches enabled

T2 equals T1, with the exception that all operations are executed with enabled caches. This test is conducted for both latency and throughput measurements.

§.§.§ T3: Caches invalidated

T3 is also based on T1, but the isr additionally invalidates the data and instruction caches. Due to the fact that this is not feasible in throughput measurements, as new interrupts would arrive independently of the cache invalidation process, we conduct only latency measurements with T3.

§.§.§ T4: Enabled interrupts

T4 aims at stressing the gic with the highest possible number of enabled interrupts, as the interrupt selection and signaling process suggests that more checks have to be done the more interrupts are enabledpending. Hence, T4 enables the maximum number of interrupts supported by the zynqmp, except those required for conducting the measurements. All interrupts are routed to and handled by core 0. The measured PL-to-PS interrupt is assigned to the highest priority and all other interrupts to the lowest priority. Core 0 installs an empty isr that immediately returns after clearing the irq in the gic for all interrupts, except the measured PL-to-PS interrupt, which uses the same isr as T1.

As this test aims at stressing the gic to reduce its performance, we only evaluate it with respect to the interrupt latency. To be able to identify trends, we evaluated this test-case with 1, 36, 72, 108, 144, and 180 stressing interrupts. However, due to the marginal differences between the results of the different T4 variants and space constraints we only show the results of T4-180, T4 with 180 stressing interrupts, which provoked the highest latency.

§.§.§ T5: Order of priorities

T5 utilizes the same setup as T4 and is also applied to latency measurements only. However, in contrast to T4, T5 only utilizes as much interrupts as there are priorities, 15. The measured interrupt remains at priority 0 and the priorities of the other 14 are assigned in an ascending order (14 to 1). This design intends to provoke a maximal number of hppi updates.

§.§.§ T6: Parallel interrupt handling

To test the influence of parallelly handled interrupts on the interrupt handling process, T6 enables up to 4 cores and configures all of them to handle the emio pin 0 interrupt. The interrupt is configured as level-sensitive with the highest priority. The pl ensures that this interrupt is signaled continuously and simultaneously as soon as the test is enabled. The isr on all cores generate a stm event, which are evaluated for throughput measurements. In case of latency measurements, however, only those stm events produced by core 0 are considered.

We evaluated T6 with 2, 3, and 4 enabled cores. The results showed a clear trend that the more enabled cores the higher the observed latency and the lower the achieved throughput. Due to space constraints we thus only show the results for T6-4, with 4 enabled cores, in case of the latency considerations and T6-2 in case of the throughput measurements.

§.§.§ T7: Random memory accesses

As pointed out earlier, the shared memory and interconnecting buses of multi-core processors represent a major source of unforeseen delays. Accordingly, T7 is designed to delay memory accesses by overloading the interconnecting bus and memory interface. For this purpose all 4 cores are running random, concurrent memory accesses in form of constants that are written to random locations in a 96 large array. In parallel core 0 executes the standard latency test. Throughput evaluations are not considered with this test-case, as it targets to delay the interrupt handling process.

§.§ Proposed Benchmarks

Analyzing the measured interrupt performances under the different test-cases, shown in <ref>, we conclude that first of all different setups and software stacks indeed considerably influence the interrupt handling performance. All three targeted components, provoke a considerable effect on the interrupt latency and throughput. Particularly noticeable are the differences between the test-cases with enabled (T2, T3) and disabled caches (T1, T4–T7), for both the observed latency and throughput, as well as the effects of stressing the gic on the measured latency (T4–T6).

Of special interest is that the FreeRTOS based stack achieved a smaller minimum latency and a narrower variation range of the latency and throughput, compared to the bare-metal stack. Examples are for instance T2 and T6-4 for latency measurements, and T6-2 for throughput measurements. After measuring and reviewing the tests for each critical test-case multiple times without finding any anomalies, we assume that some low-level hardware effects, for instance in the pipeline or shared interconnects, might cause the observed behavior. Further insight into the situation could be gained by (i) implementing a fully optimized, assembly-only bare-metal stack, or (ii) analyzing the actual hardware effects with a cycle-accurate simulation in ARM's Cycle Model Studio <cit.>. However, both approaches are out of the scope of this .

T2 produces by far the shortest interrupt latency of 232 on average with only a few outliers. Hence, we propose to utilize T2 as benchmark for the minimal achievable latency (B-Lmin).

To obtain a suitable benchmark for the maximal latency, we analyzed all combination out of the test-cases T4-36, T4-144, T6-3, and T7. Except for the combination out of T6 and T7, all tested combinations showed a similar performance with only slight differences. An exception to that forms the interrupt latency performance of the combination out of T4-144 and T6 on FreeRTOS, which is considerably more confined than all other observed ranges. The highest latency is achieved with a combination out of T4-36 and T6, however, the combination of T4-36, T6, and T7 is close. Accordingly, we propose to use the combination out of T4-36 and T6 to benchmark the achievable maximal interrupt latency (B-Lmax).

For the maximal throughput benchmark (B-Tmax) we evaluated all four variants of the T6 test-case with enabled caches (T2). Interestingly, the enabled caches seem to mitigate the effect of more enabled cores, as all combinations showed a similar throughput. However, the combination out of T6-2 and T2 still performed best. Even though the maximal achieved throughput of the combined test-cases lags a little behind that of T2 alone in case of the bare-metal software stack, it outperforms T2 by far in case of the FreeRTOS based stack. Hence, we propose the combination out of T6-2 and T2 to benchmark the maximal throughput of a system.

§ RELATED WORK

In principle, there exist two patented interrupt latency measurement approaches that are used in literature. First, measurements based on an external measurement device, such as an oscilloscope <cit.>. And second, measurements based on storing timestamps when an interrupt is asserted and when the interrupt handling routine is completed <cit.>, like we do with our measurements.

measured the interrupt latency of five Linux variations on an Intel PXA270 processor, which features an ARM instruction set. They used a counter based measurement method and focused on the effect of different computational loads. Since their stimulation is limited to a single periodic interrupt, we argue that their approach is not able to stress the interrupt distribution process and that they rather analyzed the responsiveness of the scheduler to aperiodic events than the deviation of the interrupt latency.

The wide majority of studies, however, focused on interrupt performance measurements with external measurement devices <cit.>, or combined it with the timestamp approach <cit.>.  compared different 80×86 processors with each other and <cit.> determined an exact latency for their i.MX RT1050 processor. All other aforementioned studies focused on comparing different software stacks with respect to various computational loads. None of the mentioned studies analyzed the throughput, or stressed the interrupt distribution process.

<cit.> claim to have measured the event latency of LITMUSRT a KVM/Qemu virtualized environment on an Intel based computer. However, it stays unclear how they performed the measurements and where they got the timing information from.

Previous studies of the achievable interrupt throughput focused on the analysis of the achievable network packet transmissionreception or storage inputoutput operations per second when considering different interrupt coalescing and balancing strategies <cit.>, but do not analyze the interrupt throughput in isolation with respect to different software stacks.

§ CONCLUSION AND OUTLOOK

We presented a flexible evaluation method based on the ARM CoreSight technology <cit.>, which enables the assessment of various software stacks on top of commodity ARMv8-A platforms with respect to their interrupt handling performance. Utilizing the evaluation method, we crafted seven specifically tailored test-cases that were shown to stress the ARM interrupt handling process. Out of these test-cases we deduced three benchmark functions, tailored to provoke the minimal (B-Lmin) and maximal (B-Lmax) interrupt latency, and the maximal throughput (B-Tmax), of a given software stack. We validated the test-cases and benchmark functions by comparing two software stacks (a simple bare-metal and FreeRTOS based environment) and measuring them on top of a Xilinx ZCU102 <cit.>.

Our measurements showed that different software stacks do have a considerable impact on the interrupt handling performance of a hardware platform. Hence, we hope to draw some attention on the importance of a good software design for cps, with respect to interrupt processing and the need of a more profound analysis on how interrupt handling processes can be made more predictable with respect to the achievable latency and throughput.

The presented results build on top of the Bachelor's thesis by <cit.> and were partially funded by the BMWiGerman Federal Ministry of Economics and Technology (BMWi)https://www.bmwi.de under grant n°BMWi01MD16002C and the EUEuropean Union (EU)https://europa.eu/ under RIA grant n°825050.

#1     #1#1#1     #1     #1     #1     #1#1          #1#1

[Ahmad, Gulati, and MashtizadehAhmad
et al2011]
authorpersonIrfan Ahmad, personAjay Gulati,
and personAli Mashtizadeh. year2011.
vIC: Interrupt Coalescing for Virtual Machine
Storage Device IO. In booktitleUSENIX Annual Technical
Conference (ATC).

[Aichouch, Prevotet, and NouvelAichouch
et al2013]
authorpersonMehdi Aichouch,
personJean-Christophe Prevotet, and personFabienne
Nouvel. year2013.
Evaluation of the overheads and latencies of a
virtualized RTOS. In booktitleProceedings of the 8th
IEEE International Symposium on Industrial Embedded Systems (SIES).

[ARM Ltd.ARM Ltd.2013a]
authorpersonARM Ltd.
titleARM Generic Interrupt Controller – Archichtecture
ver. 2.0.
(IHI 0048B.b).

[ARM Ltd.ARM Ltd.2013b]
authorpersonARM Ltd.
booktitleCoreSight Technical Introduction.
typeWhite paper ARM-EPM-039795.

[ARM Ltd.ARM Ltd.2015]
authorpersonARM Ltd.
titleARM DS-5 Version 5 ARM DSTREAM User Guide.
(DUI 0481K).

[ARM Ltd.ARM Ltd.2020a]
authorpersonARM Ltd.
titleARM Architecture Reference Manual – ARMv8, for
ARMv8-A architecture profile.
(DDI 0487F.c).

[ARM Ltd.ARM Ltd.2020b]
authorpersonARM Ltd.
titleCycle Model Studio, ver. 11.2 – User Manual.

[Cheng and WangCheng and Wang2012]
authorpersonLuwei Cheng and personCho-Li
Wang. year2012.
vBalance: Using Interrupt Load Balance to Improve
I/O Performance for SMP Virtual Machines. In
booktitleProceedings of the 3rd ACM Symposium on Cloud
Computing (SoCC). publisherACM Press.

[Daimler AGDaimler AG2018]
authorpersonDaimler AG.
titleAt a glance: The key data on MBUX.

[fortiss GmbH – Research Institute of the
Free State of Bavariafortiss GmbH – Research Institute of the Free State
of Bavaria2020]
authorpersonfortiss GmbH – Research Institute of the
Free State of Bavaria. year2020.
titletoki Development Site.

authorpersonPatrick Frey.
booktitleCase study: engine control application.
typeTechnical Report. institutionOpen
Access Repositorium der Universität Ulm.

[Horst and BaumgartenHorst and
authorpersonOliver Horst and personUwe
Baumgarten. year2019.
toki: A Build- and Test-Platform for Prototyping
and Evaluating Operating System Concepts in Real-Time Environments. In
booktitleProceedings of the Open Demo Session of Real-Time
Systems (RTSS@Work) held in conjunction with the 40th IEEE Real-Time Systems
Symposium (RTSS).

[Horst, Wiesböck, Wild, and BaumgartenHorst
et al2020]
authorpersonOliver Horst, personJohannes
Wiesböck, personRaphael Wild, and personUwe
Baumgarten. year2020.
titleQuantifying the Latency and Possible Throughput of
External Interrupts on Cyber-Physical Systems: Measurement Software and
Measured Data.
howpublishedAvailable on Zenodo.

authorpersonE. Douglas Jensen.
Wrong Assumptions and Neglected Areas in Real-Time
Systems. In booktitleProceedings of the 11th IEEE
International Symposium on Object and Component-Oriented Real-Time
Distributed Computing (ISORC). publisherIEEE.

[Keysight TechnologiesKeysight
authorpersonKeysight Technologies.
titleInfiniiVision 6000 X Series Oscilloscopes Data

[Koning and EvensenKoning and
authorpersonMaarten Koning and personTomas
Evensen. year2013.
titleInterrupt latency measurement.
howpublishedU.S. Patent No. 8,612,660.

authorpersonPaul D. Lever.
titleContinuous monitor for interrupt latency in real time
howpublishedU.S. Patent No. 5,944,840.

[Liu, Liu, Wang, Wang, and ShaoLiu
et al2011]
authorpersonMiao Liu, personDuo Liu,
personYi Wang, personMeng Wang, and
personZili Shao. year2011.
On Improving Real-Time Interrupt Latencies of
Hybrid Operating Systems with Two-Level Hardware Interrupts.
journalIEEE Trans. Comput. volume60,
number7 (dateJuly year2011),

authorpersonMartin W.S Macauley.
Interrupt latency in systems based on Intel
80×86 processors.
journalMicroprocessors and Microsystems
volume22, number2 (dateJune
year1998), pages121–126.

authorpersonDavid Manners.
titleDesign IP market grew 5.2% last year.

[Müller and PaulMüller and Paul1995]
editorpersonSilvia M. Müller and
personWolfgang J. Paul (Eds.). year1995.
booktitleThe Complexity of Simple Computer
publisherSpringer-Verlag, Chapter 8,

[NXP SemiconductorsNXP
authorpersonNXP Semiconductors.
titleMeasuring Interrupt Latency.
howpublishedApplication Note AN12078.

[Prasad, Jain, and DovrolisPrasad
et al2004]
authorpersonRavi Prasad, personManish Jain,
and personConstantinos Dovrolis.
Effects of Interrupt Coalescence on Network
In booktitleLecture Notes in Computer Science.
publisherSpringer-Verlag, pages247–256.

[Regnier, Lima, and BarretoRegnier
et al2008]
authorpersonPaul Regnier, personGeorge
Lima, and personLuciano Barreto.
Evaluation of interrupt handling timeliness in
real-time Linux operating systems.
journalACM SIGOPS Operating Systems Review
volume42, number6 (dateOct.
year2008), pages52–63.

[Renesas Electronics Corp.Renesas
Electronics Corp.2020]
authorpersonRenesas Electronics Corp.
titleRenesas Advanced Automotive SoC Adopted by
Continental for Its Body High-Performance Computer.

[Rybaniec and WieczorekRybaniec and
authorpersonRadosław Rybaniec and
personPiotr Z. Wieczorek. year2012.
Measuring and minimizing interrupt latency in
Linux-based embedded systems. In booktitlePhotonics
Applications in Astronomy, Communications, Industry, and High-Energy Physics
Experiments 2012, editorpersonRyszard S. Romaniuk
(Ed.). publisherSPIE.

[Tang, Chucholowski, and LienkampTang
et al2014]
authorpersonTito Tang, personFrederic
Chucholowski, and personMarkus Lienkamp.
Teleoperated driving basics and system design.
journalATZ worldwide volume116,
number2 (dateJan. year2014),

[Tesla, Inc.Tesla, Inc.2019]
authorpersonTesla, Inc.
titleTesla Autonomy Day.

authorpersonRaphael Wild.
titleEvaluation of a Multi-core Processor Regarding
Response Time and Load Limit for Interrupt Processing.
B.S. thesis. schoolTechnical University of Munich.

[Xilinx, Inc.Xilinx, Inc.2019a]
authorpersonXilinx, Inc.
titleZCU102 Evaluation Board – User Guide.
UG1182 (v1.6).

[Xilinx, Inc.Xilinx, Inc.2019b]
authorpersonXilinx, Inc.
titleZynq UltraScale+ Device – Technical Reference
UG1085 (v2.1).

[Xilinx, Inc.Xilinx, Inc.2020]
authorpersonXilinx, Inc.
titleXilinx Embedded Software (embeddedsw) Development.

[Yocto ProjectYocto Project2020]
authorpersonYocto Project.