Middleware Support for Aperiodic Tasks in Distributed Real-Time Systems

Transcription

1 Outline Middleware Support for Aperiodic Tasks in Distributed Real-Time Systems Yuanfang Zhang, Chenyang Lu and Chris Gill Department of Computer Science and Engineering Washington University in St. Louis Patrick Lardieri and Gautam Thaker Advanced Technology Laboratories Lockheed Martin Problem Integrated middleware architecture Admission control service Deferrable server mechanism Empirical evaluation Conclusions This work was supported in part by the DARPA Adaptive and Reactive Middleware Systems (ARMS) program (contract NBCHC0040) and NSF CAREER award CNS Approved for public release. Distribution unlimited. 2 Motivating s Aperiodic s in many mission-critical distributed real-time applications have hard end-to-end deadlines are critical to the system Examples Fire detection Target detection Alert! Displaying temperature Processing data Collecting data Sensing temperature T -T>20F! Gap between Theory and Middleware Theoretical techniques exist for aperiodic scheduling Aperiodic Utilization Bound () [Abdelzaher, 2004] Aperiodic Servers: Polling Server [Sha 986] Deferrable Server [Strosnider 995] Priority Exchange [Lehoczky 987] Sporadic Server [Sprunt 989] Slack Stealing [Lehoczky 992] Existing middleware lacks support for real-time aperiodic s Lack scheduling mechanism Lack online admission control 4 Contributions: Integrated middleware architecture within TAO s federated event channel End-to-end scheduling service for aperiodic/periodic s Online admission control service Support two alternative approaches: Aperiodic Utilization Bound () Deferrable Server (DS) Aperiodic Utilization Bound: Theory End-to-end Task T i D i : End-to-end deadline C ij : Sub execution time on node j Aperiodic or periodic Current job set S(t) Jobs that have arrived but whose deadlines have not expired Note: A job may still be current after completion Synthetic utilization of processor j: U(t)= ij j Ti S(t) Di Resetting rule: when a processor becomes idle, the contribution of all completed aperiodic jobs to the processor s synthetic utilization is removed C 5 6 Washington University in St. Louis

2 Utilization Bounds for End-to-End Aperiodic Tasks Example Under end-to-end deadline monotonic scheduling, all endto-end deadlines are met if U(-U/2) N j j j= -Uj For arbitrary graphs 2 4 U (- U /2) U(-U/2) j j U 4(- U 4/2) +max + -U j=2, -Uj -U4 U = =0.4, U 2 = =0.25, U =max{0.06, 0., 0.}=0. U(-U/2) = 0.9 j j j= -Uj 7 8 TAO s Federated Event Channel Event Channel () dispatches events locally according to their priorities. Gateway forwards events to remote processors. Admission Control Service accept accept? update util sched. analysis Checker Y N Aperiodic Timer Queue Waiting Queue not accepted Admission Controller Round trip delay <.4 ms Considered in schedulability analysis T, Gate way Processor T,2 T, Processor 2 Gate way Processor 9 send request arrives Waiting Queue T, Processor Idle Detector accept remove idle report reject Processor 2 release set timer timer fires T,2 T, Processor 0 Design Decisions Critical Tasks Send an event to notify the central admission controller Hold the in a waiting queue and waits for the reply Noncritical Tasks AC may eject noncritical periodic s when new critical ones arrive (criticality-awareness admission policy) Aperiodic Tasks Update the synthetic utilization when an aperiodic job is released or reaches its deadline When the CPU is idle, idle detector reports the completed aperiodic jobs to AC (resetting rule) Periodic Tasks Do not update synthetic utilization at every release or deadline of a periodic job. Deferrable Server: Theory A periodic server executes all aperiodic s Budget: maximum time the server can run in a period Bound aperiodic s impact on periodic s Algorithm Server is suspended when its budget runs out or there are no pending aperiodic events Server s budget is replenished at the end of each period Requires new run-time scheduling mechanism Schedulability Analysis worst case end-to-end response time <= end-to-end deadline 2 Washington University in St. Louis 2

