On Decentralized Proactive Resource Allocation in Asynchronous

On Decentralized Proactive Resource Allocation in Asynchronous Real-Time Distributed Systems Tamir Hegazy Dept. of Electrical and Computer Engineering Georgia Institute of Technology E-mail: [email protected]

Binoy Ravindran Real-Time Systems Laboratory Bradley Dept. of Electrical and Computer Engineering Virginia Tech, Blacksburg, VA 24061 Phone: 540-231-3777, E-mail: [email protected]

Abstract We present two classes of distributed algorithms called DRBA and DOBA, for decentralized, proactive resource allocation in asynchronous real-time distributed systems. The objective of the algorithms is to maximize aggregate application benefit and deadlinesatisfied ratio for an user-specified future time interval. Since determining the optimal allocation is computationally intractable, the algorithms heuristically compute near-optimal allocations in polynomial-time. While the DRBA algorithms analyze subtask response times to determine allocation decisions, which are computationally expensive, the DOBA algorithms analyze processor overloads to compute their decisions in a much faster way. Within each class, we present three algorithms that differ in the way they tolerate end-host failures: no reallocation upon failure, stateless reallocation, and stateful reallocation.

1. Introduction Asynchronous real-time distributed systems are emerging in many domains including defense, telecommunication, and industrial automation for the purpose of strategic mission management [9]. Such systems are fundamentally distinguished by the significant runtime uncertainties that are inherent in their application environment and system resource states [9, 11, 7]. Consequently, it is difficult to postulate upper bounds on application workloads for such systems that will always be respected at run-time. Thus, they violate the deterministic foundations of hard real-time theory that ensures that all timing constraints are always satisfied under deterministic postulations of application workloads and execution environment characteristics.

To deal with such non-determinism’s, recent advances in real-time and distributed systems research [2] have produced quality of service (QoS) technologies that allow applications to specify and negotiate realtime requirements. The real-time QoS techniques consider application models where applications can operate at multiple, discrete “levels” of service. A level is a strategy for doing an applications’ work and is characterized by resource usages such as CPU and network utilization and a QoS dimension such as timeliness of computations. Thus, if all timing requirements of all applications cannot be satisfied at run-time, then an adaptation mechanism can determine the “right level” of QoS to optimize a system-wide criteria. Examples of such real-time QoS techniques are presented in [6]. In this paper, we advance the real-time QoS technology by presenting two classes of distributed algorithms called Distributed Response Time AnalysisBased Best-Effort Resource Allocation (or DRBA) and Distributed Overload Analysis-Based Best-Effort Resource Allocation (or DOBA). DRBA and DOBA consider an application model where timeliness requirements of trans-node application tasks are expressed using Jensen’s benefit functions [7]. Further, the algorithms use adaptation functions, a concept that we presented in [4], for describing the anticipated application workload during future time intervals. Furthermore, the algorithms consider an adaptation model where application subtasks are dynamically replicated for sharing workload increases. Given such models, the objective of the algorithms is to maximize the aggregate application benefit and deadline-satisfied ratio during an user-specified future time window. Since this problem can be shown to be NP-hard [4], DRBA and DOBA heuristically compute their resource allocation decisions in polynomial-time. DRBA and DOBA build upon the RBA∗ and OBA

Proceedings of the 7th IEEE International Symposium on High Assurance Systems Engineering (HASE’02) 1530-2059/02 $17.00 © 2002 IEEE

