ARMADA Middleware and Communication Services T. ABDELZAHER, M. BJORKLUND, S. DAWSON, W.-C. FENG, F. JAHANIAN, S. JOHNSON, P. MARRON, A. MEHRA, T. MITTON, A. SHAIKH, K. SHIN, Z. WANG, H. ZOU Real-Time Computing Laboratory University of Michigan Presented by Guoliang
ARMADA Middleware and Communication Services. T. ABDELZAHER, M. BJORKLUND, S. DAWSON, W.-C. FENG, F. JAHANIAN, S. JOHNSON, P. MARRON, A. MEHRA, T. MITTON, A. SHAIKH, K. SHIN, Z. WANG, H. ZOU Real-Time Computing Laboratory University of Michigan Presented by Guoliang Xing. Agenda. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ARMADA Middleware and Communication Services
T. ABDELZAHER, M. BJORKLUND, S. DAWSON, W.-C. FENG, F. JAHANIAN, S. JOHNSON, P. MARRON, A. MEHRA, T. MITTON, A. SHAIKH, K. SHIN, Z. WANG, H. ZOU
Real-Time Computing Laboratory
University of MichiganPresented by Guoliang Xing
Agenda
Introduction RTCAST Group Comm. Service Real-Time Channel Architecture Platforms RTPB Replication Service Evaluation Tools
Target Applications
Embedded fault-tolerant applications
Industrial and manufacturing systems
Distributed multimedia Air traffic control
Key Challenges Timely delivery of services with end-to-
end real-time constraints Dependability of services in the presence
of h/s failures Scalability of computation and
communication resources Exploitation of open systems and
emerging standards in operating systems and communication services
ARMADA Architecture
Applications
MiddlewareServices
EvaluationTools
API
Real-TimeChannels
Microkernel
RTCAST Multicast comm. and group management
in timely fashion, with faults
Group Communication
Reliable message delivery Agreement on group membership Failure detection and handling Consistency
Atomicity: either everybody gets the message or nobody gets it
Global order
Real-time Group Comm.
Late message means failure Atomic, ordered message delivery
in timely fashion Immediate message delivery
without compromising the above
Achieve reliability, atomicity, RT
Reliability: each member either receives a multicast message m or crashes before receiving m
Atomicity: correct members receive all message and in the same order
Time-bounded multicast: each member either receives each multicast m in total order within T time units or crashes during T before receiving m
RTCAST - ArchitectureReal-time Process Groups API
Clock Synchronization Virtual Network Interface
Unicast Datagram Communication
Admission Control andSchedulability Analysis
Group MembershipService
Timed Atomic Multicast
System Model Assumptions:
each processor has its own unique identifier a path exists between any two processors communication delay is bounded (in the
absence of failures) synchronized clocks
Failures processors may suffer performance or crash
failures messages may suffer performance or
omission failures
Agreement on membership
All members have the same membership view at group initialization time
For each membership update U which changes membership view from V to V’, U is delivered atomically (in order) to all members in V U V’ within T time units
Steady-state operation
Steady-state operation Token Ring: ensure order
A processor sends messages only after holds token
Upon receiving the token sends multicast messages within maximum
token hold time sends a heartbeat which is a token to
successor Upon receiving a multicast message
deliver to application in sequence if message omission detected, crash
Steady-state operation– contd.
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
Handle faults
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
1
2
3
4
1 3 4
1 2 3 4
1 3 4
1 3 4
1
2
3
4
Membership Changes Processor crashes
Each processor checks the heartbeats from members when its turn comes
Send membership update multicast Joins
Sends a join request to some processor which multicasts membership change message
Joining processor checks the consistence of membership views sent in ACKs
Token Rotation Period
Ptoken – Token rotation time Ti – maximum token hold time at any
processor n – number of processes dmax – comm. delay
Admission Control
Goal: Only admit affordable messages
Assumptions: Each sender can transmit messages
for up to Tj units of time within P Time elapsed between the send and
delivery is bounded by Δ
Admission Control – Contd. Real-time message: Maximum
transmission time Ci, period Pi, deadline di
Sufficient Schedulability Condition:
Implementation
Agenda
Introduction RTCAST Group Comm. Service Real-Time Comm. Architecture Platforms RTPB Replication Service Evaluation Tools Conclusion
RT Channel Architecture
RT Comm. Architecture – Contd.
Real-time channel: unicast virtual connection between two hosts with bounded end-to-end delay guarantee RTC API: Clip: endpoint with QoS parameters RTCOP: Signaling and resource reservation QoS model & Admission control: