The Design of the TAO RealTime ORB

1
The Design of the TAO Real-Time ORB

• By
• Douglas Schmidt, David Levine and Sumedh Mungee
• Washington University

2
The Track

• CORBA Primer
• TAO Architecture
• I/O subsystem
• ORB core
• Objec adapters
• Stubs, skeletons Memory management
• Real-Time scheduling service
• RT_Operation interface
• Off-line online scheduling
• Performance Measurements Comparisons
• Summary
• Questions

3
CORBA Primer

• Standardized architecture for distributed object
  computing
• Object location transparency
• Programming language bindings
• Widely supprted on OS platforms
• Supported over many communication protocols
• Shielded from hardware details
• Eliminates tedious, error-prone and non-portable
  aspects of low-level programming
• Automates common network programming tasks by IDL
  compiler
• Everything sounds great !!

4
CORBA 2.x Reference Model
5
Concept of GIOP

• General Inter-ORB Protocol
• Standard end-to-end interoperability protocol
  between potentially heterogenous ORBs
• Specifies an abstract interface to be mapped onto
  actual transport protocols
• IIOP is such a mapping where transport protocol
  is TCP
• The standard includes
• Common data representation
• GIOP message formats
• GIOP transport assumptions
• By virtue of GIOP, ORBs from different vendors
  can communicate as long as they follow the
  standard

6
Problems with 2.x model

• When it comes to Real-Time arena, its not so
  great !!
• Lack of QoS specification interfaces
• No admission control policies
• Lack of QoS enforcement
• Lack of language features
• Lack of performance optimizations
• The result ??
• Unbounded priority inversions
• Poor memory management operations
• No real-time guarantees

7
The weak points in 2.x
8
The Track

• CORBA Primer
• TAO Architecture
• I/O subsystem
• ORB core
• Objec adapters
• Stubs, skeletons Memory management
• Real-Time scheduling service
• RT_Operation interface
• Off-line online scheduling
• Performance Measurements Comparisons
• Summary
• Questions

9
TAO Synopsis

• The ACE ORB
• ACE is a highly portable OO middleware
  communication framework having rich set of C
  components implementing design patterns
• Applications can specify QoS requirements
  concisely
• Provide end-to-end bandwidth, latency and
  reliability guarantees
• Enforce deterministic and statistical end-to-end
  application QoS guarantees (Rate monotone
  scheduling).
• Minimized priority inversions
• Implemented and functional at
• Boeing for real-time avionics mission computing
• Run-Time infrastructure for defense modelling
• Siemens medical engineering framework
• Turkish navy for shipboard combat managementand
  many more

10
TAO Architecture

• High speed ATM network
• Real-time I/O subsystem
• Real-time schedduling service
• QoS API

User
Kernel
11
Real-time I/O subsystem

• Mediates ORB and application access to low-level
  network and OS resources
• Lowest level component in ORB
• APIC is priority aware
• Pre-allocates pool of kernel threads dedicated to
  protocol processing
• A message received from protocol is dispatched to
  a matching priority kernel thread - APIC decodes
  the message to extract priority
• Priority inversion is eliminated from very
  beginning !!
• Admission controller - refuses to admit the
  thread in case of over-utilization

12
Predictable ORB core

• Priority based concurrency arichitecture,
  priority based connection architecture and
  real-time inter-ORB protocol

3 client threads
4 priority levels
13
ORB Core (contd)

• Each client thread maintains a Connector, each
  having a separate connection for each thread
  priority in server ORB
• On server side, Reactor is associated with each
  thread priority and uses Acceptor to listen on a
  specific port numbers for client requests
• Each priority level has its own specific Acceptor
  port number, so requests arriving at these ports
  can be associated with the corresponding priority
  thread - connection established
• Acceptor creates a new socket queue and a GIOP
  connection handler to service that queue
• I/O subsystem (APIC) uses port number contained
  in the arriving requests as a demux key to
  associate requests with appopriate socket queue

14
ORB core (contd)

• Client uses strategy_connector to create and
  cache connection_handlers bound to each server
• On server side, reactor detects new incoming
  connections and notifies strategy_connector
• strategy_connector accepts the new connection and
  associates it with an appropriate real-time
  priority

