Introduction to Real Time

Linux

1
 Real-time versus Time Shared

 Time sharing OS: (GPOS) attempt to

maximize system throughput.

 Real time OS: (RTOS) attempt to

minimize latencies-either statistically
(soft) or worst case (hard)

2
 RTLinux

 A small hard real time operating system

 Runs linux as its lowest priority task

 RTLinux=RealTime+ Linux (two classes

of OSs working together)

3
 The RTOS Design Paradox
 A RTOS needs to be fast and predictable
so it needs to be small and precisely
designed.
 Modern RT applications need
networking, GUIs, databases,
development environments, web
servers, and so on. In other words, the
OS must be rich with functionality.
 But both of these conflict with each
other!! 4
 Approach 1
Start with a small, simple, and fast RTOS. Add
features and functionality as needed.
Pros:
 Achieves Hard real time performance!
 Increase in determinism
 GPOS features are available
Cons:
 Slow (eg. millisec level)
 Complex relation between drivers and software
 All software and drivers must be hacked to work in
environment
 Difficult to maintain and debug (costly)
5
 Approach 2
Start with a big, powerful, complicated OS, and
add special RT processes:
Pros:
 Achieve Soft Realtime performance!
 Increased determinism
 GPOS features are maintained
Cons:
 Very Slow (eg. hundreds of milli-secs)
 Complex relation between drivers and software
 All software and drivers must be hacked to work in
environment
6
 Difficult to maintain and debug (costly)
 RTLinux approach
Start with small, simple, and fast RTOS. Add full
featured GPOS as lowest priority thread.
Pros:
 Achieves Hard realtime performance!
 both RTOS and GPOS are decoupled
 each is optimized independently.
 GPOS features are maintained
 RTOS predictability reaches hardware limits (eg. tens
of micro-secs)!
Cons:
 Realtime programming model must be altered.
7
 RTLinux Advantages
 Small RTOS (150kB!!)

 Fast (micro-second level)

 High degree of predictability (15 micro

sec jitter on x86)

 All the sophisticated services are found

in the Linux thread 8
 Design Scheme
 A GPOS (Linux) is given a hardware
interrupt emulation layer (virtual
machine) so it cannot disable interrupts.

 the RTOS decides when to pass

interrupts to the GPOS

 RT applications cannot be delayed by

non-RT software! 9
RTLinux-Block Diagram

10
GPOS view of RTLinux

11
RTLinux view of GPOS

12
RTLinux view of GPOS

13
Non RT Kernel

14
RT Linux Kernel

15
 RTLinux Kernel Linux is executed in the background

User Processes

Real Time Tasks System libraries

Device drivers Linux kernel

I/O Software Interrupts

Direct
h/w RT-Scheduler
access RTLinux Plug-in

I/O Hardware Interrupts

Hardware

16
RTLinux Advantages

 Performance nears hardware limits. Ex: on a fully

loaded machine (compiling the Linux kernel, running
Netscape, and a ping flood), the worst case jitter on
a periodic task running at 1ms, 24 hour test:
 Pentium4/Athlon: 13 micro sec
 Dual Pentium 4: 16 micro sec
 G4: 15 micro sec

 tiny footprint (150kB)

 standardized API POSIX threads and signals

 uses all of the Linux functionality without interfering

with the mainstream Linux Development
17
RTLinux Advantages contd..

 no scheduling interactions with the GPOS

 no dependencies between RTOS and GPOS except by
programmer choice
 The split design encourages a safe programming
style with clear separation between hard RT and
soft/non-RT

 Use any third party software. Examples:

 databases: Oracle, DB2, MySQL, PostgreSQL etc.
 editors: emacs, vi, jove etc.
 graphical toolkits: GTK+, Qt etc.

18
RT Linux – Tasks
 Initial Design – Each RT task executed in its
own address space.
 High overhead of context switching as TLB
had to be invalidated.
 High overhead of system calls.
 Now all RT tasks run in the same address
space (in the kernel space) and at the highest
privilege level.
 But highly error prone as a bug in a single
application can wipe out entire system.
19
RT Linux – Tasks (Contd.)
 RT tasks run as kernel modules. Can be
dynamically added.
 Tasks have integer context for faster context
switching (unless FP context is explicitly
requested).
 Hardware context switching provided by x86
is not used.
 Task resources should be statically allocated
(kmalloc etc. should not be used within an RT
task).
20
RT Linux - Scheduling
 RT Linux is module based – the
scheduler is itself a loadable kernel
module.
 Default – A simple preemptive priority
based scheduler where the tasks are
statically assigned priorities. The
highest priority task ready to run is
scheduled.
 Cooperative Scheduling 21
RT Linux – Scheduling
(Contd.)
 Alternate scheduling policies
 Earliest Deadline First (EDF) – A dynamic priority
scheduler in which the task with the nearest
deadline is scheduled.
 Rate Monotonic (RM) – A static priority scheduler
for periodic tasks where the task with the smallest
period is assigned the highest priority. This is
provably the optimal policy.
 ADS-Application Defined Scheduler

22
Design of applications using
RT Linux
 It is envisaged that applications will
consist of two parts.
 The Real Time part should be fast,
simple and small.
 Other part will run in user space and
should take care of I/O etc.
 User task will communicate with real
time task via real time fifos.

23
 Structure of RT Application
RT Fifo

User Process
RT Fifo

X Windows Linux Kernel

RT Process

Display Disk Network

Peripheral Device

24
Conclusion
 RT Linux has achieved hard real-time
performance by making minimal changes to a
freely available Operating System.
 Provides an alternative to proprietary real-
time systems which may be prohibitively
expensive.
 As Linux develops, RT Linux will also ride the
wave of its development.
 Unlike other RT systems, no separate support
for RT Linux is needed since support for Linux
is already widely available. 25
RTLinux Demonstration

26