0001 IRQ Latency Benchmark
0002 ---------------------
0003
0004 1. Overview
0005
0006 This latency benchmark for external interrupts consists of three parts:
0007
0008 1. xeno_irqbench (ksrc/drivers/testing)
0009 RTDM driver for the test target to handle and reply to the IRQ events, or
0010 forward them to user-space.
0011
0012 2. irqloop (src/testsuite/irqbench)
0013 xeno_irqbench control front-end and user-space loop-closer. Runs against
0014 the POSIX skin on the test target.
0015
0016 3. irqbench (src/testsuite/irqbench)
0017 IRQ triggering and reaction measuring tool for the log system. Runs over
0018 plain Linux on x86 hosts. Note that this tool will only be compiled
0019 automatically with Xenomai if the target architecture is x86. To compile
0020 it manually, invoke
0021
0022 <gcc-x86-compiler> irqbench.c -o irqbench -O2
0023
0024
0025 2. Hardware Setup
0026
0027 To link both test and log system, a null-modem cable between 8250-compatible
0028 two RS232 ports or a Laplink cable between two PC parallel ports is required.
0029 The null-modem cable must provide at least the following links:
0030
0031 test target log system
0032 ----------- ----------
0033 CTS(8) <------ RTS(7) IRQ trigger
0034 RTS(7) ------> CTS(8) reply
0035
0036 DCD(1)
0037 and/or <------ DTR(4) trace trigger (optional)
0038 DSR(6)
0039
0040 (Pin number on 9-pin sub-D socket)
0041
0042 The relevant links of the Laplink cable are:
0043
0044 test target log system
0045 ----------- ----------
0046 /ACK(10) <------ DATA3(5) IRQ trigger
0047 DATA3(5) ------> /ACK(10) reply
0048
0049 BUSY(11) <------ DATA4(6) trace trigger (optional)
0050
0051 Test and log system can be started in arbitrary order, they will wait on
0052 each other.
0053
0054
0055 3. Test Scenarios
0056
0057 The xeno_irqbench driver supports four different IRQ handling scenarios,
0058 selectable via "-t <test_mode>" on irqloop start-up:
0059
0060 Mode 0 - Installs an IRQ handler that wakes up a user-space task. This task
0061 is provided by irqloop. Once it is woken up, it will issue an IOCTL
0062 to xeno_irqbench in order to generate the reply. This scenario is
0063 typical for kernel-based device drivers.
0064
0065 Mode 1 - Same as mode 0, except that the task resides inside the kernel and is
0066 provided by xeno_irqbench itself. A typical scenario for kernel-based
0067 RT-applications or drivers that handle IRQ requests inside a kernel
0068 task.
0069
0070 Mode 2 - Installs an IRQ handler that directly replies to the event. This
0071 scenario measures the reactivity of driver IRQ handlers when handling
0072 events immediately or taking timestamps.
0073
0074 Mode 3 - In this mode, an additional I-pipe domain is registered on top of
0075 Xenomai. The IRQ handler for immediate reply is then assigned to the
0076 new domain. By pushing the handling above Xenomai, the IRQ reply
0077 latency can widely be decoupled from RT-application-related delays.
0078 The drawback is that no direct interaction with the Xenomai scheduler
0079 is possible from the higher domain. Note that the nucleus option
0080 CONFIG_XENO_OPT_PIPELINE_HEAD has to be switched off to be able to
0081 use this mode.
0082
0083
0084 4. Measuring
0085
0086 The log system runs each single IRQ measurement with local IRQs disabled. It
0087 will wait up to 100 times the current period on the test system's reply (after
0088 initial successful synchronisation, which happens with IRQs enabled). Note that
0089 these timeouts may disturb other processes or drivers on the log system.
0090
0091 Keep in mind for test evaluations that, by design, irqbench will not trigger a
0092 new IRQ event before the reply on the previous one has arrived or timed out.
0093 Thus the specified test period may be dynamically expended in case of
0094 overload. But a maximum latency close or above the period will clearly
0095 indicate this.