algorithms that we presented in [4], respectively. While the DRBA class of algorithms analyze response times of application subtasks to compute resource allocations, similar to RBA∗ , the DOBA class of algorithms analyze processor overload situations to compute their allocation decisions, similar to OBA. However, DRBA and DOBA overcome two fundamental limitations of RBA∗ and OBA — scalability and fault-tolerance. The fact that RBA∗ and OBA are centralized algorithms (naturally) made them relatively less scalable for large-scale networks, besides becoming single points of failure. DRBA and DOBA overcome the limitations of RBA∗ and OBA by decentralizing their decision making process, resulting in one order of magnitude improvement in their computational costs. Furthermore, we present DRBA and DOBA algorithms that are designed to tolerate failures while computing resource allocation decisions, thereby overcoming the single-point-of-failure drawback of RBA∗ and OBA. We present three algorithms in each class: NR (no reallocation), SLR (stateless reallocation), and SFR (stateful reallocation). The algorithms vary in the way they tolerate end-host failures. We show that DOBA is faster than DRBA and the SFR algorithms are faster than the SLR algorithms by orders of magnitude. Further, our experimental results reveal that DOBA performs just about the same as that of DRBA. Furthermore, under end-host failures, the SFR algorithms perform almost the same as that of the SLR algorithms. Thus, the major contribution of the paper is the DRBA and DOBA classes of algorithms that perform decentralized, proactive resource allocation in asynchronous real-time distributed systems. The rest of the paper is organized as follows: Section 2 presents our application, adaptation, failure, and system models. Section 3 discusses the DRBA class of algorithms and Section 4 presents the DOBA class of algorithms. Experimental evaluation of the algorithms is discussed in Section 5. Finally, the paper concludes in Section 6.

2. The Application, Adaptation, System, and Failure Models 2.1. Application Model We denote the set of tasks in the application by Ti ∈ T, i ∈ [1, z], where a task can be either periodic or aperiodic. Each aperiodic task Tj has a “triggering” periodic task Tk that triggers its execution. After a periodic task Tk completes its execution, it may gen-

erate zero or more number of events that trigger the execution of the corresponding aperiodic task Tj . The period of a task Ti is denoted as period (Ti ), if Ti is periodic. If Ti is aperiodic, period (Ti ) denotes the period of the periodic task that triggers task Ti . The periods of periodic tasks need not be the same and can be different for different tasks. Each task Ti is assumed to consist of a set of subtasks (executable programs), which execute in a “serial” fashion. We use the notation Ti = [sti1 , mi1 , sti2 , mi2 , . . . , stin , min ] to represent a task Ti that consists of n subtasks and n messages to be executed and transmitted in series, respectively. i.e., stki (i > 1) cannot execute before message mki−1 arrives.

Benefit of task Ti

6 Bi (θ)

Time θ

Figure 1. A Benefit Function We use Jensen’s benefit functions for expressing application timeliness requirements [7] and assume “step” benefit functions for all tasks such as the one shown in Figure 1. Thus, completing a task anytime before its deadline will result in uniform benefit; completing it after the deadline will result in zero benefit. We model the workload of a subtask and that of a message as the number of data objects that they need to process and transmit, respectively. Our motivation for this is due to the fact that the number of sensor reports and aperiodic events (or “data objects”) processed and transmitted by subtasks and messages, respectively, constitute the most significant part of the application workload in many asynchronous real-time distributed systems such as [16]. We assume that application-profile functions that can estimate subtask execution times as a function of data objects are available. The profile functions can be determined by application profiling and measurement as described in [3].

2.2. Adaptation Model We assume an adaptation model for the application where subtasks of tasks can be replicated at run-time.


The idea behind replication of subtasks is that once a subtask is replicated, replicas of the subtask can share the workload that was processed by the original subtask. Furthermore, concurrency can be exploited by executing the replicas on different processors and thereby the end-to-end task response time can be reduced. For simplicity in the design of the application, we assume that the workload of a subtask is equally distributed among all its replicas.

Workload of task Ti

6

Ai (θ)

-

protocol [5]. Thus, packets of application messages are scheduled using non-preemptive EDF. The set of end-host processors is denoted by pi ∈ P R, i ∈ [1, m]. We assume that the processor clocks are synchronized using a protocol such as [13]. For process scheduling and resource access control, we consider the DASA real-time scheduling algorithm [1] that explicitly incorporates benefit functions for scheduling. Our choice of DASA is due to the fact that it outperforms EDF during overloaded situations, and performs the same as EDF during under-loaded situations where EDF is optimal. Furthermore, variants of DASA are available in kernel implementations including Alpha [8], MK7.3 [17], and real-time Linux [12]. We assume a fail-stop model for the end-hosts. Furthermore, we assume that hosts may fail arbitrarily.

