IRIS: A new reclaiming algorithm for server-based real-time systems
Luca Marzario and Giuseppe Lipari
Scuola Sup. S.Anna, Pisa, Italy
marzario, lipari
@sssup.it
Patricia Balbastre and Alfons Crespo
Universidad Politecnica de Valencia, Valencia, Spain
patricia, alfons
@disca.upv.es
Abstract
In this paper we present a new algorithm for CPU re-source reservation in real-time systems that allows the coex-istence of hard, soft and non real-time tasks. The proposed algorithm is specifically designed to handle computational overload. A task that needs more CPU-time than reserved can re-use the spare bandwidth, without interfering with the others tasks. With respect to other reclamation schemes, the novelty of the proposed algorithm is that the spare band-width is fairly distributed among the needing servers. The effectiveness of the algorithm is demonstrated with an ex-tensive set of experiments. We also propose a methodology to set scheduling parameters depending on the type of the task and on the time constraints needed.
1. Introduction
General purpose operating systems are not well suited for executing soft real-time applications, like multimedia applications or monitoring systems, because of their par-ticular requirements in terms of delay and jitter limitation.
On the other hand, hard real-time operating systems gen-erally offer support only for hard real-time processes, pro-viding a ”best effort” service to non real-time processes. Abeni and Buttazzo [2] list the main e reasons why schedul-ing such applications in hard real-time systems is unpracti-cal.
In recent years, many researchers studied the problem of integrating hard, soft and non-real-time tasks. One of the best approaches is the resource reservation framework [10]. For soft real-time tasks, the notion of reservation guaran-tee has been introduced. This reservation ensures that an amount of a resource will be available to the reserved task every period
Reservation guarantees for soft real-time tasks can also be applied to other kind of applications besides
This work has been partially supported by the OCERA project (IST 2001 35102), funded by the European Commission
dia systems. Mobile robotic systems are performed combin-ing deliberative goal-oriented planncombin-ing with reactive sen-sor driven operations. This results in an heterogeneous sys-tem with reactive activities and deliberative processes. Usu-ally, the first ones have hard real-time constrains, while the second ones are implemented as soft real-time tasks. Has-san, Simo and Crespo [5] presented a real-time architec-ture to cope with the dynamic and flexible environment of behavior-based mobile robotic applications.
The combination of hard and soft activities is also found in industrial control applications, where the control action of the regulator can be obtained in a first step by a hard real-time task, and if there is enough time, the control ac-tion is refined using the remaining time of the system (by a soft real-time task) [3]. Balbastre et al. proposed a frame-work in which tasks are divided into a mandatory part and in a optional computation, and the amount of this extra com-putation is guaranteed off-line.
The main advantage is the ease of implementation of the system, since in this case the task model is simpler than im-precise computation models or multiple version tasks. Al-gorithms such as CBS [1] or GRUB [6, 4] fit perfectly to implement this kind of applications.
However, as explained in the following sections, both CBS and GRUB suffer from certain shortcomings. This pa-per presents a new work-conserving algorithm called IRIS (Idle-time Reclaiming Improved Server), that presents sig-nificant improvements respect to CBS and GRUB. The main property of IRIS is that it guarantees a minimum budget in a fixed interval of time. This is a key issue for the applica-tions explained before, and leads to a significant improve-ment in its behavior.
2. System model and notation
In this research, we consider two types of tasks in the system: cyclic tasks and non–cyclic tasks. Acyclic task
consists of a main loop. At the end of every loop instance the task blocks waiting for some event. Each execution be-tween two blockings is calledjob
We indicate with
the worst-case execution time (WCET) of Cyclic tasks
timer event with period ;sporadic tasksthat wait for ex-ternal events with a minimum inter-arrival time, also called ; aperiodic tasks that wait for external events with an unbounded inter-arrival time. We assume that the relative deadline of cyclic tasks is equal to Each job
has
as-sociated an arrival time
and a deadline We denote with
the utilization factor of task
More-over, cyclic tasks can be divided into two classes, depend-ing on their criticality: hard real-time and soft real-time. For the hard real-time tasks, it must be guaranteed that every job completes before its deadline while for soft real-time task a deadline miss could result in a performance degra-dation but not in a critical fault.Acyclic tasksmodel batch activities that are continuously active for large intervals of time, like for example the process of compiling a program, or a long scientific simulation or calculation, or a control tasks polling an external sensor. Usually, they are not as-sociated any temporal constraint. However, in some case it may be desirable to execute them at a certain minimum rate. Aserver is an abstract entity used by the scheduler to re-serve a fraction of CPU-time to a task. Each re-server is characterized by the period of the reservation and by the
reserved execution time per period; we define
the fraction of CPU-time reserved by server , also called utilization factor. In addition, each server maintains its own internal variables that are updated by the scheduler depend-ing on the server rules. One of these variables is the server priority. The servers are inserted in the priority queue of the scheduler. When a server is selected by the scheduler, the corresponding task is executed. While a task is executing, the budget of the server is decremented accordingly. We de-note by the current budget of server When the budget
is exhausted, the task is stopped until the budget is replen-ished. We denote with
the time at which the budget is
replenished. Each server has a dynamic deadline that is
used by the scheduler to order tasks in the priority queue, accordingly with EDF algorithm [7].
3. Problem description
Algorithm IRIS that we present in this paper is based on the Constant Bandwidth Server (CBS) of Abeni and But-tazzo [1]. The basic idea of the CBS algorithm is that, when the budget is exhausted, it is immediately recharged to and its dynamic deadline is postponed to
The CBS presents some drawbacks when serving acyclic tasks. In Figure 1a we show an example of such problems. Consider a system consisting of two acyclic tasks
½ and
¾ served by servers ½ e ¾, respectively. Suppose that
at a certain instant
½is the only active task in the system
and executes without stopping itself. The associated server
½consumes all its budget, postponing its deadline several
times so that it goes far away in the future. When task ¾ ar-1 τ2 τ 1 τ2 τ
Figure 1. (a) Problem of CBS when scheduling acyclic tasks. (b) Another problem of CBS: the server parameters are not respected.
rives, server ¾is assigned a short deadline and, according
to the EDF scheduler, it executes. When budget of ¾is
en-tirely consumed, its deadline is postponed. However, since the deadline of server ½ is far away, it is still the
earli-est deadline and continues to execute. Only after its own deadline becomes greater than the deadline of ½
¾is
pre-empted and the first task can continue to execute. As you can see in Figure 1a, the servers do not execute every Moreover, the amount of execution in every period for
server ½depends on the arrival time and on the period of
server ¾
We say that both servers suffer fromdeadline ag-ing.
Another problem can be highlighted by the following ex-ample. Consider a system scheduled by the CBS algorithm consisting of two tasks. Task
½ is acyclic it is served by
server ½with budget ½ and period ½ The sec-ond task
¾is periodic with period ¾
and it is served
by a server ¾with budget
¾
and
¾
The
re-sulting schedule is shown in Figure 1b. Task
½is not scheduled as we expect. In particular, it
ex-ecutes as it was served by a server with budget ¼ ½ and period ¼ ½
Notice also that this behavior depends on
the parameters of the other servers in the system. For exam-ple, if the second server had a budget of
¾
and a
pe-riod of ¾
the first task would be scheduled as it was
served by a server with budget ¼ ½ and period ¼ ½
This problem is more subtle and depends on the fact that CBS algorithm immediately recharges the budget without suspending the tasks. This second problem can be solved by using the technique calledhard reservation [10]. In a hard reservation, when the budget is exhausted, the corre-sponding task is suspended until arecharging time. Never-theless, adding only this rule to the CBS algorithm makes it a non-work-conserving algorithm: the system is forced to be in idle state even if there are pending jobs.
Summarizing, the main drawback of CBS algorithm is that it does not guarantee a minimum execution time to a task in a fixed interval of time. This is particularly nega-tive for multimedia or interacnega-tive tasks, since the period of
forced inactivity, caused by a possible starvation after an overload situation, can result in a loss of quality of service and interactivity.
To solve these problems, we decided to propose a novel algorithm called IRIS (Idle-time Reclaiming Im-proved Server) that overcomes the aging deadline prob-lem, guarantees a minimum budget in a fixed interval of time, and it is work-conserving.
4. The IRIS Algorithm
4.1. Definition
IRIS is based on the CBS [1]. It can be defined as fol-lows:
Each server is associated to a task and is
char-acterized by an ordered pair where is the
maximum budget and is the relative deadline. The
sum of all server bandwidths cannot exceed 1:
Each server maintains: acurrent budget that is
decreased while the served task is running; a server deadline that is used to insert the server in the EDF
queue of the system scheduler; arecharging time
that is used to set the time to recharge the current bud-get when it has been exhausted.
Each server can be in one of the following states:
1. Active: the served task is ready to execute or
ex-ecuting and the current budget
2. Recharging: the served task is ready to execute
but the server is waiting for replenishment of the exhausted budget;
3. Inactive: the served task completed the last job
and has no more pending jobs.
Recharging Inactive
Active
Figure 2.State transition diagram.
The system maintains a ready queue, where all Ac-tiveservers are ordered by deadline, and a recharging queue, where allRecharging servers are ordered by recharging time.
Initially all servers are in theInactivestate.
The current budget and the relative deadline associated with each server are updated applying the following rules:
1. If a job
arrives at time t,
(a) if the server isInactive, i. if
then
ii. if and the server becomes
Rechargingand it is inserted in the
recharg-ing queue with
iii. otherwise the server becomesActiveand it is inserted again in the ready queue with the same current budget and deadline.
(b) if the server isActiveorRecharging, the arrival is buffered and will be served later.
2. When the served task executes forÆ Æ
3. If the server isActiveand the server reaches
theRechargingstate and the recharging time is set to
4. If the server is in theRecharging state and
then the server become Active, and
5. When the job finishes,
(a) if there is another pending job, the server remains in theActivestate;
(b) otherwise it goes inInactivestate.
6. If at timeno server is inActivestate and there is at
least one server inRechargingstate,
(a) let be the first server in the recharging queue
(i.e. the one with the smallest recharging time), and let Æ
for every server i in the
recharging queue, Æ
(b) every server in the recharging queue with is removed from the recharging queue and
in-serted in the ready queue; its budget is recharged toand its deadline is set to
The IRIS algorithm presents two main differences with respect to the original CBS algorithm. The first difference is that IRIS explicitly sets a recharging time for each server, whereas the CBS algorithm immediately recharges the server that exhaust its budget. Therefore, the IRIS algo-rithm implements the hard reservation technique [10]. Sec-ond, and most important, the IRIS algorithm introduces a rule for advancing the recharging times of all the servers in
theRechargingstate when an idle time occurs. In this way,
the IRIS algorithm efficientlyreclaimsthe idle time of the system and distributes it among the needing servers.
4.2. Properties
The IRIS algorithm maintains the original CBS schedu-lability property. It is also a fair algorithm in the sense that the spare time is equally distributed among the servers that need to execute more than the reserved CPU time.
Before proving the theorems, we introduce a simplified scheduling algorithm that use the same rules of IRIS except Rule 6. This algorithm has the same behavior as IRIS ex-cept that when all servers are inRechargingstate, the CPU is forced to be idle until the next re-charging event. We will call it IRIS-HR (IRIS Hard Reservation). We are not go-ing to implement IRIS-HR, but we use it only for the sake of demonstrating the properties of IRIS.
Definition 1 We define the demand bound function of an IRIS-HR server as We indicate with ½ ¾ ¾ ½ Lemma 1 (Utilization factor)The demand bound function of an IRIS-HR server with parameters in any intervals ½ ¾ never exceed
Proof The proof of this lemma is similar to the same prop-erty of the CBS algorithm (see [1]). We remand the reader for the full proof to [8].
Theorem 1 (Schedulability Property)Given a set of pe-riodic tasks with total utilization factor
and a set of IRIS servers with utilization factor
the whole set is schedulable by EDF if and only if
For space limitation, we do not report the proof of this theorem here. The proof can be found in [8].
Theorem 2 (Hard Schedulability)A hard task with pe-riod and WCET is schedulable by an IRIS server with parameters and if and only if is schedu-lable with EDF.
ProofFor any job of a hard task we have that ·½ and
Hence, by definition of the IRIS, each
server is assigned a deadline
equal to the
job deadline, and it is scheduled with a budget
Moreover, since
each job finishes before the
bud-get is exhausted, the server deadline assigned to a job is never postponed and is exactly the same as the one used by EDF; moreover, the server will never reach the Recharg-ingstate so the rule 6 will never be applied. By Theorem 1 the job will never miss its deadline.
Note that Theorem 2 is valid both for IRIS and IRIS-HR since theRechargingstate will never be reached and there-fore Rule 6 is never applied.
Property 1 (Minimal execution time guarantee) Let
½
¾
be an interval such that server serving task is never inactive. If
¾
½
then
exe-cutes at least unit of time in the interval ½
¾
Proof Let
be the first replenishing time for server in
½
¾
We now analyze all possible case that current
bud-get can assume at time ½:
This means that the budget has been replenished
at time ½ ½ ½ Contextually,
the deadline is set to
½
In the worst case,
½
½
so that the server deadline at time ½is ½ ½ ¾
Since the server
will execute at least up to
by setting ¾
the theorem holds.
This means that the server executed for at list
since the last recharging time
½ so ½ ½ In the worst case the budget is just exhausted (
½
½
) and there will be no idle time till
½ ½ hence ½ ½ At in-stant
the budget is replenished and the deadline is
set to ½ ; the server
will execute at least from
up to By set-ting ¾
the theorem holds. This means that
½ ½ and ½ ½
In this case
exe-cutes for at least unit of time up to
½ In the worst case, at ½ ½ the
bud-get is replenished. will be scheduled at least at the
time This descends
from Theorem 1, since otherwise the server will miss its deadline. Consider the instant
¾ ½ ½ Since in
the worst case is scheduled at
and executes till
it executes in the interval ¾ for ¾ Hence in the interval
½
¾
execute at least
An interesting property of IRIS server is that it solves the deadline aging problem (see Section 3).
Property 2 If is the deadline associated to the server at timewe have that:
ProofThis is easily proved since each time the server dead-line is assigned, it is set to the current time plus the pe-riod of the server. The IRIS algorithm distributes the spare
time among the reclaiming servers in a fair way: the spare time of the system is redistributed to the servers propor-tionally to the reserved bandwidths. Since the allocation of CPU time is not fluid, we show the property only in inter-vals large enough with respect to the periods of the servers. For simplicity we analyze the case in which the served tasks are always ready to execute. We denote by ¼
½
¾
the bandwidth used by server in the interval ½ ¾ : ¼ ½ ¾ ¼ ´ ¾ µ ¼ ´ ½ µ ¾ ½ where ¼ is the amount of
budget used by server until time
Theorem 3 (Fairness) Consider two IRIS servers serving tasks that are always ready to execute (the servers are always in the stateActiveor Re-charging). The follow-ing property holds:
½ ¾ ¾ ½ ¾ ½ ¾ ½ ¼ ½ ¾ ¼ ½ ¾ ¾ ½ ¾ ½ (1) where
Proof We first consider the IRIS-HR algorithm and then we show that the same property is valid for IRIS. Under the hypothesis, the only rule applied to set the budget and deadline, after the first assignment when the first request is raised, is Rule 4. This implies that at each reservation’s pe-riod, each server execute exactly for unit of time. The
minimum total budget ¼
assigned to serverin any
in-terval ½ ¾ is: ¼ ½ ¾ ¾ ½
This minimum corresponds to the case in which the budget has just been replenished at time
½
and exhausted at
time
½; moreover, at
¾the server is going to execute and
the budget will exhaust at the deadline expiration time ¾
Similarly, the maximum total budget is:
¼ ½ ¾ ¾ ½
This is the case when at
½the server is scheduled and will
exhaust its budget at the deadline expiration ½
and
at ¾
the budget has just been replenished and is
ex-hausted at time
¾(the dual situation of the previous one).
We now calculate the minimum ratio between the budget assigned respectively to two serversandin
½ ¾ : ¼ ½ ¾ ¼ ½ ¾ ¼ ½ ¾ ¼ ½ ¾ ¾ ½ ¾ ½
The ratio can be minimized as following:
¾ ½ ¾ ½ ¾ ½ ¾ ½ ¾ ½ ¾ ½ Æ where we definedÆ ´¾ ½ ¾µ ´ ¾ ½ ·¾ µ
Similarly to minimum ratio, maximum ratio is:
¼ ½ ¾ ¼ ½ ¾ ¼ ½ ¾ ¼ ½ ¾ ¾ ½ ¾ ½
The ratio can be maximized as following:
¾ ½ ¾ ½ ¾ ½ ¾ ½ ¾ ½ ¾ ½ Æ whereÆ ´ ¾ ½ ·¾ µ ´¾ ½ ¾µ Finally, we have Æ ¼ ´½ ¾µ ¾ ½ ¼ ´ ½ ¾ µ ¾ ½ ¼ ½ ¾ ¼ ½ ¾ ¼ ´½ ¾µ ¾ ½ ¼ ´½ ¾µ ¾ ½ Æ
Now consider the schedule
generated by IRIS.
Apply-ing Rule 6 the schedule is modified when the system is idle by anticipating of the same amount the activation time of all tasks that are inRecharging state. This anticipation does not modify the order and the distance between two consecu-tive recharging events. This means that, considering the two servers and
we can map one-to-one every recharging
instant and period of reservation of the IRIS-HR schedule
with the IRIS schedule Consider an interval ½ ¾ in
and the corresponding one ¼ ½ ¼ ¾ in
Since the
to-tal budget assigned in the two intervals is the same, the ex-pression calculated above is still true if we substitute
½and ¾with ¼ ½and ¼ ¾
Note that Equation 1 depends exclusively
on the size of the interval and not on the position of the time window.
The schedulability property (Theorem 1) is an important result because allow us to execute in the same system EDF, IRIS-HR and IRIS servers, assigning independently the pro-cessor utilization to each server with the only (obvious)
con-straint that the total utilization must be less than 1. This al-lows an easy design of system’s bandwidth reservation (see section 5).
IRIS automatically reclaims the spare time of the sys-tem. This is done applying the rule 6. The reclamation is done at a certain time if and only if all active servers ex-ecuted at least for the reserved time in the current period. Hence, IRIS prevents the reclamation of a server from de-laying the execution of other servers or hard real-time tasks that have not yet executed in the current reservation period. Moreover, IRIS avoids the irregularities of the CBS sched-ules, which are caused by an early reclamation, as we have seen in Section 3.This is the main difference with respect to CBS algorithm. The regularity of the IRIS algorithm with respect to CBS has been also proved by properties 1 and 2.
5. System’s Design
All the properties mentioned in the previous section al-low us to use a bandwidth reservation strategy to allocate a fraction of the CPU time to each task independently of the other tasks in the system. In particular, we can execute in the same system different types of task, cyclic and acyclic, hard and soft.
In this section, we give some suggestion on how to as-sign the budget and the period to the different tasks in the the system.
¯ Hard real-time tasks. Hard real-time tasks can be
scheduled directly by EDF or by a dedicated IRIS server. The second solution ensures that tasks execut-ing for longer than estimated do not jeopardize the en-tire system. This is useful especially in the developing and debugging phase.
¯ Soft real-time tasks.In the case of periodic soft
real-time tasks, we can set to the task’s period. For
aperi-odic tasks, the server period should be set equal to the maximum response time needed. To set we have
more freedom: since setting it to the WCET may waste the CPU utilization, we can set this parameter to some value between the task’s average execution time and its WCET. The trade off is between the amount of re-served bandwidth and the number of deadline miss.
¯ Non real-time tasks.These tasks do not have time
constraints. However, in many cases it could be de-sirable to execute them at a certain rate. In this case a server could be used to reserve a fraction of CPU time to each task. must be set to the granularity of
reservation, while must be set proportionally to the
needed bandwidth.
Since we proved that that IRIS-HR servers can be sched-uled together to IRIS servers, we can use a IRIS-HR server to force a task to use no more than the reserved bandwidth.
This could be important in case we want to use an exter-nal control system to dynamically assign the bandwidth to a task, like in the case of feedback scheduling [9], to man-age power consumption or simply to slow down a particular application.
6. Simulation results
In this section, we show the effectiveness of the IRIS al-gorithm. The goal is to highlight two important characteris-tics of IRIS against CBS: good performance in overload sit-uations, and minimal temporal utilization guarantee. A mas-sive number of tests have been run using a synthetic work-load model. In the following, we describe the simulations settings and the obtained results.
6.1. Performance in overloaded systems
The task sets for these experiments were generated with the following characteristics:
¯ Three hard real-time periodic tasks, generated with
random and
The bandwidth consumed by hard
tasks is:
¯ Two soft real-time tasks that serve sporadic jobs,
whose inter-arrival and execution times are also ran-domly generated around the values and A
to-tal of 300 jobs are generated for each task. The soft load is:
The variable measured is the average response time of sporadic tasks, when task sets are scheduled under IRIS and CBS. Being
the response time of the job
the
aver-age response time of soft real-time is defined as follows:
In the first experiment, soft real-time tasks consume 15% of the total utilization of the system ( ) while
hard task parameters are specified with
ranging from
0.2 to 0.6. We assume that the computation time of the jobs (
) is similar to the budget of the server assigned to the
task (). In this case, average response time is very
sim-ilar in IRIS and CBS, although it is slightly lower in the case of IRIS. Experiment 2 has been generated with the same characteristics than Experiment 1, except that an over-load situation is forced. We can create an overover-loaded sys-tem if some jobs have a
(we call it ”heavy” jobs). In the simulations, every 10 ac-tivations
The results are shown in Figure
3. In this case, IRIS performs much better than CBS, be-cause CBS suffers from deadline aging, and when a ”heavy” job arrives, the budget is replenished several times and the deadline is moved away. This way, the response time of the ”heavy” job, and also the response time of future jobs, is highly increased. However, as IRIS does not replenish the budget immediately, the jobs that arrive after the ”heavy” one do not suffer the consequences of the overload, main-taining a reasonable response time. In Experiments 3 and 4,
Figure 3. Response time under overload situ-ation (
)
hard tasks consumes 35% of the total utilization of the sys-tem ( ) while soft real-time tasks parameters
andare generated with
ranging from 0.1 to 0.5.
Ex-periment 3 simulates a normal execution while ExEx-periment 4 simulate an overload situation.
Figure 4. Response time under overload
situ-ation ( )
In both experiments, the performance of IRIS is better than CBS, with a great improvement in the overloaded sys-tems (Figure 4).
The number of missed tasks’ deadlines is also an im-portant parameter that must be taken into account. Figure 5
shows the percentage of missed deadlines with both algo-rithms for the task sets generated in Experiment 4. The re-sults show that the maximum deadline misses of IRIS is less than 30%, being always greater in CBS.
Figure 5. Deadline misses under overload sit-uation
6.2. Fairness of bandwidth allocation
In this section, we compare the bandwidth is assigned di-namycally in IRIS and CBS in order to prove that IRIS is more fair. In the first experiment, the workload consists of 6 greedy tasks (
), with
and randomly
gener-ated, except budget for that is
Task set
param-eters are generated to have different utilization (from 20 to 80%).
In this case, the variable measured is the distance be-tween two consecutive executions of task
As this task
has
we want to see if the required utilization of
the task is guaranteed for both algorithms. During the sim-ulations, the number of occurrences of every value of the distance have been counted. The distance between two con-secutive executions has been normalized to the period
Figure 6 shows the results.As it can be seen, CBS executes with a great variabil-ity, and most of the times task executions are very close. But, due to deadline aging, when the budget is exhausted, the task scheduled under CBS can stay without executing for a long time. This is the reason why under CBS, the time between two consecutive executions can be up to 440% of the task period. However, a task scheduled under IRIS executes most of the times every period, or less. And the maximum interval between two executions is only 190% (
). This property of IRIS is specially important in
systems where reducing jitter is a key issue, such in con-trol systems.
The second experiment consists of measuring the utiliza-tion of greedy tasks all over the execuutiliza-tion of the system, and see what happens to utilization when a new greedy task ar-rives. The goal is to demonstrate that IRIS is more fair in distributing the idle time than CBS.
Figure 6. Comparison of distance between two consecutive executions
Experiments have been done as follows: three acyclic tasks ½
¾ and ¿ have been generated with server
peri-ods ranging from 10 to 30. First activation of ½ and ¾is
set to the initial instant (t=0), while first activation of ¿is
set to instant t=30. The variable measured is
¼ ½
´½¾µ ½
Sim-ilar results have been obtained with
¼ ¾
´½¾µ ¾
but in Figure
7 are depicted results only for ½
Instants ½ and
¾ have
been chosen to measure utilization in windows that moves over the total execution of the system. The size of the win-dows is the largest period the three tasks. This means that, in Figure 7, point 1 in X coordinates means the first win-dow (
½
¾ ), point 2 is the second
win-dow ( ½
¾
), and so on. Figure
Figure 7. Fairness: acyclic tasks
7 shows that, in CBS, the utilization of ½ rapidly goes to
0 when ¿ arrives (t=30). And the same happens to ¾ As
a consequence, CBS does not maintain the utilization re-quired. However, IRIS maintains the required utilization of
½
even when new tasks arrives, or even in overload
situa-tions.
7. Conclusions and future work
In this paper, the IRIS algorithm has been presented. It is a new resource reservation scheduling algorithm expressly designed to deal with systems consisting of different types of tasks, cyclic and acyclic, periodic and aperiodic, hard and soft real-time tasks. IRIS enhances the CBS algorithm [1] by introducing an efficient reclamation mechanism. In ad-dition, IRIS provides a fair distribution of the spare time to the needing tasks, and ensure a minimum execution time to each task in every interval of time.
Simulations corroborated the theoretical results, show-ing the better performance of IRIS against CBS. Current re-search is focused on the implementation of IRIS in a real-time kernel. A first version has been released in RTLinux under the OCERA IST project. The goal is to use the bene-fits of this new algorithm with real applications.
References
[1] L. Abeni and G.Buttazzo. Integrating multimedia
applica-tions in hard real-time systems. InProceedings of the 19th
IEEE Real-Time Systems Symposium, Madrid, Spain,
decem-ber 1998. IEEE.
[2] Luca Abeni. Server mechanisms for multimedia applica-tions. Technical Report RETIS TR98-01, Scuola Superiore S. Anna, 1998.
[3] Patricia Balbastre, Ismael Ripoll, and Alfons Crespo. Schedulability analysis of window-constrained execution
time tasks for real-time control. In14th Euromicro
Confer-ence on Real-Time Systems., 2002.
[4] G.Lipari and S.K. Baruah. Greedy reclaimation of unused
bandwidth in constant bandwidth servers. InIEEE
Proceed-ings of the 12th Euromicro Conference on Real-Time
Sys-tems, Stokholm, Sweden, June 2000.
[5] H. Hassan, J. Simo, and A. Crespo. Flexible real-time
mo-bile robotic architecture besed on behavioural models.
En-gineering applications of Artificial Inteligence, 14(2):685–
702, 2002.
[6] G. Lipari.Resource Reservation in Real-Time Systems. PhD
thesis, Scuola Superiore S.Anna, 2000.
[7] C.L. Liu and J.W. Layland. Scheduling algorithms for
mul-tiprogramming in a hard-real-time environment. Journal of
the Association for Computing Machinery, 20(1), 1973.
[8] Luca Marzario and Giuseppe Lipari. Properties of the iris
scheduling algorithm. Technical Report ReTiS-TR04-02,
Scuola Superiore S. Anna, 2004.
[9] Luigi Palopoli, Tommaso Cucinotta, and Antonio Bicchi. Quality of service control in soft real-time applications. In Proc. of the IEEE 2003 conference on decision and control
(CDC02), Maui, Hawai, USA, December 2003.
[10] Raj Rajkumar, Kanaka Juvva, Anastasio Molano, and Shuichi Oikawa. Resource kernels: A resource-centric
ap-proach to real-time and multimedia systems. In
Proceed-ings of the 4th Real-Time Computing Systems and