3 Deferrable Server: Middleware Mechanism First middleware implementation of bandwidth preserving server Server processes aperiodic events (2nd highest priority) Budget manager manages the budget and controls the execution of server s (highest priority) High Priority Low Priority < 89 us per Replenish Timer Budget server period Manager ACE Timer Queue Aperiodic Events Budget Exhausted Timer Periodic Events Periodic Events Server Dispatching Dispatching < 58 us per aperiodic job Experimental Platforms Task Set One set contains 4 aperiodic s and 5 periodic s Randomly generate 60 sets with synthetic utilization of 0., 0.4, 0.5 and 0.6, respectively Testbed ron.cse 00Mbps Ethernet switch norbert.cse Pentium4 2.5GHz hermoine.cse Pentium4 2.80GHz Pentium4 2.80GHz harry.cse Pentium4 2.5GHz 4 Comparison of and DS Acceptance ratio Synthetic utilization per processor Resetting mechanism is effective DS and are comparable DS requires more complex run-time mechanism without Reset DS Impact of Criticality or DS: do not eject noncritical s to accept new critical s or DS with Criticality: eject noncritical s to accept new critical s Acceptance ratio 0.8 with 0.6 Criticality 0.4 DS 0.2 DS with Criticality Synthetic utilization per processor 6 Critical Tasks (4 aperiodic s and 2 periodic s) with criticality is more effective than DS for critical s 5 6 Conclusions Integrated middleware architecture for real-time end-to-end aperiodic/period s Admission control service Aperiodic Utilization Bound () Deferrable Server (DS) Scheduling service: DS on top of priority-based OS Integration with TAO s federated event channel Empirical results DS is highly efficient at the middleware level Admission control incurs acceptable delays is comparable to DS while requiring simpler run-time mechanisms Reading Required: Y. Zhang, C. Lu, C. Gill, P. Lardieri and G. Thaker, Middleware Support for Aperiodic Tasks in Distributed Real-Time Systems, IEEE Real- Time and Embedded Technology and s Symposium (RTAS'07), April Washington University in St. Louis

4 Chenyang Lu Common Object Request Broker Architecture (CORBA) Real-Time Object Request Broker Middleware CORBA specifications OMG is the standards body Over 800 companies CORBA defines interfaces, not implementations Object Request Brokers (ORB) allow clients to invoke operations on distributed objects transparently from Object location Programming language Operating System Communication protocols and interconnect Hardware 2 CORBA Reference Model Stubs and Skeletons Client invokes operations on objects. An Object includes An interface specified by an Interface Definition Language (IDL) Servant(s) that implements the IDL interface Translate between platform-dependent data formats and a common data representation. Generated by an IDL compiler based on the IDL interface. Ensure platform/language transparency. 4 ORB Core Object Adapter Deliver requests to objects and responses to clients Communicate using a General Inter-ORB Protocol (GIOP) e.g., Internet Inter-ORB Protocol (IIOP) on TCP Typically a run-time library linked to applications Demultiplexes each incoming request to the right servant/operation Make the upcall to the operation 5 6 Real-Time Middleware

5 Chenyang Lu Limitations of CORBA Lacks real-time specification interfaces to applications s cannot specify rate, deadline, and importance Lacks real-time enforcement Does not map specification to priorities of s Contains significant priority inversion Lacks performance optimization Poor worst-case and average latency Latencies and Priority Inversions 7 8 The ACE ORB (TAO) norb: A Small-footprint ORB Open-source Real-Time CORBA >>,000,000 SLOC 00+ person years of effort Pioneered R&D on DRE middleware design & optimizations norb Server Worker Conn. CORBA Objects T: 2 Hz T2: 2 Hz Client Timer Priority queues Conn. Source: D.C. Schmidt, 9 Operation Request Lanes 0 Real-Time Middleware 2