High-performance and Real-time CORBAschmidt/PDF/tutorial.pdf · High-performance and Real-time...

High-performance and Real-time CORBA

Douglas C. [email protected]

Washington University, St. Louiswww.cs.wustl.edu/�schmidt/

This work was sponsored in part by Boeing and DARPA

Douglas C. Schmidt High-performance CORBA Tutorial

Problem: High-Performance, Real-time Middleware

DDIIAAGGNNOOSSTTIICC

SSTTAATTIIOONNSS

AATTMMMMAANN

AATTMMLLAANN

AATTMMLLAANN

MMOODDAALLIITTIIEESS

((CCTT,, MMRR,, CCRR)) CCEENNTTRRAALL

IIMMAAGGEESSTTOORREE

CCLLUUSSTTEERRIIMMAAGGEESSTTOORREE

DDXXIIMMAAGGEESSTTOORREE

� Many applications requirehigh-performance

– e.g., telecom, imaging,WWW

� Building these applicationsmanually is hard

� Existing middleware doesn’tsupport performanceeffectively

– e.g., CORBA, DCOM,DCE

Washington University, St. Louis 1


Candidate Solution: CORBA

INTERFACEINTERFACE

REPOSITORYREPOSITORY

IMPLEMENTATIONIMPLEMENTATION


IDLIDLCOMPILERCOMPILER

DIIDII ORBORBINTERFACEINTERFACE

ORBORB CORECORE

operation()operation()

OBJECTOBJECT

ADAPTERADAPTER

in argsin args

out args + return valueout args + return value

CLIENTCLIENT

GIOPGIOP//IIOPIIOP

OBJECTOBJECT((SERVANTSERVANT))

IDLIDLSTUBSSTUBS

STANDARD INTERFACESTANDARD INTERFACE STANDARD LANGUAGE MAPPINGSTANDARD LANGUAGE MAPPING

ORB-ORB-SPECIFIC INTERFACESPECIFIC INTERFACE STANDARD PROTOCOLSTANDARD PROTOCOL

INTERFACEINTERFACE


IMPLEMENTATIONIMPLEMENTATION


IDLIDLCOMPILERCOMPILER

IDLIDLSKELETONSKELETON

DSIDSI

www.cs.wustl.edu/�schmidt/corba.html

� Goals of CORBA

– Simplifydistribution byautomating

� Object location &activation

� Parametermarshaling

� Demultiplexing

� Error handling– Provide

foundation forhigher-levelservices



Performance Challenges for ORB Middleware

OS KERNELOS KERNEL

OS IOS I//O SUBSYSTEMO SUBSYSTEM

NETWORK INTERFACESNETWORK INTERFACES

OS KERNELOS KERNEL



NETWORKNETWORK

ORBORBINTERFACEINTERFACE

operation()operation()

IDLIDLSTUBSSTUBS

OBJECTOBJECT

ADAPTERADAPTER

IDLIDLSKELETONSKELETON

in argsin args

out args + return valueout args + return value

GIOPGIOP//IIOPIIOPORBORB

CORECORE

11

22

33

44

55

66

77

1) CLIENT MARSHALING

2) CLIENT PROTOCOL QUEUEING

3) NETWORK DELAY

4) SERVER PROTOCOL QUEUEING

5) THREAD DISPATCHING

6) REQUEST DISPATCHING

7) SERVER DEMARSHALING

8) METHOD EXECUTION


88CLIENTCLIENT

� Key Challenges

– Specifying QoSrequirements

– Determining operationschedules

– Alleviating priorityinversion andnon-determinism

– Reducing latency/jitter fordemultiplexing

– Reducing presentationlayer overhead

– Maintaining small footprint



The ACE ORB (TAO)

NETWORK

ORB RUN-TIME

SCHEDULER

REAL-TIMEORB CORE

operation()

RIDLSTUBS

REAL-TIME

OBJECT

ADAPTER

RIDLSKELETON

in args

out args + return value

CLIENT

OS KERNEL

HIGH-SPEED

NETWORK INTERFACE

REAL-TIME I/OSUBSYSTEM

RIOP

OBJECT(SERVANT)

OS KERNEL

HIGH-SPEED

NETWORK INTERFACE

REAL-TIME I/OSUBSYSTEM

ACE COMPONENTS

www.cs.wustl.edu/�schmidt/TAO.html