3. The DRBA Class of Algorithms

Time θ

3.1. Overview of DRBA Figure 2. An Adaptation Function We use adaptation functions that we originally presented in [4] for expressing anticipated workload scenarios of the application during future time intervals. The adaptation functions describe the anticipated application workload as a function of the time (or a reference point such as task period) at which it is anticipated to occur. The functions are user-specified for each application task, can have arbitrary shapes, and are specified for a finite duration of future time. Furthermore, the functions can be dynamically modified as the user’s perception regarding the future workload changes. Specification of the functions will trigger proactive resource allocation. An example adaptation function is shown in Figure 2. In this work, we use task periods as reference points for describing anticipated workloads. Thus, we denote the anticipated workload of a task Ti during a period p as Ai (p). For a periodic task, the anticipated workload is defined as the number of data objects that is anticipated during a task period. For an aperiodic task, the anticipated workload is defined as the number of events that the triggering periodic task (of the aperiodic task) is anticipated to produce at the end of its period. The anticipated workload is assumed to be a constant during a period, but may be different for different periods.

2.3. System and Failure Model We consider a system architecture where hosts are interconnected using a shared media broadcast network such as Gigabit Ethernet that runs the CSMA/DDCR

The objective of resource allocation is to maximize aggregate benefit and minimize aggregate missed deadline ratio in the presence of host failures. We define the aggregate benefit of the application as the sum of the benefit accrued by the execution of the tasks of the application. The aggregate missed deadline ratio is the ratio of the number of missed task deadlines to the total number of task releases. This resource allocation problem can be shown to be NP-hard by mapping it to the 0-1 Knapsack problem. Thus, DRBA (and DOBA) algorithms that we present in this paper are heuristic algorithms that solve the problem in polynomial-time. The heuristics employed by the DRBA class of algorithms include: (1) Allocate resources in the decreasing order of task benefits. This heuristic will increase the possibility of maximizing aggregate task benefit, as the task selected next for resource allocation is always the one with the highest benefit among the unallocated tasks; (2) Allocate resources for each task until its deadline is satisfied. This heuristic will increase the possibility of maximizing the deadline-satisfied ratio. This is because, there is no reason to allocate resources for a task once its deadline is satisfied, since the task benefit functions are step functions and drop to zero benefit after the deadline; (3) De-allocate resources for a task if its deadline cannot be satisfied. By doing so, we save system resources, which can be used for potentially satisfying deadlines of lower benefit tasks, resulting in contributions of non-zero benefit from them toward aggregate task benefit.


