Benchmark and comparison of real-time solutions based on embedded - - PowerPoint PPT Presentation

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

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

Peter Feuerer August 8, 2007

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

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

Benchmark and comparison of real-time solutions based on embedded Linux 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.

Benchmark and comparison of real-time solutions based on embedded Linux 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.

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

Linux real-time approaches

Rtai:

◮ One of the first approaches. ◮ Dual kernel. ◮ Real-time applications in kernel-space.

Xenomai:

◮ Dual kernel. ◮ Skin support, e.g. Posix API, VxWorks API. ◮ Real-time applications in user- and kernel-space.

Rt-Preempt:

◮ Patch to make vanilla Linux kernel real-time capable. ◮ Real-time applications run in user-space.

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

Overview

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

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

Target setup

Intel x86:

◮ 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 PowerPC:

◮ Hardware: MEG32 from Frenco ◮ Software: ELDK toolchain and Linux kernel 2.6 and

2.4 with Xenomai and kernel 2.4 with Rtai ARM:

◮ Hardware: LILLY-9xx board from Incostartec. ◮ Software: skipped, due to missing patches of the

real-time extensions.

Benchmark and comparison of real-time solutions based on embedded Linux 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

Benchmark and comparison of real-time solutions based on embedded Linux 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

Benchmark and comparison of real-time solutions based on embedded Linux 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.

Benchmark and comparison of real-time solutions based on embedded Linux 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

Benchmark and comparison of real-time solutions based on embedded Linux 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

• f four functions:

init-io to initialize the I/O-port reset-io to reset the I/O-port

• utb writes data

inb reads data

Benchmark and comparison of real-time solutions based on embedded Linux 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

Benchmark and comparison of real-time solutions based on embedded Linux 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

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

Results: Interrupt latency

◮ Blue: system is idling ◮ Red: system is under heavy load

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

Jitter

Idea:

◮ ORF program creates square-wave ◮ Scope application measures durations ◮ Maximal jitter is calculated

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

Results: Jitter

Benchmark and comparison of real-time solutions based on embedded Linux 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

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

Results: Maximal Frequency

Benchmark and comparison of real-time solutions based on embedded Linux 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

Benchmark and comparison of real-time solutions based on embedded Linux Benchmarks Inter-process communication

Results: Inter-process communication

Benchmark and comparison of real-time solutions based on embedded Linux 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

Benchmark and comparison of real-time solutions based on embedded Linux 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
• .

x86 / 2.4 / rtai test1 test2 No load X

• Heavy load
• X: test passed
• : test aborted
• : machine died

Benchmark and comparison of real-time solutions based on embedded Linux 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

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

Results: Priority functionality

The result contains the amount of how often each thread has been preempted by any other thread. Linux 2.6 + Xenomai: No load Heavy load T0 T1 T2 T3 T0 T1 T2 T3 T0 T1 932 903 T2 922 104 925 98 T3 4480 486 40 4531 503 48

Benchmark and comparison of real-time solutions based on embedded Linux 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:

◮ stable in case of overloads ◮ state of the art technology ◮ skin support

Rt-Preempt:

◮ in the very beginning ◮ hard-real-time capability

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

Questions?