� TAO Overview

– A real-time,high-performanceORB

– Leverages ACE

� Runs on POSIX,Win32, RTOSs

� Related work

– U. RI, Mitre– QuO at BBN– ARMADA at U.

Mich.



The ADAPTIVE Communication Environment (ACE)

PROCESSESPROCESSES//THREADSTHREADS

DYNAMICDYNAMIC

LINKINGLINKING

MEMORYMEMORY

MAPPINGMAPPING

SELECTSELECT//IO COMPIO COMP

SYSTEMSYSTEM

VV IPCIPCSTREAMSTREAM

PIPESPIPES

NAMEDNAMED

PIPESPIPES

CAPIS

SOCKETSSOCKETS//TLITLI

COMMUNICATIONCOMMUNICATION

SUBSYSTEMSUBSYSTEM

VIRTUAL MEMORYVIRTUAL MEMORY

SUBSYSTEMSUBSYSTEM

GENERAL POSIX AND WIN32 SERVICES

PROCESSPROCESS//THREADTHREAD

SUBSYSTEMSUBSYSTEM

FRAMEWORKS ACCEPTORACCEPTOR CONNECTORCONNECTOR

SELF-CONTAINED

DISTRIBUTED

SERVICE

COMPONENTS

NAMENAME

SERVERSERVER

TOKENTOKEN

SERVERSERVER

LOGGINGLOGGING

SERVERSERVER

GATEWAYGATEWAY

SERVERSERVER

SOCKSOCK__SAPSAP//TLITLI__SAPSAP

FIFOFIFO

SAPSAP

LOGLOG

MSGMSG

SERVICESERVICE

HANDLERHANDLER

TIMETIME

SERVERSERVER

C++WRAPPERS

SPIPESPIPE

SAPSAP

CORBACORBA

HANDLERHANDLER

SYSVSYSVWRAPPERSWRAPPERS

SHAREDSHARED

MALLOCMALLOC

THE ACE ORBTHE ACE ORB

((TAOTAO))

JAWS ADAPTIVEJAWS ADAPTIVE

WEB SERVERWEB SERVER

MIDDLEWARE

APPLICATIONS

REACTORREACTOR//PROACTORPROACTOR

PROCESSPROCESS//THREADTHREAD

MANAGERSMANAGERS

ADAPTIVE SERVICE EXECUTIVE ADAPTIVE SERVICE EXECUTIVE (ASX)(ASX)

SERVICESERVICE

CONFIGCONFIG--URATORURATOR

SYNCHSYNCH

WRAPPERSWRAPPERS

MEMMEM

MAPMAP

OS ADAPTATION LAYER

www.cs.wustl.edu/�schmidt/ACE.html

� ACE Overview– Concurrent OO

networkingframework

– Ported to C++and Java

– Runs on RTOSs,POSIX, andWin32

� Related work– x-Kernel– SysV STREAMS



Scope: Performance Optimizations in TAO

NETWORK

OS KERNEL

OS I/O SUBSYSTEM

NETWORK INTERFACES

ORBINTERFACE

ORBCORE

operation()

IDLSTUBS

OBJECT

ADAPTER

IDLSKELETON

in args

out args + return value

CLIENT

GIOPGIOP


CONCURRENCYCONCURRENCY

MODELSMODELS

TRANSPORTTRANSPORT

PROTOCOLSPROTOCOLS

I/OI/OSUBSYSTEMSUBSYSTEM

NETWORKNETWORK

ADAPTERADAPTER

PRESENTATIONPRESENTATION

LAYERLAYER

SCHEDULINGSCHEDULING,,DEMUXINGDEMUXING,, &&DISPATCHINGDISPATCHING

DATADATA

COPYING COPYING

CONNECTIONCONNECTION

MANAGEMENTMANAGEMENT

OS KERNELOS KERNEL





Problem: Providing QoS to CORBA Operations

RTRTOperationOperation

PERIODIC SCHEDULINGPERIODIC SCHEDULING//DISPATCHINGDISPATCHING

TT++PP

P:P: PERIOD PERIOD

C:C: REQUEST COMPUTATION TIME REQUEST COMPUTATION TIME

PP

CC CC

TIMETIME

TT TT++22PP

struct RT_Info {struct RT_Info { Time worstcase_exec_time_; Time worstcase_exec_time_; Period period_; Period period_; Criticality criticality_; Criticality criticality_; Importance importance_; Importance importance_;};};