(4) De-allocate resources for a task at any point in time during the resource allocation process, if timeliness of higher benefit tasks are adversely affected. The rationale behind this heuristic is that since it is not clear how many higher benefit tasks will have to “pay” for satisfying the deadline of the task (as their timeliness is adversely affected), it may be best not to “disturb” the aggregate benefit that is accrued so far. Moreover, since resources are always allocated in decreasing order of task benefits, the chances of obtaining a higher aggregate benefit is higher by satisfying as many high benefit tasks as possible. (5) Decompose task-level resource allocation problem into subtask-level resource allocation problem. The rationale behind this heuristic is that solving task-level resource allocation problem such as determining the replica needs of subtasks of a task and their end-hosts that will satisfy the task deadline, will require a holistic analysis of the system. This can be computationally expensive. Therefore, by decomposing the problem into sub-problems and solving the sub-problems, we seek to reduce the overhead of computing a near-optimal solution. Since we are focusing on step-benefit functions for tasks, the decomposition can be done by assigning deadlines to subtasks and messages of a task from the task deadline in such a way that if all subtasks and messages of the task can meet their respective deadlines, then the task will be able to meet its deadline. Using this heuristic, we can now determine the replica needs of a task that will satisfy the task deadline by determining the replica needs of subtasks of the task that will satisfy the subtask deadlines. Thus, DRBA allocates resources in decreasing order of task benefits and period occurrences, respectively. For each task and for each adaptation period, DRBA determines the number of replicas needed for each subtask and their hosts that will satisfy the subtask deadline for the current period. While computing the number of replicas, if the timeliness of a higher benefit task is affected or if the task is found to be infeasible, the algorithm de-allocates all allocated replicas and proceeds to the next task adaptation period. To assign deadlines to subtasks and messages of a task from the end-to-end task deadline, DRBA uses the equal flexibility (EQF) algorithm presented in [10]. Now, to determine the number of replicas that are needed for a subtask, DRBA at a host first analyzes the subtask response time on the host and determines the largest possible workload that the subtask can process without affecting the timeliness of higher benefit subtasks. The algorithm then broadcasts this workload to all other hosts, receives all broadcast messages, and computes an agreement decision. Hence, the algorithm

is named Distributed Response Time Analysis-Based Best-Effort Resource Allocation (or DRBA). Since we are considering the DASA scheduling algorithm, which uses benefit values of subtasks for making scheduling decisions, the user-specified task-level benefit must be mapped into benefit values for subtasks of the task. Toward this, DRBA defines the benefit of a subtask as simply the benefit of its parent task. We now discuss how DRBA analyzes subtask response times, computes agreement decisions, and detects host failures in the subsections that follow. In Section 3.5, we present three algorithms of the DRBA class. The algorithms use the key idea discussed here, but vary in their approaches for tolerating end-host failures while computing resource allocation decisions.

3.2. Analyzing Subtask Response Times DRBA assumes that a subtask completes its execution when all of its replicas complete their execution. Therefore, the response time of a subtask is the longest response time among all its replicas. Furthermore, the first subtask of a task will arrive at the beginning of the period of its parent task; every other subtask will arrive after the elapse of an interval of time (since the beginning of the task period) that is equal to the sum of the message delays and subtask response times of all predecessor messages and all predecessor subtasks of the subtask, respectively. Since determining the exact message delay will require a holistic analysis of the system as messages will suffer interference from each other [15], DRBA assumes that a message will arrive at its destination host by its deadline assigned using EQF. Now, given the arrival time of a task Ti , the arrival of a sub¢ ¡ time task stij of the task is given by AT stij = AT (Ti ) + ¡ i¢ ¡ i ¢¤ Pj−1 £ k=1 RT stk + dl mk , where AT (x) denotes the arrival time of a subtask or a task x, RT (x) denotes the response time of a subtask x, and dl (x) denotes the deadline of a message x. DRBA thus determines the arrival time of each subtask on a processor and constructs an arrival list using a binary heap, where arrival times are used as key values for the heap nodes. This enables the algorithm to efficiently determine the earliest subtask arrival time at any given time by performing an “Extract-Min” operation on the heap. Once the subtask arrival times are determined, the algorithm estimates the anticipated workload during each task adaptation period using the task adaptation functions. The anticipated workloads are then “plugged into” the subtask-profile functions to estimate the subtask execution times during the task peri-


ods. DRBA then estimates the subtask response times by determining the scheduling events that occur during the time window and by applying the scheduling algorithm at each scheduling event to determine the scheduling decision.

3.3. Determining Largest Possible Workload and Computing Agreement To determine the number of replicas needed for a subtask stij during a task period p, DRBA on each host will compute the smallest possible positive integer f , such that the subtask on the host is able to process 1/f of the task workload during the task period. This is given by Ai (p)/f . Furthermore, a replica of the subtask on the host should be able to process this workload successfully by its deadline without negatively affecting the timeliness of the subtasks that have been allocated so far. To compute the value of f at a host, the algorithm at the host iteratively analyzes response time of the subtask on the host, starting with a value of 1 for f and incrementing until the maximum possible number of replicas is reached. The maximum number of replicas that are possible for a subtask is equal to the number of end-hosts, since this allows maximum concurrency. Note that as the value of f increases, the value of the workload will decrease, and this will decrease the subtask execution time. Furthermore, this will increase the possibility of the subtask deadline to be satisfied. The algorithm at the host will iterate until one of the following three cases occurs: The first case occurs when the algorithm finds a value of f that is less than or equal to the maximum possible number of replicas, such that the subtask replica on the host can process the corresponding workload and complete before its deadline. Furthermore, this will not affect the timeliness of any higher benefit subtasks on the host. The second case occurs when the end of the iteration is reached and the algorithm finds that the subtask response time is still larger than the subtask deadline. The third case occurs when the end of the iteration is reached and the algorithm finds that the subtask response time is smaller than the subtask deadline, but unfortunately, the timeliness of one or more higher benefit subtasks on the host is negatively affected. If the second or third case occurs, the algorithm will broadcast an “impossible” value to all other hosts in the system, indicating that the host is unable to execute the subtask. If the first case occurs, the algorithm will insert the value of f and the ID of the host into a list called f list that has one entry per host. The algorithm

then broadcasts a message that contains the value of f and the ID of the host to all other hosts. Whenever the algorithm receives a broadcast message from any host, it will extract the f value and the host ID in the message and will insert the value-ID pair into the f list. Thus, when all hosts compute their f values, broadcast the values, and receive all the broadcast messages, each host will have an identical f list that indicate the f value of all hosts. Now, the DRBA algorithm at each host sorts the f list (ties are resolved using host IDs) and examines the sorted list in the ascending order. The algorithm stops examining the list either (1) when it finds an entry k in the list such that k = f list[k] or (2) when the list is exhausted. If the algorithm finds an entry k such that k = f list[k], then it implies that there are k hosts in the system, where f list[i] 6 i, for i = 1, . . . , k. Furthermore, each of these k hosts can execute a subtask replica on the host such that the replica can process at least 1/k of the workload without affecting the timeliness of higher benefit subtasks on the host. If no entry in the f list has a value for f such that k = f list[k], then it indicates that the workload of the subtask is infeasible. The algorithm therefore, deallocates all replicas that are allocated to subtasks of the task for the current adaptation period, since it is better to save resources for other tasks and thereby increase the likelihood of obtaining non-zero contributions from them toward aggregate task benefit. The algorithm then proceeds to the next adaptation period.

3.4. Detecting Host Failures DRBA uses timers to synchronize computations that concurrently proceed on each host. For example, some hosts may take longer to analyze subtask response times and compute f , since there may be large number of subtasks with shorter periods that are assigned to the host. Thus, the number of scheduling events would be large, resulting in longer execution times for computing response times. When the algorithm begins to compute the number of replicas for a subtask for a task period, it will start a timer. If the broadcast messages from all hosts are received before the timer expires, the algorithm turns off the timer and proceeds to the next subtask. On the other hand, if the timer expires and only a subset of the messages from other hosts have been received, the algorithm will then send probe messages to those hosts whose messages have not yet been received. Probe messages are further timed and repeated if a message from the host is not received before the timer expires. Prob-


ing is performed for a finite number of times and hosts whose messages are not received before the expiration of the last timer are considered as failed. Whenever a host receives a probe message from another host, the host will respond with an acknowledgement message that is broadcast to all the hosts in the network. Thus, the sender of the probe message (as well as other hosts) is simultaneously notified that the probed host is “alive.”

allocation, but ignores the values of f that were received from the hosts that have now failed. Note that these additional steps of examining previously saved values and ignoring those values of f from currently failed hosts do not incur any additional response time analysis or message broadcasts. Thus, this approach is faster than DRBA-SLR.

3.5. Three DRBA Algorithms

A careful observation of the DRBA class of algorithms reveals that the key component of the algorithms is computationally complex. In fact, the procedure that costs DRBA the most is the subtask response time analysis procedure. This is because, DRBA analyzes the subtask response time on an end-host processor by invoking the DASA scheduler at each subtask arrival and subtask departure. Given r processes in the ready queue of the processor, DASA incurs a worst-case complexity of O(r2 ) [1]. This means that given n tasks, a maximum of m subtasks per task, a smallest task period of k, and an adaptation window of length W , we can have O(mn dW /ke) arrivals on a processor, in the worst-case. Thus, the cost of invoking DASA for a single scheduling event 2 becomes O(m2 n2 dW/ke ). Before invoking DASA, the next earliest subtask arrival time should be extracted from the heap, which costs O(log (mn dW/ke)). The sequence of extracting the next subtask arrival from the heap and invoking DASA is repeated 2mn dW/ke times for all O(mn dW /ke) subtask arrivals and departures. Thus, the complexity of DRBA’s subtask response time analysis procedure becomes 2 2mn dW/ke (log (mn dW/ke) + m2 n2 dW/ke ), which 3 is O(m3 n3 dW/ke ). Thus, we now would like to design a faster algorithm that achieves the same objectives as that of DRBA. A careful observation again reveals that we can conduct an overload test on the processor for determining subtask feasibility, instead of analyzing response times. If a processor is under-loaded, then clearly, the subtask must be able to complete its execution by its deadline as DASA is equivalent to EDF during under-loaded situations, where EDF guarantees all deadlines [1]. On the other hand, if a processor is overloaded, we can then reduce the workload share of the subtask by considering a replica for the subtask. The subtask feasibility can then again be determined through the overload test and the whole procedure can be repeated in a way similar to that of DRBA. We call this new algorithm Distributed Overload Analysis-Based Best-Effort Resource Allocation (or DOBA). Given n subtask arrivals on a processor that are

It is possible to construct variants of the DRBA algorithm that differ in the way they tolerate end-host failures while computing resource allocation decisions. We consider three variants of DRBA. These include (1) DRBA with no reallocation upon failure, called DRBANR, (2) DRBA with stateless reallocation upon failure, called DRBA-SLR, and (3) DRBA with stateful reallocation upon failure, called DRBA-SFR. The DRBA-NR algorithm detects host failures by sending probe messages as described in Section 3.4. However, once a failure is detected, the algorithm simply proceeds to the next allocation step. Note that the resource allocation that has been performed so far assumed the presence of the failed host, which is not true anymore and therefore has become incorrect. However, DRBA-NR does not “care” to correct the incorrect allocation and simply continues. Nevertheless, when a host failure is detected, DRBA-NR at all other hosts will now mark that host as “failed” and will not expect broadcast messages from the failed host in the subsequent steps of the resource allocation. The main motivation behind this approach is to perform the resource allocation as fast as possible. However, the algorithm will perform poorly if the host failures occur late in the resource allocation process, since all the previous subtasks would now be allocated based on no longer valid messages from the failed host(s). The DRBA-SLR algorithm re-computes the entire resource allocation from the beginning, once a host failure is detected. This will lead to more accurate resource allocations than DRBA-NR, but at the cost of additional computational overhead, since the process of response time analysis, computation of largest feasible workload, and message broadcasting for computing agreement has to be repeated every time a failure is detected. DRBA-SFR allocates resources exactly like DRBANR. However, it saves the values of f received from all the hosts for all the steps of the resource allocation process. When host failures are detected, the algorithm uses the saved values of f and re-computes the resource

4. The DOBA Class of Algorithms


5.1. DRBA versus DOBA Figure 3 shows the aggregate accrued benefit (or AAB) of DRBA and DOBA under increasing ramp workload pattern and no end-host failure. Each data point in the plot was obtained by a single experiment. Thus, the maximum workload of the individual experiments are shown on the x-axis of the plot. Aggregate Accrued Benefit 120

