RealTime Processing Environments on Commodity OS

1
Real-Time Processing Environments on Commodity OS

• Dimitris Nikolopoulos, CSRD
• ITR group meeting, 6/8/2001

2
Contents

• Resource kernels for commodity OS
  Oikawa and Rajkumar IEEE RTAS 99
• Abstractions reserves, resources sets and
  reservations
• Design and implementation issues
• Portability
• OS support for fine-grain distributed simulations
  House and Niehaus IEEE RTAS00
• Metrics of performance
• OS bottlenecks
• High-level real-time programming in Java
  Niz and Rajkumar IEEE RTAS00
• Scheduling and synchronization issues

3
Resource kernels

• Resource-centric approach for building
  real-time kernels with minimal extensions to
  commodity OS
• Designed for portability
• Timely, guaranteed and enforced access to system
  resources (CPU, disk, network)
• Evolved from previous work on real-time Mach
  Rajkumar98

4
Overall architecture
Thread
Thread
Thread
Thread
Thread
Application Layer
Portable RK
Resource Set
Resource Set
Rsv,CPU
Rsv,Disk
Rsv,CPU
Rsv,Net
Rsv,Net
Sched, Disk
Sched, Net
Sched, CPU
Disk
Network
CPU
OS layer
5
Reserves

• Admission control
• Scheduling policy
• Enforcement
• Accounting
• Time-multiplexed, space-multiplexed
• Reservations parameters C, T for time-shared
  resources

C
T
6
Resource sets

• Set of reserves
• Programming Interface
• rk_resource_set_create
• rk_resource_set_destroy
• rk_resource_set_attach_thread
• rk_resource_set_detach_thread
• cpu_reserve_create
• cpu_reserve_ctl
• disk_reserve_create

7
Implementation

• Preemptive round-robin scheduling
• Implementation of customized schedulers via
  explicit assignment of priorities to threads
• Highest priority real-time scheduler thread
• Lowest priority non-real-time scheduler thread
• Native OS mechanisms for suspending and resuming
  threads
• sleep_on(), wake_up()
• Accounting
• Callback hooks for context switching, interrupts,
  system calls
• Polling status at user-level
• /proc interface

8
Portability

• Priority control ?
• Suspending resuming processes ?
• Polling status at user-level ?
• Accounting ?

9
Distributed fine-grain synchronous computing

• Applications real-time simulation at the
  microsecond scale (e.g. ATM simulation, hard
  real-time), distributed videoconference
  (soft-real time), control (hard real-time)
• Balance epoch time (ET) between computation (CT)
  and slack time (ST) according to the application
  characteristics ETCTST
• Evaluate the tolerance of the application to
  missed epochs

Receive
Compute
Transmit
CT
ST
ET
10
Performance metrics

• Missed epochs
• Epoch execution time
• CPU utilization
• Per epoch
• Global
• Application-specific requirements
• Videoconferencing limit the rate of missed
  epochs
• ATM simulation reduce execution time, shorten
  epoch execution time up to a point where the
  overhead of missed epochs does not outweigh the
  reduction of execution time

11
Implementation Issues

• Fine-grain timers
• OS timers work at the granularity of 10 ms
• Timers at a granularity of 100 µs required
• Hardware counters (e.g. Pentium 64-bit TSC)
• Reduction of the frequency of interrupts
• Multiplexing of simulation events on the same
  node
• Localized communication

12
Implementation challenges(1) scheduling jitter

• Scheduling jitter
• Introduced from other activities in the system
• Sources
• Interrupt service routines and bottom halves
• Solutions
• Better implementation of ISRs (hard,
  non-portable)
• Scheduling ISRs in a dedicated kernel thread

13
Implementation challenges(2) clock
synchronization

• Different notion of clock rates and absolute time
  in different components of the distributed system
• Epoch interleaving
• Solution, NTP protocol

14
Java for real-time processing

• Pros
• Portability
• Cons
• Low performance of interpreted code
• Garbage-collection slows down execution in an
  unpredictable manner
• Interaction with the native OS scheduler. Code is
  portable but performance may be not
• Efforts
• Scheduling of real-time Java Threads(RTJ)
• Protocols that deal with priority inversion

15
RTJ Specification Design

• Independent of the Java environment (Personal
  Java, Embedded Java, etc.)
• Compatible with non-real time Java code
• Platform-independent to the extent possible
• Extensibility
• Predictability
• No extensions that require changes of the compiler

16
RTJ Specification

• Extensible thread scheduler
• New memory regimes
• Synchronization
• Asynchronous event handling
• Asynchronous transfer of control
• Thread termination
• Physical memory access

17
RTJ scheduling

• Preemptive FIFO scheduling
• Extensible scheduler interface
• Exploitation of resource kernels for portable
  real-time thread scheduling
• Extensions
• javax.RealtimeThread
• Periodic parameters
• Priority parameters
• Dynamic policy parameters

18
RTJ memory regimes

• Immortal memory
• Memory can not be garbage-collected
• Resident memory
• Scoped memory
• Constant time memory
• Shared vs. private memory
• Immortal memory is shared
• Constant time memory is private to cope for
  unpredictable synchronization overhead

19
Bounding priority inversion

• A thread holding a lock is not scheduled because
  its priority is lower than an idling thread that
  busy-waits
• Priority inheritance
• The thread that holds a lock inherits the
  priority of a thread that busy-waits for the lock
  if the priority of the latter is higher
• Interference with resource-kernel priorities
• Race between the resource kernel and the priority
  control mechanisms in the monitors
• Solution select the higher of the two priorities

20
Conclusions

• Portable extensions to commodity OS for soft
  real-time processing are feasible
• Hard real-time processing subject to performance
  limitations of most OS kernels
• Slow interrupt handling
• Unpredictable scheduling overhead
• Monolithic architecture, non-preemptive kernels
• Extensibility appears to be the most critical
  issue