� Design Challenges

– Specifying/enforcing QoSrequirements

– Focus on Operations upon Objects

� Rather than on communication channels orthreads/synchronization

– Support static and dynamic scheduling

� Solution Approach

– Servants publish resource (e.g., CPU)requirements and (periodic) deadlines

– Most clients are also servants



Solution: TAO’s Real-time Static Scheduling Service

RT_INFO

REPOSITORY

OFF-LINE

SCHEDULER

DEPENDS UPON =EXECUTES AFTER

4: ASSESS

SCHEDULABILITY

5: ASSIGN OS THREAD

PRIORITIES AND

DISPATCH QUEUE

ORDERING

SUBPRIORITIES

6: SUPPLY

PRIORITIES

TO ORB

3: POPULATE

RT_INFO

REPOSITORY

RUN-TIME

SCHEDULER

Priority/SubpriorityTable Per

Mode

MODE 0

MODE 1

MODE 2

MODE 3

CURRENT

MODE

SELECTOR

struct RT_Info { Time worstcase_exec_time_; Period period_; Criticality criticality_; Importance importance_;};

1: CONSTRUCT CALL

CHAINS OF RT_OPERATIONS

2: IDENTIFY THREADS

RT

Operation

RT

Operation

RT

Operation

I/O SUBSYSTEM

ORB CORE

OBJECT ADAPTER

www.cs.wustl.edu/�schmidt/TAO.ps.gz



TAO’s High-Performance, Real-time ORB Endsystem

RR

UU

NN

TT

II

MM

EE

S S

CC

HH

EE

DD

UU

LL

EE

RR

SOCKETSOCKET QUEUEQUEUE DEMUXERDEMUXER

ATM PORT INTERFACECONTROLLER (APIC)

ZZ

EE

RR

OO

CC

OO

PP

YY

BB

UU

FF

FF

EE

RR

SS

II//OOSUBSYSTEMSUBSYSTEM

OBJECTOBJECTADAPTERADAPTER

SERVANTSERVANT DEMUXERDEMUXER

CLIENTSCLIENTSSTUBS

SERVANTSSKELETONS

U

ORBORB CORECORE

REACTORREACTOR

(20 HZ)

REACTOR

(10 HZ)

REACTOR

(5 HZ)

REACTOR

(1 HZ)

� Solution Approach

– Integrate RT dispatcher intoORB endsystem

– Support multiple requestscheduling strategies

� e.g., RMS, EDF, and MUF– Requests ordered across

thread priorities by OSdispatcher

– Requests ordered withinpriorities based on datadependencies and importance



ORB Latency and Priority Inversion Experiments

��

C 1C 0

Requests

C n

��

Client

...

...

2ATM Switch

Ultra 2 Ultra 2

I/O SUBSYSTEM

Server

Object Adapter

ORB Core

Servants RU

NT

IME

SCH

ED

UL

ER

www.cs.wustl.edu/�schmidt/RT-perf.ps.gz

� Vary ORBs, hold OSconstant

� Solaris real-time threads

� High priority client C0

connects to servant S0

with matching priorities� Clients C1 : : : Cn have

same lower priority

� Clients C1 : : : Cn

connect to servant S1

� Clients invoke twowayCORBA calls that cube anumber on the servantand returns result



ORB Latency and Priority Inversion Results

0

4

8

12

16

20

24

28

32

36

40

44

48

52

1 5 10 15 20 25 30 35 40 45 50

Number of Low Priority Clients

Late

ncy p

er

Tw

o-w

ay R

eq

uest

in M

illiseco

nd

s

CORBAplus High Priority CORBAplus Low Priority

MT-ORBIX High Priority MT-ORBIX Low Priority

miniCOOL High Priority miniCOOL Low Priority

TAO High Priority TAO Low Priority

� Synopsis of results

– TAO’s latency is lowest for large# of clients

– TAO avoids priority inversion

� i.e., high priority clientalways has lowest latency

– Primary overhead stems fromconcurrency and connectionarchitecture

� e.g., synchronization andcontext switching



ORB Jitter Results

1 5 10 15 20 25 30 35 40 45 50

TAO High Priority

TAO Low Priority

miniCOOL High Priority

miniCOOL Low Priority

MT-ORBIX High Priority

MT-ORBIX Low Priority