%

deadline-ordered, we can perform the overload test in O (n) time [1]. Thus, given a subtask-deadline heap, we can test for overload by examining each subtask deadline in their increasing order, and comparing the current subtask deadline against the cumulative sum of the remaining execution times of all subtasks with lesser deadlines (than the current subtask deadline). It costs log (mn dW /ke) to extract and delete the next earliest deadline subtask from the heap. Since this process is repeated for all the mn dW /ke nodes of the heap, the cost of the overload test is O (mn dW /ke log (mn dW /ke)). This cost is an order of magnitude improvement over that of DRBA’s subtask response time analysis procedure.

NR SLR SFR

4

O p n m dW /ke 4

4

4

O pn m dW /ke

0

2

4

6

8

Total Maximum Load

10

12

O pn2 m2 dW /ke Π 4

4

0

2

O pn4 m4 dW /ke 2

DOBA

60

20

DOBA (Π = log (nm dW /ke)) 4

DRBA

80

40

Table 1. Complexities of DRBA and DOBA DRBA

100

O p2 n2 m2 dW /ke2 Π 2

2

Figure 3. AAB of DRBA and DOBA

2

O pn m dW /ke Π

In order to determine the number of replicas for a subtask and their end-hosts, the DOBA algorithm at each host computes the smallest possible positive integer f such that the host is able to process 1/f of the workload, which is given by Ai (p)/f , without causing an overload situation on the host. The rest of the algorithm is the same as DRBA. We can also specify three variant algorithms of DOBA called DOBA-NR, DOBA-SLR, and DOBASFR that are analogous to DRBA-NR, DRBA-SLR, and DRBA-SFR, respectively, in the way the algorithms tolerate end-host failures while computing resource allocations. Table 1 summarizes the worst-case computational complexities of the DRBA and DOBA algorithms. For brevity, we omit the analysis of the complexities.

Under no host failure, all three variants of DRBA and DOBA algorithms are exactly the same. The figure shows that DRBA and DOBA yield almost the same aggregate benefit. Similar results were observed for the deadline-satisfied ratio metric.

5.2. DRBA Algorithms Under Failures Figure 4 shows the AAB produced by the DRBA algorithms under the ramp load pattern and the ramp failure pattern. We observe that DRBA-NR shows very poor performance when end-hosts fail. Furthermore, DRBA-SFR performs almost the same as DRBA-SLR. We observed similar consistent results for constant workload and step end-host failure patterns and for the deadline-satisfied ratio metric.

5. Experimental Evaluation

Aggre ga te Ac c rue d Be ne fit

120

D R B A-S L R

100

D R B A-S FR

80

D R B A-N R %

In our experimental study, we considered adaptation functions that have an increasing “ramp” workload pattern, and end-host failures that follow “ramp” and “step” patterns. In an increasing ramp workload pattern, the workload of a task is anticipated to linearly increase whenever the task is triggered. In an increasing ramp end-host failure pattern, the number of failed hosts linearly increase over time. In an increasing step failure pattern, increasing percentages of the total hosts in the system instantaneously fail at one point in time.

60 40 20 0 0

2

4

6

8

Tota l M a x im um Loa d

10

12

Figure 4. AAB of DRBA Algorithms


5.3. DOBA Algorithms Under Failures Figure 5 shows the AAB of the DOBA algorithms under the ramp load and ramp failure patterns. We still observe that DOBA-NR performs poorly when endhosts fail. Furthermore, DOBA-SFR and DOBA-SLR perform almost the same. Again, similar consistent results were obtained for constant workload and step end-host failures and for deadline-satisfied ratio. Aggre gate Ac c rue d Be ne fit

120

D OB A-SL R

100

D OB A-SFR

80 %

D OB A-N R 60 40 20 0 0

2

4

6

8

10

12

Tota l M ax im um Loa d

Figure 5. AAB of DOBA Algorithms

