Benchmark and comparison of real-time solutions based on embedded Linux

Transcription

1 Benchmark and comparison of real-time solutions based on embedded Linux Peter Feuerer August 8, 2007

2 Table of contents General Motivation Real-time computing Preparations Environment setup Open Realtime Framework Benchmarks Interrupt latency Jitter Maximal frequency Inter-process communication Overload behavior Priority functionality Conclusion

3 General Motivation Motivation To enhance Linux by real-time ability there are different real-time approaches and different hardware platforms. When specifying the system for a particular application one real-time approach and one hardware must be chosen. A benchmark is needed.

4 General Real-time computing What is real-time? A real-time capable system is reliable has deterministic behaviour and is able to adhere to specified deadlines. There are two main real-time categories: Soft real-time - would be great to adhere to deadlines. Hard real-time - not allowed to miss any deadline.

5 General Real-time computing Linux real-time approaches Rtai: Xenomai: Rt-Preempt: One of the first approaches. Dual kernel. Real-time applications in kernel-space. Dual kernel. Skin support, e.g. Posix API, VxWorks API. Real-time applications in user- and kernel-space. Patch to make vanilla Linux kernel real-time capable. Real-time applications run in user-space.

6 Preparations Environment setup Overview To get meaningful results from a practical point of view, this setup is used:

7 Preparations Environment setup Target setup Intel x86: PowerPC: ARM: Hardware: AMD k7 600Mhz desktop PC, Kontron Geode gx1 embedded system. Software: modified ArchLinux distribution, Linux kernel 2.6 and 2.4 with Rtai, Xenomai and a rt-preempt patched 2.6 kernel Hardware: MEG32 from Frenco Software: ELDK toolchain and Linux kernel 2.6 and 2.4 with Xenomai and kernel 2.4 with Rtai Hardware: LILLY-9xx board from Incostartec. Software: skipped, due to missing patches of the real-time extensions.

8 Preparations Environment setup Measurement USB-Scope Mephisto UM202: C-API and library to write custom measurement applications Windows application with GUI to monitor and control

9 Preparations Open Realtime Framework What is ORF? The Open Realtime Framework is an open source project initiated and developed by Yellowstone-Soft. Standardized API for real-time applications Platform independent and portable Cyclical working sequential controls like a Siemens PLC has Modular design

10 Preparations Open Realtime Framework ORF enhancement: Dynamical linked libraries To enable addition and removal of real-time programs without stopping ORF, programs are built as libraries and loaded dynamically. Changes to ORF: Management for the loaded libraries Functionality for linking and unlinking Modification to orf add initfunc and orf delete initfunc functions to not conflict with ORF spec.

11 Preparations Open Realtime Framework ORF enhancement: Character devices The former communication between ORF and user-space was done by Rtai FIFOs. platform dependent. Standard kernel device files has been implemented: Former Rtai FIFOs has been removed /dev/rtf[0-x] is handled by main ORF module One communication cycle: 1. User-space application writes command 2. ORF processes command and blocks user-space application 3. User-space application reads result

12 Preparations Open Realtime Framework ORF enhancement: I/O-API To create meaningful benchmarks from a practical point of view I/O-port access is needed. An I/O-API within ORF enables platform independent usage. It consists of four functions: init-io to initialize the I/O-port reset-io to reset the I/O-port outb writes data inb reads data

13 Preparations Open Realtime Framework ORF enhancement: Interrupt handling Catching interrupts was not implemented in ORF yet. Special interrupt threads have been added to ORF to meet ORF s specs Interrupt service routine wrappers are introduced ORF real-time progs add their main function to the interrupt wrapper

14 Benchmarks Interrupt latency Interrupt latency Idea: I/O-pin is set high level interrupt is created ORF program catches interrupt and sets pin back to low Duration of high level phase is measured

15 Benchmarks Interrupt latency Results: Interrupt latency Blue: system is idling Red: system is under heavy load

16 Benchmarks Jitter Jitter Idea: ORF program creates square-wave Scope application measures durations Maximal jitter is calculated

17 Benchmarks Jitter Results: Jitter

18 Benchmarks Maximal frequency Maximal Frequency Idea: Alive square-wave signal on pin 2 Square-wave signal with rising frequency on pin 1 Measurement application calculates frequency of pin 1 Maximal frequency is stored if no malfunction appeared Measurement stops if alive signal or frequency signal gets lost

19 Benchmarks Maximal frequency Results: Maximal Frequency

20 Benchmarks Inter-process communication Inter-process communication Idea: Echo function implemented into ORF writes received data back counts packages Infinite amount of packages are written to the character device file ORF real-time program prints amount of transmitted packages every second

21 Benchmarks Inter-process communication Results: Inter-process communication

22 Benchmarks Overload behavior Overload behavior Idea: 2 threads, one with high frequency, one with lower frequency A shot of the lower frequent thread produces short-time overload Two scenarios: light overload - period of high frequent thread is delayed heavy overload - period of high frequent thread is omitted

23 Benchmarks Overload behavior Results: Overload behavior ppc / 2.6 / xn x86 / 2.6 / xn x86 / 2.6 / rtai test1 test2 test1 test2 test1 test2 No load X - X - X - Heavy load X - X - o -. x86 / 2.4 / rtai test1 test2 No load X - Heavy load o - X: test passed -: test aborted o: machine died

24 Benchmarks Priority functionality Priority functionality Idea: 4 threads with different priority and frequency Every thread sets its output pin to high, when active Measurement application checks preemption

25 Benchmarks Priority functionality Results: Priority functionality The result contains the amount of how often each thread has been preempted by any other thread. Linux Xenomai: No load Heavy load T0 T1 T2 T3 T0 T1 T2 T3 T T T T

26 Conclusion Conclusion The benchmark suite created in this project can be used to do meaningful evaluations of real-time approaches on various platforms. Rtai: very deterministic, high performance overload must be avoided Xenomai: Rt-Preempt: stable in case of overloads state of the art technology skin support in the very beginning hard-real-time capability

27 Questions & Answers Questions?