CORBAplus High Priority

CORBAplus Low Priority

0

50

100

150

200

250

300

Jitt

er in

mill

isec

on

ds


� Definition

– Standard deviationfrom averagelatency

� Synopsis ofresults

– TAO’s jitter islowest and mostconsistent

– CORBAplus’ jitteris highest andmost variable



Problem: Improper ORB Concurrency Model

OBJECTOBJECTADAPTERADAPTER

SERVANTSERVANT DEMUXERDEMUXER

SERVANTSERVANTSKELETONSSKELETONS

U

ORBORB CORECORE

FILTERFILTER

FILTERFILTER

FILTERFILTER

SERVANTSERVANTSKELETONSSKELETONS

U

2: enqueue(data)2: enqueue(data)

3: dequeue,3: dequeue,filterfilter

request,request,&enqueue&enqueue

4: dispatch4: dispatchupcall()upcall()

II//OO SUBSYSTEMSUBSYSTEM

THREADTHREAD

FILTERFILTER

1: recv()1: recv()

CONNECTION THREADSCONNECTION THREADS

� Common Problems

– High overhead

� Context switching

� Synchronization– Thread-level priority

inversions

� FIFO request queueing

� Improper thread priorities– Lack of application control

over concurrency model



Problem: ORB Shared Connection Model

SERVERSERVERORBORB CORECORE



COMMUNICATIONCOMMUNICATION LINKLINK


SERVANTSSERVANTS

ONEONE TCPTCP

CONNECTIONCONNECTION

ORBORB CORECORE

SEMAPHORESSEMAPHORES

2: select()2: select()4: release()

3: read()

BO

RR

OW

ED

TH

RE

AD

BO

RR

OW

ED

TH

RE

AD

S

APPLICATION

5: dispatch_return()

1: invoke_twoway()

� Common Problems

– Request-levelpriority inversions

� Sharing multiplepriorities on asingle connection

– Complexconnectionmultiplexing

– Synchronizationoverhead



Problem: High Locking Overhead

40

94

199

175

32

231216

599

0

100

200

300

400

500

600

700

TAO miniCOOL CORBAplus MT ORBIX

ORBs Tested

Use

r L

evel

Lo

ck O

per

atio

ns

per

Req

ues

t

client server

� Locking overheadsignificantly affects latencyand jitter

– Memory managementcommonly involveslocking

� RT ORBs should minimizeor eliminate all lockingoperations

� TAO is carefully designed tominimize locking andmemory allocation



Solution: TAO’s Inter-ORB Connection Topology

CLIENTCLIENT ORBORB CORECORE

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

SERVERSERVER ORBORB CORECORE

REACTORREACTOR

(20 (20 HZHZ))

REACTORREACTOR

(10 (10 HZHZ))

REACTORREACTOR

(5 (5 HZHZ))

REACTORREACTOR

(1 (1 HZHZ))

CC

OO

NN

NN

EE

CC

TT

22

AA

CC

CC

EE

PP

TT

OO

RR

CC

OO

NN

NN

EE

CC

TT

11

CC

OO

NN

NN

EE

CC

TT

33

II//OO SUBSYSTEMSUBSYSTEMI/O SUBSYSTEM

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

COMMUNICATION LINK

CLIENT APPLICATION

STUB STUB STUB

www.cs.wustl.edu/�schmidt/RT-middleware.ps.gz



Real-time OS/ORB Performance Experiments

[P ]0

[P ]1

SCH

ED

UL

ER

0

RU

NT

IME

[P ]

I/O SUBSYSTEM

Server

0 nS1

nC

��Pentium Pro

S S0C 1C

...

...

Object AdapterServants

ORB Core

Client

...

[P]

Requests

Priority

...

[P ][P ]1

[P ]

n

n

www.cs.wustl.edu/�schmidt/RT-OS.ps.gz

� Vary OS, hold ORBs constant

� Single-processor IntelPentium Pro 200 Mhz, 128Mbytes of RAM

� Client and servant run on thesame machine

� Client Ci connects to servant

Si with priority Pi

– i ranges from 1 : : : 50

� Clients invoke twowayCORBA calls that cube anumber on the servant andreturns result



Real-time OS/ORB Performance Results

0

1

2

3

4

5

6

7

8

9

1 5 10 15 20 25 30 35 40 45 50


La

ten

cy

pe

r T