15
The Track

• CORBA Primer
• TAO Architecture
• I/O subsystem
• ORB core
• Objec adapters
• Stubs, skeletons Memory management
• Real-Time scheduling service
• RT_Operation interface
• Off-line online scheduling
• Performance Measurements Comparisons
• Summary
• Questions

16
Efficient Object Adapters

• Demux incoming client requests to a servant and
  dispatch an appropriate operation
• Uses perfect hashing (gperf) or active demuxing
  tomap client requests directly to
  servant/operation tuples in O(1) time
• Conventionally, demuxing goes through many layers
  
• OS demuxes the request and dispatches data to ORB
• ORB locates corresponding POA and servant in POA
  hierarchy
• POA uses operation name to find appropriate
  skeleton which in turn calls the operation after
  demarshalling
• TAO eliminates some of these and uses efficient
  hashing algorithm for demuxing

17
Object Adapter Comparison
Conventional ORBs
TAO
18
Stubs Skeletons

• Marshalling to and demarshalling from common data
  representation - presentation layer
• Compiler optimizations (IDL)
• Minimize use of dynamic memory allocation and
  data copying
• Allocate sufficient storage a priori to avoid
  run-time allocation
• Perform copies in blocks of data chunks
• Use inlining for stubs and skeletons
• Cache premarshalled application data units that
  are used repeatedly

19
Memory Management

• Heap fragmentation can yield non-uniform behavior
  for different message sizes and different
  workloads
• Locks required to protect the heap from race
  conditions increase potential for priority
  inversion
• Make use of zero-copy buffer system
• Thread specific storage pattern to minimize lock
  contention resulting from memory allocation

20
The Track

• CORBA Primer
• TAO Architecture
• I/O subsystem
• ORB core
• Objec adapters
• Stubs, skeletons Memory management
• Real-Time scheduling service
• RT_Operation interface
• Off-line online scheduling
• Performance Measurements Comparisons
• Summary
• Questions

21
Real-Time Scheduling Service

• Scheduling service is defined as a CORBA object
  (implementation of an IDL inteface)
• Application registers with schduling service and
  specifies its QoS requirements for all operations
  with RT_info constructs (part of RT_operation
  interface) for each of the operations one
  opeartion -gt one RT_info
• Scheduling service, then analyzes all the RT_info
  structs for schedulability, assigns priorities to
  each of the operations and prepares a operation
  -gt priority table. This process is off-line
  scheduling.
• At run-time, the run-time scheduler accesses the
  priority-table to lookup the priorities of the
  invoked operations and asssociates them to
  appropriate system thread

22
Steps in Real-time Scheduling
23
Some Remarks

• Application specify dependencies. A depends on B
  if A always calls B. By this information,
  dependency graphs are created to identify
  threads.
• Application also specifies number of times A
  calls B. With this information, rate of each task
  can be obtained, which inturn maps to priority
  levels.
• The off-line part of the scheduling is performed
  in configuration runs. Once configured, the
  priority tables remain static.
• Each terminal node in the DAG constructed above
  represents a thread.
• An operation containing one or more threads is
  called active object. Whereas an operation
  containing zero threads is a passive object.

24
Performance Measurements

• Measuring degree of priority-inversion in ORB
• A high priority client Co and N low priority
  clients C1 to Cn, make requests concurrently to
  the server end-system
• N, the number of low priority clients is
  increased gradually to observe the change in the
  response time of the highr priority client.
• Experimented with IONA Orbix, Visigenic
  Visibroker and TAO
• Due to the priority inversions present in the
  conventional ORBs and layered demuxing process,
  TAO performs significantly better than both the
  commercial products.

25
Comparison
Orbix
Visibroker
TAO
26
Summary

• Key design issue is to minimize inversions for
  real-time ORBs
• Performance optimizations (without compromizing
  worst case performance) may result in
  significantly better behavior above ORB level
• QoS specification, enforcement and control are
  mandatory for real-time middleware services
• Connecstion per priority model integrates the ORB
  vertically to provide deterministic behavior at
  ORB level
• Early demultiplexing of requests can minimize
  prority inversion and provide predictable
  behavior below ORB level (APIC)

27
Questions

• ??