6. Conclusions Our experimental results thus reveal that DOBA produces just about the same aggregate benefit and deadline-satisfied ratio as that of DRBA. Furthermore, the SFR algorithms react to failures and produce almost the same aggregate benefit and deadline-satisfied ratio as that of the SLR algorithms. This result further reinforces the result in [14] that application statedriven incremental decisions can produce better resource allocations. Finally, we note that DOBA-NR is faster than DRBA-NR and the SFR algorithms are faster than the SLR algorithms by orders of magnitude. We have constructed a real-time middleware called Choir, that contains the RBA∗ and OBA algorithms. Efforts are ongoing in implementing the DRBA and DOBA algorithms in Choir.

7. Acknowledgements This work was supported by the U.S. Office of Naval Research under Grant N00014-00-1-0549.

References [1] R. K. Clark. Scheduling Dependent Real-Time Activities. PhD thesis, Carnegie Mellon University, 1990. CMU-CS-90-155. [2] DARPA. Quorum. http://www.darpa.mil/ipto/ research/quorum/index.html, August 1997.

[3] R. Devarasetty. Heuristic algorithms for adaptive resource management of periodic tasks in soft real-time distributed systems. Master’s thesis, Virginia Tech, February 2001. [4] T. Hegazy and B. Ravindran. Using application benefit for proactive resource allocation in asynchronous real-time distributed system. IEEE Transactions on Computers, 51(8):945–962, August 2002. [5] J.-F. Hermant and G. L. Lann. A protocol and correctness proofs for real-time high-performance broadcast networks. In Proceedings of The IEEE Conference on Distributed Computing Systems, pages 360–369, 1998. [6] Proceedings of the ieee workshop on middleware for distributed real-time systems and services, December 1997. In Conjunction with The 18th IEEE Real-Time Systems Symposium. [7] E. D. Jensen. Asynchronous decentralized real-time computer systems. In W. A. Halang and A. D. Stoyenko, editors, Real-Time Computing, Proceedings of the NATO Advanced Study Institute. Springer Verlag, October 1992. [8] E. D. Jensen and J. D. Northcutt. Alpha: A nonproprietary operating system for large, complex, distributed real-time systems. In Proceedings of The IEEE Workshop on Experimental Distributed Systems, pages 35–41, 1990. [9] E. D. Jensen and B. Ravindran. Guest editor’s introduction to special section on asynchronous real-time distributed systems. IEEE Transactions on Computers, 51(8):881–882, August 2002. [10] B. Kao and H. Garcia-Molina. Deadline assignment in a distributed soft real-time system. IEEE Transactions on Parallel and Distributed Systems, 8(12):1268–1274, December 1997. [11] G. Koob. Quorum. In Proceedings of The Darpa ITO General PI Meeting, pages A–59–A–87, October 1996. [12] P. Li, B. Ravindran, and T. Hegazy. Implementation and evaluation of a best-effort scheduling algorithm in an embedded real-time system. In Proceedings of The IEEE Symposium on Performance Analysis of Systems and Software, pages 22–29, November 2001. [13] D. L. Mills. Improved algorithms for synchronizing computer network clocks. IEEE/ACM Transactions on Networks, pages 245–254, June 1995. [14] D. Rosu, K. Schwan, S. Yalamanchili, and R. Jha. On adaptive resource allocation for complex real-time applications. In Proceedings of The 18th IEEE Real-Time Systems Symposium, pages 320–329, December 1997. [15] K. Tindell and J. Clark. Holistic schedulability analysis for distributed hard real-time systems. Microprocessing and Microprogramming, 40:117–134, 1994. [16] L. R. Welch, B. Ravindran, B. Shirazi, and C. Bruggeman. Specification and modeling of dynamic, distributed real-time systems. In Proceedings of The IEEE Real-Time Systems Symposium, pages 72–81, December 1998. [17] D. Wells. MK7.3 Release Notes. The Open Group Research Institute, Cambridge, Massachusetts, 1997.