wo

-wa

y R

eq

ue

st

in M

illi

se

co

nd

s

VxWorks High Priority VxWorks Low Priority

Windows NT High Priority Windows NT Low Priority

Solaris x86 High Priority Solaris x86 Low Priority

LynxOS High Priority LynxOS Low Priority

� Synopsis of results

– LynxOS yielded very goodlatency and deterministicbehavior

– Erratic behavior and highlatency are a problem forWindows NT

– Windows NT also showedpriority inversion at 50 lowpriority clients

– VxWorks performssurprisingly erratically

– Solaris’ latency is high butpredictable



Real-time OS/ORB Jitter Results

15

1015

2025

3035

4045

50

LynxOS High PriorityLynxOS Low Priority

VxWorks High PriorityVxWorks Low Priority

Solaris x86 High PrioritySolaris x86 Low Priority

Windows NT High PriorityWindows NT Low Priority

0

1

2

3

4

5

6

Jitt

er in

mill

isec

on

ds


� Definition

– Standard deviationfrom averagelatency

� Synopsis ofresults

– Some RTOS’sprovide lowjitter

– ORB (TAO)doesn’tintroduce jitter



Problem: Reducing Demultiplexing Latency

2:2: DEMUX TO DEMUX TO

I/OI/O HANDLE HANDLE

OP

ER

AT

ION

OP

ER

AT

ION

KK

OP

ER

AT

ION

OP

ER

AT

ION

22.........

OP

ER

AT

ION

OP

ER

AT

ION

11

.........

.........IDL

SKEL 1IDLIDL

SKEL SKEL 22IDLIDL

SKEL SKEL MM

OS KERNELOS KERNEL


NETWORK ADAPTERSNETWORK ADAPTERS

SERVANT SERVANT 11 SERVANT SERVANT 22 SERVANT SERVANT NN


SKELETON SKELETON


OPERATION OPERATION

1:1: DEMUX THRU DEMUX THRU

PROTOCOL STACK PROTOCOL STACK


SERVANT SERVANT

LAYERED

DEMUXING

ORB COREORB CORE

OBJECT ADAPTER


OBJECT ADAPTER OBJECT ADAPTER

� Design Challenges

– Minimize demuxinglayers

– Provide O(1)

operation demuxing– Avoid priority

inversions– Remain

CORBA-compliant



Solution: Demultiplexing Optimizations

.........

.........IDLIDL

SKEL SKEL 22

OBJECT ADAPTER

SERVANT SERVANT 500500

(A)(A) LAYERED DEMUXING LAYERED DEMUXING,,LINEAR SEARCHLINEAR SEARCH

SERVANT SERVANT 11 SERVANT SERVANT 22

IDLIDL

SKEL SKEL 11

OP

ER

AT

ION

OP

ER

AT

ION

100

100

OP

ER

AT

ION

OP

ER

AT

ION

22

.........

OP

ER

AT

ION

OP

ER

AT

ION

11

IDLIDL

SKEL NSKEL N

... ..................

SE

RV

AN

TS

ER

VA

NT500::

500::

OP

ER

AT

ION

OP

ER

AT

ION

100

100

SE

RV

AN

TS

ER

VA

NT500::

500::

OP

ER

AT

ION

OP

ER

AT

ION

11

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

100

100

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

22

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

11

OBJECT ADAPTER

.........

.........IDLIDL

SKEL SKEL 22

OBJECT ADAPTER

(C) LAYERED DEMUXING,PERFECT HASHING

SERVANT SERVANT 11 SERVANT SERVANT 22

OP

ER

AT

ION

OP

ER

AT

ION

100

100

OP

ER

AT

ION

OP

ER

AT

ION

22

.........

OP

ER

AT

ION

OP

ER

AT

ION

11

IDLIDL

SKEL NSKEL N

search(object key)

hash(operation)

IDLIDL

SKEL SKEL 11

(D) DE-LAYERED ACTIVE DEMUXING

hash(object key)

search(operation)

index(object key/operation)

(B) LAYERED DEMUXING,DYNAMIC HASHING

SERVANT SERVANT 500500

� Results at www.cs.wustl.edu/�schmidt/ieee tc-97.ps.gz

� Linear search based on Orbix demuxing strategy

� Perfect hashing based on GNU gperf

– www.cs.wustl.edu/�schmidt/gperf.ps.gz



Demultiplexing Performance Results

1100200300400500

Act

ive

Dem

ux (

1 M

etho

d)

Act

ive

Dem

ux (

10 M

etho

ds)

Act

ive

Dem

ux (

100

Met

hods

)

GP

ER

F (

1 M

etho

d)

GP

ER

F (

10 M

etho

ds)

GP

ER

F (

100

Met

hods

)

Dyn

amic

Has

h (1

Met

hod)

Dyn

amic

Has

h (1

0 M

etho

ds)

Dyn

amic

Has

h (1

00 M

etho

ds)

Line

ar (

1 m

etho

d)

Line

ar (

10 m

etho

ds)

Line

ar (

100

met

hods

)

0

20

40

60

80

100

120

140

Lat

ency

in m

icro

seco

nd

s

Number of Objects

Demultiplexing scheme

� Synopsis

– Linear search is fartoo costly

– Dynamic hashing canbe unstable

– gperf solution is100% compatible, butstatic

– Optimal activedemuxing may not be100% compatible, butis dynamic

– Strategy patternfacilitates flexibility



Next Steps: Integrating TAO with ATM I/O Subsystem

REACTORREACTOR

(20 (20 HZHZ))

REACTORREACTOR

(10 (10 HZHZ))

REACTORREACTOR

(5 (5 HZHZ))

REACTORREACTOR

(1 (1 HZHZ))

ORBORB CORECORE

APICAPIC ATMATM DRIVERDRIVER

II//OOSUBSYSTEMSUBSYSTEM

PERPER--VCVC

SOCKETSOCKET

QUEUESQUEUES

APICAPIC PACINGPACING

QUEUESQUEUES

ZZ

EE

RR

OO

CC

OO

PP

YY

BB

UU

FF

FF

EE

RR

SS

� Key Features

– Vertical integration of QoSthrough ORB, OS, and ATMnetwork

– Real-time I/O enhancementsto Solaris kernel

– Provides rate-based QoSend-to-end

– Leverages APIC features forcell pacing and zero-copybuffering



Next Steps: Strategized Scheduling ServiceFramework

ssttrruucctt RRTT__IInnffoo {{ wwcc__eexxeecc__ttiimmee__;; ppeerr iioodd__;; ccrr iittiiccaalliittyy__;; iimmppoorr ttaannccee__;; ddeeppeennddeenncciieess__;; }};;

SSCCHHEEDDUULLIINNGG

SSTTRRAATTEEGGYY

RRTT__IINNFFOO

RREEPPOOSSII TTOORRYY

OOFFFF--LL II NNEE

SSTTRRAATTEEGGIIZZEEDD

SSCCHHEEDDUULLEERR

OOFFFF--LLIINNEE

OONN--LLIINNEE

RRTT__IINNFFOO

RREEPPOOSSII TTOORRYY

RRUUNN--TTIIMMEE

SSCCHHEEDDUULLEERR

11.. SSPPEECCIIFFYY RRTT__OOPPEERRAATTIIOONN

CCHHAARRAACCTTEERRIISSTTIICCSS AANNDD

DDEEPPEENNDDEENNCCIIEESS

33.. AASSSSEESSSS SSCCHHEEDDUULLAABBIILL IITTYY

44.. AASSSSII GGNN SSTTAATTIICC PPRRIIOORRIITTYY AANNDD SSTTAATTIICC SSUUBBPPRRIIOORRIITTYY

55.. MMAAPP SSTTAATTIICC PPRRIIOORRIITTYY,, DDYYNNAAMMII CC SSUUBBPPRRII OORRII TTYY,, AANNDD

SSTTAATTIICC SSUUBBPPRRIIOORRIITTYY II NNTTOO DDIISSPPAATTCCHHIINNGG PPRRIIOORRIITTYY

AANNDD DDIISSPPAATTCCHHIINNGG SSUUBBPPRRIIOORRIITTYY

66.. AASSSSIIGGNN DDIISSPPAATTCCHHIINNGG QQUUEEUUEE CCOONNFFIIGGUURRAATTIIOONN

22.. PPOOPPUULLAATTEE

RRTT__IINNFFOO

RREEPPOOSSIITTOORRYY

77.. SSUUPPPPLLYY DDIISSPPAATTCCHHIINNGG QQUUEEUUEE

CCOONNFFIIGGUURRAATTIIOONN TTOO TTHHEE OORRBB

RRTTOOppeerraattiioonn



II //OO SSUUBBSSYYSSTTEEMM

OORRBB CCOORREE

OOBBJJEECCTT AADDAAPPTTEERR

99.. SSUUPPPPLLYY SSTTAATTIICC PPOORRTTIIOONNSS OOFF

DDIISSPPAATTCCHHIINNGG PPRRIIOORRIITTYY AANNDD

DDIISSPPAATTCCHHIINNGG SSUUBBPPRRIIOORRIITTYY

TTOO TTHHEE OORRBB

((SSCCHHEEDDUULLEERR''SS OOUUTTPPUUTT

IINNTTEERRFFAACCEE))

((SSCCHHEEDDUULLEERR''SS IINNPPUUTT

IINNTTEERRFFAACCEE))

88.. CCOONNFFIIGGUURREE QQUUEEUUEESS BBAASSEEDD

OONN DDIISSPPAATTCCHHIINNGG QQUUEEUUEE

CCOONNFFIIGGUURRAATTIIOONN

1100.. DDYYNNAAMMIICC QQUUEEUUEESS AASSSSIIGGNN

DDYYNNAAMMIICC PPOORRTTIIOONNSS OOFF

DDIISSPPAATTCCHHIINNGG SSUUBBPPRRIIOORRIITTYY

((AANNDD PPOOSSSSIIBBLLYY

DDIISSPPAATTCCHHIINNGG PPRRIIOORRIITTYY)) OORRBB EENNDDSSYYSSTTEEMM

www.cs.wustl.edu/�schmidt/dynamic.ps.gz



Principles for High-Performance, Real-time ORBs

� Avoid dynamic connection management

� Minimize dynamic memory managementand data copying

� Avoid multiplexing connections fordifferent priority threads

� Avoid complex concurrency models

� Integrate ORB with OS and I/Osubsystem and avoid reimplementingOS mechanisms

� Guide ORB design by empiricalbenchmarks

'&

$%'

&

$%



TAO Project Research Summary

� Current focus: real-time ORBs

– Developed first deployed real-time CORBA scheduling service andfirst POA

– Minimized ORB Core priority inversion and non-determinism– Reduced end-to-end latency via demuxing optimizations– Applied optimizations to IIOP protocol engine– Co-submitters to OMG’s real-time CORBA RFP

� Future work

– Dynamic and hybrid scheduling of CORBA operations– Distributed QoS and integration with real-time ATM I/O Subsystem– Optimizing IDL compiler– Technology transfer with DARPA Quorum program



Web URLs for Additional Information

� These slides:www.cs.wustl.edu/ �schmidt/PDF/tutorial4.ps.gz

� More information on TAO: www.cs.wustl.edu/ �schmidt/RT-ORB.ps.gz

� TAO Event Channel: www.cs.wustl.edu/ �schmidt/JSAC-98.ps.gz

� TAO static scheduling: www.cs.wustl.edu/ �schmidt/TAO.ps.gz

� TAO dynamic scheduling:www.cs.wustl.edu/ �schmidt/dynamic.ps.gz

� ORB Endsystem Architecture:www.cs.wustl.edu/ �schmidt/RT-middleware.ps.gz



Web URLs for Additional Information (cont’d)

� Performance Measurements:

– Demuxing latency: www.cs.wustl.edu/ �schmidt/GLOBECOM-97.ps.gz

– SII throughput: www.cs.wustl.edu/ �schmidt/SIGCOMM-96.ps.gz

– DII throughput: www.cs.wustl.edu/ �schmidt/GLOBECOM-96.ps.gz

– Latency, scalability: www.cs.wustl.edu/ �schmidt/ICDCS-97.ps.gz

– IIOP optimizations: www.cs.wustl.edu/ �schmidt/JSAC-99.ps.gz

� More detail on CORBA: www.cs.wustl.edu/ �schmidt/corba.html

� ADAPTIVE Communication Environment (ACE):www.cs.wustl.edu/ �schmidt/ACE.html

� The ACE ORB (TAO):www.cs.wustl.edu/ �schmidt/TAO.html


High-performance and Real-time CORBAschmidt/PDF/tutorial.pdf · High-performance and Real-time...

Documents

Transcript of High-performance and Real-time CORBAschmidt/PDF/tutorial.pdf · High-performance and Real-time...