Spare Capacity Distribution Using Exact Response-Time Analysis

Attila Zabos, Robert I. Davis, Alan BurnsDepartment of Computer Science

University of York, UK

Michael Gonzalez HarbourComputers and Real-Time GroupUniversidad de Cantabria, Spain

Abstract

Real-time systems designed for use in dynamic openenvironments allow applications to enter and leave thesystem during runtime. This leads to changing run-time scenarios where the load and the spare capacityof hardware resources is influenced by the resource de-mand of running applications. Flexible real-time ap-plication components, with variable temporal parame-ters, can adapt their timing behaviour to these chang-ing runtime scenarios and improve both, their Qualityof Service (QoS) and the utilisation of system resources.In these open systems application components are of-ten designed independently of each other, introducingthe need for system management of resources at runtime.This management requires a mechanism to distribute theavailable system resources among the running applica-tion components, in a way that maximises resource us-age and increases QoS with respect to their importanceand temporal limits. This paper introduces a runtime al-gorithm for the distribution of spare capacity in flexiblereal-time systems. The efficiency of the presented algo-rithm is evaluated by empirical tests and performancemeasurements on embedded hardware.

1. IntroductionIn embedded real-time systems being developed to-

day it is common to find requirements for flexibilityand support for dynamic behaviour that are key drivingfactors in the design of their architectures and schedul-ing methods. Manufacturers of these embedded and re-source constrained systems are faced with the difficultyof providing guarantees on the real-time behaviour oftheir applications while at the same time handling flex-ibility and dynamic changes to the applications beingexecuted. Traditional real-time scheduling focuses onworst-case behaviour and using it for static configura-tions implies that a large amount of capacity, that is onlyused occasionally, is statically allocated in order to man-age dynamic changes in application demand. This con-flicts with the common requirement to be able to use themaximum possible amount of the available resources.

In this context of requirements for flexibility and sup-port for dynamic behaviour it is possible to design appli-cations that adapt themselves to the available resources,trading the quality of the response with the usage of re-

sources. In a system developed with this adaptivity inmind it is possible to maximise resource usage while try-ing to provide the best possible QoS.

The complexity of modern embedded systems is alsodriving the need to independently develop applicationsor application components that may join and leave thesystem during runtime. The available resources shouldbe dynamically adapted to these changing situations. Inmost platforms these dynamic changes may be frequent,but not as fast as the regular application periods. We mayhave new applications that stay in the system for secondsor minutes, while their own internal periods may be inthe milliseconds range.

2. MotivationFlexible applications come in many different forms.

For instance, multimedia systems need to process differ-ent kinds of video and audio streams that have highlyvariable computation times but require real-time pro-cessing and rendering. It is common that classic in-dustrial control applications, such as a robot control, getmixed together with multimedia activities when the pro-cess in which the robot is working requires image cap-ture and analysis, or remote video monitoring. Mobilephones and other embedded devices are turning them-selves into devices with multiple capabilities, includingaudio and video processing, GPS positioning, Internetnavigation, and more, in addition to their original radiolink capabilities. In these systems it is common that theuser starts or downloads new applications that must runtogether with the previous ones in an environment withlimited resources; and many of these applications havereal-time constraints.

Not all the applications running in the system are ca-pable of adapting or adapting equally to the availableresources. Most applications will require a minimumamount of resources to produce results of the minimumacceptable quality. Then, some applications may be ableto use additional resources, while others won’t. Of thosethat may adapt to the available resources the level ofadaptation may be different. For instance, a video playermay upgrade itself to a higher frame rate if more re-sources are available, changing the rate in a continuousway, up to a maximum level after which there is no per-ceived increase in the quality of the output. These typeof applications are referred to ascontinuous. A con-

1

trol algorithm on the other hand may have two versions:a fast one with a low quality output and one requiringmore computation time and providing a high quality out-put. In this case the system should allocate resources torun either one version or the other. Applications withthis type of behaviour are referred to asdiscrete. In gen-eral we find applications that can operate and generatevalid results at different frequencies (i.e. having a vari-able period), and/or handle different processing time as-signments (i.e. having a variable execution time).

The FRESCOR1 EU project is developing a middle-ware layer, that is placed on top of a real-time operatingsystem, with the capability of running multiple applica-tion components and scheduling the resources that theyneed to run. Each application component describes theresource requirements through one or morecontracts.These contracts specify the minimum resource require-ments and the way in which the component is able touse any additional available resources. The contract isnegotiated with the system in order to verify that theminimum resources required can be granted to the ap-plication component. Once a contract has been acceptedby the system avirtual resource (VR)(which has similarproperties to servers [10]) is allocated to the applicationcomponent. This VR represents a resource reservation,and manages the consumption of the resource by theapplication component to ensure that it can always getits allocated budget, and that it never exceeds it, so thatother application components can also run in the systemwith full temporal protection. On the other hand, whenapplication components complete processing and termi-nate, their VRs are destroyed. In this situation the util-isation of the processing hardware resource decreases,causing an increase of the spare capacity. As a conse-quence this spare capacity can be distributed to all of thecurrently active VRs by adapting their parameters.

Since the decision making process for the selection ofVR parameters is an online task, there will be a trade-offbetween the selection of optimal VR parameters and themaximal affordable processing time for this task.

These mixed application and system requirementsgive us the motivation for an online anytime algorithmthat is capable of distributing the spare capacity avail-able in a given system resource. This resource is com-monly a processor running tasks, but may also be a net-work transmitting message streams. The algorithm pre-sented in this paper is designed for fixed priorities, al-though we believe that it could be easily extended toother scheduling policies. We call this algorithm SCD,for spare capacity distribution.

The SCD algorithm is based on the idea of maximis-ing the utilisation of the processing hardware resource,whilst optimising the QoS of the applications as dictatedby their importance and weight. The two attributes, im-portance and weight, specified in each contract allow the

1Framework for Real-time Embedded Systems based onCOntRacts [10]

system integrator to control the spare capacity distribu-tion among active applications in the system by defin-ing their significance to the system and relative to eachother. The SCD algorithm maximises the hardware re-source utilisation by modifying the VRs’ temporal at-tributes during runtime (i.e., budget, period, deadlineand as a consequence their priorities as well), under thecondition that their temporal requirements are not vio-lated. The search for a feasible spare capacity distribu-tion is an incremental process and it is based on bisec-tion that provides the foundation for a simple and ef-ficient implementation of the presented algorithm in aruntime framework. Furthermore, the algorithm uses re-sponse time analysis to test for schedulability, and sincethis method is known to be exact no schedulability lossesare incurred by the test itself. The transition to a systemstate where the new temporal values and priority order-ing are used, is performed at a feasible time instant (e.g.,at anidle instant[21], or according to the idle instant op-timised protocol [11]). The protocol for the change fromone set of applications to another one, is currently a sub-ject of extensive research. The purpose of this paper isto present and evaluate the SCD algorithm.

3. Related workIn real-time systems, servers are often used as a

resource reservation mechanism to accomplish tempo-ral partitioning among running application components.They provide a budgeting mechanism, which preventsmalicious applications from affecting the operation ofother applications in the system. Although server con-cepts [19, 20, 16] have been introduced to improve theresponse time of aperiodic tasks, their application hasbeen adapted to provide temporal partitioning amongtasks [1].

The composition of independently developed appli-cations has been considered by Deng et al. [9]. Theydefined a scheme for a two-level hierarchically sched-uled open system. Their work was based on dynamicscheduling. Kuo and Li [13] later adapted Deng’s ap-proach [9] to a fixed-priority operating system scheduler.

The FIRST2 project addressed the need for a schedul-ing framework that could handle applications with vary-ing processing demand [2]. The algorithm to adapt theserver parameters used utilisation-based schedulabilitytests which are not exact, thus causing a lower resourceusage in the system.

Utilised in this paper are the improvements to the ex-act schedulability test for fixed-priority tasks that werepresented in [8] by Davis et al. and in [7] by Davis andBurns. In our case, the exact schedulability test is ap-plied to VRs and determines whether the full amount ofeach VR’s budget can be utilised before its deadline bythe associated application tasks.

The server attributes,importanceandweight, that arerelated to the spare capacity distribution, were intro-

2Flexible Integrated Real-Time Systems Technology

2

duced in [2]. They were further adopted for VRs in [10].These attributes allow the applications to influence theoutcome of the spare capacity distribution.

Rosu et al. [18] described an adaptive resource al-location mechanism for distributed real-time systems.The expected application resource needs are specifiedby configurations. The choice of the appropriate config-uration and the resulting resource allocations dependson environmental states, availability of resources in thesystem and the achievable system performance. The re-source allocation is carried out as a response to events inthe environment and changes in the processing demandof a complex distributed application.

Resource adaptive soft real-time systems were con-sidered by Lin et al. [15]. Here, the Rate-Based EarliestDeadline (RBED) scheduler uses a heuristic algorithmto increase the overall benefit by adjusting the QoS levelof the adaptive soft real-time tasks. Since the resourcedemand varies with the QoS levels, the processing of theadaptive tasks is adjusted so that they can be accommo-dated on the available resources.

An elastic tasking model has been defined by But-tazzo et al. [5, 6], where the task periods can be adjustedin order to adapt to different load conditions.

Rajkumar et al. [17] introduced a QoS based resourceallocation model. Resource allocation to applications ismade in terms of resource utilisation, but it is the appli-cation’s responsibility to choose the appropriate budgetand period. The algorithm that determines the resourceallocation, requires QoS functions representing resourcedependent changes of the application’s contribution tothe system value. However, the definition of such a func-tion is not always straightforward.

Almeida et al. [3] presented an approach to adaptduring runtime the temporal parameters of flexible pe-riodic tasks. Each task’s execution time and period isexpressed as ann-tuple vector forn different QoS levels.From the set of all possible combinations of task param-eters, a set of schedulable configurations is deduced byan offline method. This set is used by the online QoSmanager to adapt the task parameters.

The SCD algorithm presented in this paper addressesthe following issues of previous work: The resource al-location model in [18] is designed for high performancedistributed systems, rather than for embedded real-timesystems. Compared to the resource allocation modelin [15], we focus on fixed-priority scheduled systems.The elastic task model [5, 6] addresses resource adapta-tion by changing task periods but not their allocated pro-cessing times. In contrast to the scheduling frameworkin [2], the SCD algorithm can be used as an anytime al-gorithm, and terminate after a maximum execution timeproviding non-optimal but schedulable VR parameters.Furthermore, loss of distributable spare capacity due tothe schedulability test of VRs is prevented by using anexact test. The adaptation method presented in [3] con-flicts with the notion of open systems due it assumption

of static set of tasks that are known before runtime, andis therefore not well applicable to open systems.

4. System modelIt is assumed that a set of flexible application compo-

nents{A1, A2, · · · , Am} are mapped to a set of virtualresourcesΓ = {S1, S2, · · · , Sn}, with m ≤ n.

The tasks of each flexible application component aremapped to and are executed by one or more VRs. Inthe former case the application’s taskset is mapped toone VR, where in the latter case the taskset is dividedinto subsets and each subset is mapped to a VR. Unlessa one-to-one mapping of task to VR is used, a hierar-chical scheduler can be utilised to determine the orderof execution of tasks on the same VR. The presence ofone or more tasks on a single VR does not affect thespare capacity distribution, as it is done solely for VRsaccording to their requirements specified in their respec-tive contracts.

The tasks of one application component are notmixed with tasks of other components in the same VR,in order to ensure the temporal protection among them.

Eachvirtual resourceSi is characterised by its pro-cessingbudgetCi, replenishmentperiod Ti, deadlineDi, importanceIi andweightWi.

Each virtual resourceSi is either defined as a contin-uous or discrete VR [10] depending on the domain of itstemporal parameters:• For continuous VRs, the operational ranges of pe-

riod and budget are defined by a lower and upperbound, [T min

i , T maxi ] and [Cmin

i , Cmaxi ], respec-

tively. The actual value assigned to a VR’s temporalattribute can take any value from within correspond-ing operational ranges. The budget and period ofcontinuous VRs are independent of each other andtherefore can be adjusted independently.

• For discrete VRs a finite set of(Cj , Tj , Dj)triples are defined. Only values from this set of(Cj , Tj , Dj) triples can be assigned to discrete VRs’temporal attributes. This definition implies that tem-poral attribute values are linked to each other.

The budgetCi denotes the maximal processing timethat can be consumed by a VR before it is suspended.The budget is replenished to its full amount after everyperiodTi.

The deadlineDi of a VR specifies the relative timefrom the point when it has been released until it has tocomplete the supply of its budget to the associated appli-cation component. The deadlineDi of a virtual resourceSi can be defined to be:1. equal to its periodTi for a continuous VR,2. equal toDj from the selected(Cj , Tj, Dj) triple for

a discrete VR or,3. a constant value for both types of VRs.

Additionally, it is assumed that the deadline of a VR isalways less than or equal to its period,Di ≤ Ti.

The priorityPi of a VR Si is assigned to it using a

3

fixed-priority assignment policy. The priority of VRsmay change during the spare capacity distribution, butit remains fixed during the steady operational state ofthe system. If a VR’s temporal attribute, which is usedby the priority assignment policy, is modified during theexecution of the SCD algorithm, then the priority as-signment has to be updated. Nevertheless, the constraintDi ≤ Ti is not violated by the modification of the pe-riod.

For a VRSi two of its attributes,importance levelIi andweightWi, are used to influence the outcome ofthe SCD algorithm. The precedence, in which the sparecapacity is assigned to VRs is determined by the impor-tance levelIi of the VRs. For the spare capacity distri-bution, VRs with the same importance level are logicallycombined into groups. A groupGl is the set of all VRswith the same importance levell (see Equation1).

Gl = {Si ∈ Γ|Ii = l} (1)

Each major iteration of the SCD algorithm is limitedto a groupGl of VRs. Usually several major iterations ofthe SCD algorithm are required until a solution is foundfor the given setΓ of VRs.

The weight attribute Wi influences the fraction ofthe spare capacity that a VR will get. The fair sharevalue [12] denoted asHi is used as a factor to determinethe fraction of additional capacity that a virtual resourceSi will get when a certain amount of spare capacity isdistributed at the currently examined importance levelIC (see Equation 2). In this equation,Ij denotesSj ’simportance level.

Hi =Wi∑

∀j:Ij=IC

Wj

(2)

The usage of shared resources and the consequentblocking factors have no direct impact on the SCD algo-rithm itself. Therefore, there are neither assumptions norrestrictions on the usage of shared resources, since thecorresponding blocking factors affect only the schedula-bility test.

The utilisation caused by a virtual resourceSi on aprocessor is the amount of assigned budgetCi per re-plenishment periodTi. The processor’s capacity that isunused by VRs is denoted asspare capacity.

The processor’s utilisation is calculated as the sum ofall VRs’ utilisation. The largest utilisation of the pro-cessor, determined by the SCD algorithm, at which theset of VRs in the system becomes unschedulable is re-ferred to as thebreakdown utilisation. The breakdownutilisation mainly depends on the VR types in the sys-tem. With only continuous VRs it is likely that close to100% processor utilisation is achieved since the utilisa-tion assigned to these VRs can be gradually increased.Whereas with discrete VRs the largest processor utilisa-tion is likely to be significantly less than 100% due tothe limited number of VR budget and period values.

5. Spare capacity distribution algorithm

5.1. SCD algorithm characteristics

The intention of the SCD algorithm is to allocate asmuch as possible of the processor’s spare capacityUs toVRs in the system. Of course, after the application of theSCD algorithm, the set of VRs with their new utilisationvalues has to be schedulable.

The utilisation probeUp is the amount of spare ca-pacity that can be distributed at once among the VRs atthe processed importance level.

Since the presented algorithm is a search based ap-proach, feasibility of various probe values need to betested. An efficient approach to find a feasible probevalueUp ∈ {0, 0 + δUp, . . . , Us − δUp, Us} is providedby bisecting the interval[0, Us] and applying the binarysearch algorithm to it. The binary search algorithm isfast, has minimal memory requirements and the requiredprocessing resources are also low.

For a given set of VRs, the maximal distributablespare capacity can be found within1 + ⌈log2N⌉ iter-ations, whereN is the number of potential values forUp. Given the granularityδUp of the interval[0, Us],the number of potential values forUp can be calculatedasN = Us

δUp. For example, a typical value of 1% for

δUp and the possible maximum value forUs of 100%,limits the number of potential valuesN for Up to 100.By applying the binary search on the 100 possible val-ues, a feasibleUp can be determined by checking theschedulability of1+ log2100 = 8 different spare capac-ity distribution scenarios.

A virtual resourceSi is defined to be available/activefor spare capacity distribution if it is able to increase itsutilisation due to the following conditions:• During the last iteration of the spare capacity distri-

bution,Si did not render the system unschedulable,• Si has not reached its predefined maximal utilisa-

tion and can therefore utilise a higher spare capacityallocation.

In order to determine the optimality of the SCD al-gorithm the following assumption is made, driven bythe FRESCOR project: The spare capacity supplied athigher importance levels is considered infinitely morevaluable than at lower importance levels. This impliesthat different importance levels are incomparable. TheSCD algorithm starts with the spare capacity distributionat the highest importance level. Spare capacity is sup-plied by decreasing the periods and increasing budgetof VRs at this importance level. Only after all possiblespare capacity has been allocated at the highest impor-tance level, does the algorithm considers the next high-est level and so on. Hence, under the assumption thatimportance levels are incomparable, the SCD algorithmprovides the optimal spare capacity distribution.

The schedulability test used by the SCD algorithmis an exact test for fixed-priority scheduled uniprocessorreal-time systems [8]. Before the SCD algorithm is ap-

4

plied to the VRs in the system, the schedulability usingtheir minimal timing requirements is ensured. Changesto the set of the VRs in the system are only permitted ifthe changed set remains schedulable using the minimaltemporal requirements of the VRs.

5.2. Description of the SCD algorithm

As input, the SCD algorithm requires a priority or-dered list of VRs along with their temporal attributes.This priority ordered list (Π) contains VRs that want tobenefit from the additional assignment of spare capacity.Π is also used as the output list.

The SCD algorithm starts with the VRs’ temporalparameters set to their minimum timing requirements.The minimum timing requirement is either the minimumbudgetCmin

i and largest periodT maxi in the case of a

continuous VR, or(Cj , Tj , Dj) triple with the smallestutilisation in the case of a discrete VR. A soon as theSCD algorithm finds an intermediate or final solution,the new temporal values of the VRs are stored inΠ.

With the SCD algorithm, at each importance level thesearch for the largest feasibleUp is carried out in orderto determine a feasible spare capacity distribution (seeAlgorithm 1).

InOut: Π: Priority ordered list of VRsforeach importance levell (in decreasing order)do

DetermineHi for all Sli that are active;

while not all possibleUp values checkeddoCalculate∆Ui (see Equation 3) and increase thecurrent utilisation ofSl

i to Unewi by ∆Ui;

DetermineSli new parameters using Algorithm 2;

Determine new priority ordering for theschedulability test;if all VRs are schedulablethen

Store new priority ordering and temporalvalues of all activeSl

i in Π;

Algorithm 1: Spare capacity distribution

Each major iteration of the SCD algorithm is limitedto VRs at a particular importance level, starting at thehighest level.

The steps of the SCD algorithm that are executed atevery importance level are as follows:1. Calculate the fair share values.

The fair share valueHi of every active virtual re-sourceSi at the currently processed importancelevel is calculated using Equation 2. This value isused to determine the fraction of capacity that willbe assigned to the active VRs.

2. Search for a feasible spare capacity distribution.The algorithm considers only VRs that are active(i.e. capable of accepting more than their currentutilisation) at the currently examined importancelevel. Using binary search (represented by thewhile-loop condition in Algorithm 1), the distributablespare capacityUp is narrowed down to the largestvalue at which the system is schedulable, but wherean additional amount (δUp) of spare capacity assign-

ment (i.e. Up + δUp) would cause an infeasibleschedule.For each utilisation probeUp, the temporal param-eters of active VRs at the currently examined im-portance level are recalculated using Algorithm 2,whereUnew

i denotes the increased utilisation ofSi

by ∆Ui.

∆Ui = Up · Hi (3)

3. Increase active VRs’ utilisation.If a schedulable spare capacity distribution has beenfound, the new VR temporal parameters are stored inthe output listΠ regardless of whether these valuesare intermediate or final.

One possible approach to determine the budget andperiod of a continuous VRSi (with an increased utili-sation equal toUnew

i ) is presented in Algorithm 2. Ifpossible, the VR’s smallest periodT min

i is used and itsbudget is calculated accordingly. If it is not feasible touse its smallest period, then the minimum budgetCmin

i

is fixed first and the period is calculated accordingly.Under both circumstances, the calculated values are re-stricted to the specified interval for the budget and theperiod, respectively.

if (Cmini /T min

i ) > Unewi then

Ci = Cmini ;

Ti = min`

(Cmini /Unew

i ), T max´

;else

Ti = T mini ;

Ci = min`

(T mini · Unew

i ), Cmax´

;

Algorithm 2: Budget and period calculation

For a discrete VR, the utilisation values of its dif-ferent discrete(Cj , Tj , Dj) triples are calculated. Thenthe(Cj , Tj, Dj) triple with the biggest utilisation value,which is less than or equal toUnew

i , is selected.

5.3. Priority assignment

In this paper, the deadline-monotonic priority assign-ment [14], as provided by the FRESCOR framework,was used for the empirical evaluation. The implemen-tation of the SCD algorithm considers two different VRconfigurations for the deadline:1. Virtual resource’s deadline is equal to its period,2. Virtual resource’s deadline is constant.

In the case that a VR’s deadline is configured to beequal to its period, whenever the period is changed dur-ing the spare capacity distribution its deadline is ad-justed accordingly and priority reordering is carried out.

Furthermore, the schedulability test of the VRs is car-ried out in decreasing order of their priorities.

6. Empirical evaluation6.1. Test data generation

To evaluate the performance of the SCD algorithm,VR sets were generated where the variation of particularisolated test-case parameters was examined. For each

5

of these VR sets 100000 different configurations werecreated. Each configuration consists of the predefinednumber of VRs (i.e. 5, 10, 15, . . . , 50) for which ran-domly generated VR parameters (i.e. budget, period anddeadline) were created.

The approach, presented by Bini and Buttazzo [4], tocreate tasks parameters for a given maximal utilisation(subsequently referred to as theInitial Target Utilisation(ITU)), was used in this work to generate the random VRparameters.

The ITU was chosen so that the performance of thespare capacity distribution could be observed in differentscenarios where more or less spare capacity was avail-able. The chosen ITUs were 30%, 50% and 80%. Be-fore the VR sets were processed by the SCD algorithm,it was ensured that the generated sets were schedulableat the chosen ITU. Test-cases with initially unschedula-ble VR sets were not considered in the measurement andthey were replaced with a new and schedulable VR set.

The period and budget of the VR is derived from itsrandomly generated utilisation value. First, the VR’s pe-riod is chosen according to a uniform random distribu-tion from a randomly selected period magnitude range(i.e. [103, 104], [104, 105], [105, 106] or [106, 107]).Given the VR’s utilisation and period, the calculation ofits budget is straight forward.

To take advantage of the flexibility of VRs, a defini-tion for the upper and the lower bound of their utilisa-tion ranges is required. For each VR the initially gener-ated random utilisation values are considered in the testsas their lower utilisation bounds. This lower utilisationbound is used to derive the VR’s minimum budget andmaximum period. The minimum budget is then multi-plied and the maximum period is divided by a factor inorder to determine the VR parameters (i.e. maximumbudget and minimum period) for its upper utilisationbound. A factor of 2.0 for the 30% ITU, and a factorof 1.5 for 50% and 80% ITU was used.

For discrete VRs, additional to their lower and up-per utilisation bounds, a random number of intermediateutilisation values were generated. The number of inter-mediate values was in the range of 1 to 3, where 5 isthe maximum number of discrete temporal attributes de-fined by the FRESCOR framework.

6.2. Experiment evaluation

This section evaluates the data, which was collectedfrom various measurements by varying different param-eters as indicated in Section 6.1. The diagrams showthe progress of the spare capacity distribution as a func-tion of the number of ceiling operations needed by theschedulability analysis, a useful proxy for algorithm ex-ecution time [8]. This section uses the number of ceil-ing operations to give insight into the complexity of thealgorithm. Section 7.2 extends this information by map-ping it onto absolute time. In the following, the termnumber of ceiling operationswill be referred to asnum-

ber of iterations.The presented experiments contain a mixed set of

VRs (both continuous and discrete). The only exceptionis the experiment in which the impact of the differenttemporal attribute types (i.e. discrete or continuous) onthe SCD algorithm is examined.

For the sake of clarity, the diagram types used to sup-port the empirical evaluation are introduced in Figure 1.Of main interest are the following properties of the SCDalgorithm: how fast can the spare capacity be distributedand the number of iterations required by the algorithmto terminate. The average increase of processor’s util-isation as the SCD algorithm progresses, is depicted inFigure 1a. The percentage of test-cases terminated bya certain number of iterations is depicted in Figure 1b.This figure can also be interpreted as the probability thatthe SCD algorithm will terminate within a given numberof iterations for a given number of VRs.

For all experiments the SCD algorithm was executeduntil it terminated itself. The processor’s utilisationachieved in this way is the highest schedulable utilisa-tion of the active VRs in the system.

In Figure 1 the effect of the number of VRs on theSCD algorithm is examined. Figure 1a shows that therate of the average utilisation increase from an ITU of50% slows up when the number of VRs in the system isincreased. The number of iterations required to termi-nate with a particular probability also increases with thenumber of VRs (see Figure 1b). The diagrams indicatethat more iterations are required to find a feasible sparecapacity distribution as the number of VRs in the systemincreases. This comes about due to the increased num-ber of schedulability tests that are required for each VRutilisation level.

In dynamic real-time systems the processor’s utilisa-tion at which application components are submitted intothe system cannot be predicted in advance. Therefore,the impact of the initial processor’s utilisation on theprogress of the SCD algorithm was also considered (seeFigure 2). In Figure 2a it can be observed that the ITUhas an effect on the processor’s utilisation increase onlyat the beginning of the algorithm. In the long term (i.e.above 2000 iterations) the ITU becomes irrelevant andthe utilisation increase is dominated by the number ofVRs in the system. The probability for the terminationof the SCD algorithm is influenced from the beginningby the number of VRs and the ITU has only a negligi-ble effect (see Figure 2b). The effect of the ITU is smallsince the number of schedulability tests that are carriedout during the runtime of the SCD algorithm stay nearlyidentical for various ITUs.

The VR’s temporal attributes can be either of contin-uous or discrete type. Hence, there can be three differentVR sets in the system. Only continuous, only discreteor a mixed set of VRs. Our experiments show that thetemporal attribute type has only a minor effect on the in-crease of the processor’s utilisation and the runtime of

6

0

20

40

60

80

100

100 1000 10000Ave

rage

util

izat

ion

[%]

Number of iterations

50

40

30

20

15

10

5

(a) Average utilisation

0

20

40

60

80

100

100 1000 10000 100000

Com

plet

ed s

ets

[%]

Number of iterations

50

40

30

20

15

10

5

(b) SCD algorithm termination rate

Figure 1. Number of VRs: 5, 10, ..., 50

0

20

40

60

80

100

100 1000 10000Ave

rage

util

izat

ion

[%]

Number of iterations

5080

2580

1080

5050

2550

1050

5030

2530

1030

(a) Average utilisation

0

20

40

60

80

100

100 1000 10000 100000

Com

plet

ed s

ets

[%]

Number of iterations

5080

5050

5030

2580

2550

2530

1080

1050

1030

(b) SCD algorithm termination rate

Figure 2. ITU: 30%, 50% and 80%

the SCD algorithm. For space reasons, these results arenot included in this paper but are available in a technicalreport [22].

The VR assignment to importance levels has beenanalysed in two scenarios (see Figure 3). In one sce-nario, the VRs have been randomly distributed among

the available importance levels. In the other scenario,they have been assigned to a single importance level.Figure 3a shows that the use of a single importance levelhad a negative effect on the processor’s utilisation in-creases. These are much slower although in long term,the processor’s utilisation values for both scenarios con-verge towards each other. On the other hand, the num-ber of iterations required for the termination of the al-gorithm decreased if a single importance level was used(see Figure 3b). In this case, performing the schedula-bility test for the empty importance levels was avoided,which led to the reduction in iterations.

0

20

40

60

80

100

100 1000 10000Ave

rage

util

izat

ion

[%]

Number of iterations

50s

50d

25s

25d

10s

10d

(a) Average utilisation

0

20

40

60

80

100

100 1000 10000 100000

Com

plet

ed s

ets

[%]

Number of iterations

50d

50s

25d

25s

10d

10s

(b) SCD algorithm termination rate

Figure 3. Importance level allocation

The measured data, presented in this section, revealthat the performance of the SCD algorithm is mainly in-fluenced by the number of VRs in the system.

7. Performance evaluationThis section provides information about the embed-

ded hardware that was used for the performance mea-surements and the absolute values for the executiontimes obtained. Additionally, using a pragmatic ap-proach, a linear upper bound equation is derived for theexecution time of the SCD algorithm. This allows us todetermine the required budget for the SCD algorithm, inorder to provide a complete or partial solution for thespare capacity distribution of the system.

7.1. Test environment

The empirical evaluation, which was presented inSection 6, is extended by performance measurementson an embedded platform. The intention of this task is

7

to determine which parameters influence the SCD algo-rithm’s execution time.

In order to exclude operating system and other un-desirable overhead, an embedded system was configurein a way that only the spare capacity distribution wasexecuted. This provided the facility to obtain absolutevalues for the execution time of the SCD algorithm.

The embedded platform consisted of an MPC555 mi-crocontroller running at 40 MHz system clock.

To create the target executable file, a developmentenvironment comprising the GNU C compiler andRapiTime version 1.2, a tool for worst-case executiontime analysis, was used. The executable files were op-timised by the compiler using the option-O2. To avoidfalsification of the measurements by intermediate per-formance monitoring of the SCD algorithm, only end-to-end execution times were recorded.

Due to the limited performance of the embedded sys-tem, the number of test cases used was reduced to 3000randomly generated VR sets for each fixed number ofVRs in the set (i.e. 5, 10, 15,. . . , 45, 50 VRs). The ITU(i.e. 30%, 50% or 80%) and the type of the VR sets(only continuous, only discrete or mixed type) were ran-domly created for each of the 3000 sets. Nevertheless,sufficient data was captured to analyse the behaviour ofthe SCD algorithm on real hardware.

7.2. Measurement

During the design phase of real-time systems, infor-mation is required about the expected complexity of theSCD algorithm. In the following, an upper bound equa-tion will be defined that allows engineers to determineduring the design phase the required amount of budgetfor the SCD algorithm.

As an initial step, the dependency of the SCD al-gorithm’s execution time on the number of iterationsand VRs in the system was examined. Figure 4 showsfor different numbers of VRs the execution time plottedagainst the number of iterations and the correspondingregression lines. Since the scatter of the measured valuesalong the x-axis is very narrow for the test-cases with 5,10 and 15 VRs, their regression lines are omitted.

To determine the necessary values for the linear up-per bound equation, the least-squares linear regressionmethod was applied to the collected data. Table 1 sum-marises the parameters of the regression lines from Fig-ure 4. The data in Table 1, as well as visual inspection ofFigure 4 indicate that the slope of each regression line isvery similar. This observation suggests a linear depen-dency of execution time on the number of iterations.

But a single linear equation is not sufficient to expressthe execution time of the SCD algorithm. Since the re-gression lines do not overlap but have an offset betweenthem, the dependency of this offset on the number ofVRs has been examined as well. In Figure 4 the intersec-tion points of the regression lines with z-y-plane showsthat the offset also increases linearly with the number of

Table 1. Regression line parametersVR# Function Slope

`

10−3´

Y-axis offset

50 f50(x) 1.5425 99.28745 f45(x) 1.5520 87.23840 f40(x) 1.5579 75.51935 f35(x) 1.5722 64.30830 f30(x) 1.5862 53.02225 f25(x) 1.6263 42.27720 f20(x) 1.6386 32.486

VRs in the system.The equation, which describes the y-axis intersection

of the execution time regression lines against the numberof VRs, was also determined via linear regression (seeEquation 4).

y0(v) = 2.381 · v − 21.397 (4)

The former analysis reveals that the execution timedepends mainly on two parameters. Figure 4 shows theexecution times plotted along the y-axis. The x-axis rep-resents the number of iterations and the z-axis the num-ber of VRs. The observable linear behaviour of the plot-ted data along the x-axis as well as along the z-axis sug-gests the definition of the execution time upper bound asa plane equation with the number of iterations and VRsas independent variables.

0 20000

40000 60000

80000 100000

120000 140000

0 5 10 15 20 25 30 35 40 45 50 0

50 100 150 200 250 300 350

Exe

cutio

n tim

e [m

s]

Iterations

Virtual resources

Figure 4. Execution time samples

The general form of the plane equation can be definedasC(n, v) = a1 · n + a2 · v, with C(n, v) representingthe execution time,n the number of iterations andv thenumber of VRs.

Next, the coefficients,a1 anda2, for the plane equa-tion were specified. They were derived from the datathat was obtained by measurements on the embeddedplatform.

The first coefficient,a1, was determined by calculat-ing the average slope of the execution time regressionlines. The average value is approximately1.58224 ·10−3, but for ease of use, this value has been roundedup to1.6 · 10−3.

Finally, the value of the second coefficient,a2, wasdefined. Based on Equation 4 and on the data of Fig-ure 4, the value of2.8 was determined fora2. This valuewas obtained by the application of pragmatic steps in or-

8

der to simplify Equation 4. The aim was to preserve justa single factor that expresses the dependency betweenthe number of VRs, and the y-axis intersection of thelines that represent the execution time upper bounds foreach set of VRs. The value of coefficienta2 was in-creased from the value starting at2.381 (as specified byEquation 4) until the regression lines in Figure 4 becamethe upper bound on the measured execution times forthe corresponding set of VRs (i.e. every execution timesample was below the upper bound).

Using this information, an execution time upperbound equation for the SCD algorithm was derived (seeEquation 5). The equation represents a pragmaticallyderived execution time upper bound for the MPC555 mi-crocontroller that was used to carry out the performancemeasurements.

C(n, v) = 0.0016 · n + 2.8 · v (5)

To get an idea of how the execution time upper boundincreases with system complexity, the upper bound wasplotted against the number of VRs in the system and thenumber of iterations. The data that was generated bythe application of Equation 5 spans a plane in three di-mensional space. The plane in Figure 5 illustrates theexecution time upper bound of the SCD algorithm. Forthe sake of clarity contour lines are rendered at 50 msintervals.

0 50 100 150 200 250 300 350

0 20000

40000 60000

80000 100000

120000 140000

0 5 10 15 20 25 30 35 40 45 50 0

50 100 150 200 250 300 350

Exe

cutio

n tim

e [m

s]

Iterations

Virtual resources

C(3000,5)C(9000,10)

C(18000,15)

C(32000,20)

C(45000,25)=142 ms

C(58000,30)

C(77000,35)

C(98000,40)

C(135000,45)

Figure 5. Execution time upper bound

In order to determine the required budget for the SCDalgorithm, the expected maximal number of VRs in thesystem and the granted maximal number of iterationsfor the runtime of the algorithm has to be specified.The parameter, maximal number of iterations, also in-fluences the probability of the SCD algorithm terminat-ing within the determined budget. The probability oftermination within a certain number of iterations has al-ready been investigated during the empirical evaluationin Section 6.2. It can be summarised as follows.

Table 2 shows the maximal number of iterations thatwere required by the SCD algorithm to terminate for99.99%, 99.90%, 99.00% and 90.00% of the test-cases.There is a slight difference in the number of required it-erations for the algorithm among the test-cases that wereperformed with 30%, 50% and 80% ITU; but the great-

est observed values were chosen.

Table 2. Number of iterationsVR# 99.99% 99.90% 99.00% 90.00%

5 3000 2000 1000 100010 9000 6000 4000 300015 18000 14000 10000 600020 32000 24000 18000 1200025 45000 36000 27000 1800030 58000 49000 38000 2600035 77000 66000 51000 3600040 98000 86000 68000 4900045 135000 108000 85000 6200050 157000 132000 107000 77000

Based on the data that was collected during the em-pirical evaluation and the performance measurements,the required budget for the SCD algorithm can be de-rived for a real-time system using an MPC555 micro-controller and a specified maximum number of VRs.

As an example, we now determine the budget for twodifferent configurations. First, the budget for the SCDalgorithm on a system with a maximum of 5 applicationcomponents is calculated. The budget is chosen suchthat the algorithm can terminate in 99.99% of the cases.Applying the information from Table 2 in Equation 5,provides a budget estimate ofC(3000, 5) = 0.0016 ·3000 + 2.8 · 5 = 18.8ms. For the second example, weassume a system with at most 25 components. Again,the budget should allow the SCD algorithm to terminatein 99.99% of the cases. Hence, the estimated budget isC(45000, 25) = 0.0016·45000+2.8·25 = 142ms. Thecalculated values for the examples are also illustrated inFigure 5.

The two coefficients,a1 anda2, of the linear equationdepend on various hardware factors, like the availabilityand size of data caches, data bus bandwidth, externalmemory speed, etc. They also depend on the location(i.e. internal or external memory) of the relevant pro-cessing data. Therefore, the linear equation representingan upper bound for SCD algorithm’s execution time, hasto be individually derived for each hardware platform.This can however easily be performed using a suitableprogram for calibration, such as the one used to gener-ate the results presented here.

8. ConclusionIn this paper we presented an easily and efficiently

implementable algorithm for the distribution of a pro-cessing resource’s spare capacity. The contribution canbe summarised as:• an anytime SCD algorithm that can generate useful

results even if the algorithm’s execution time is lim-ited,

• runtime adaptation of continuous and discrete VRtemporal parameters (i.e. budget and period),

• preventing schedulability test based inefficiency us-ing an exact test.

9

The efficiency of the SCD algorithm was examinedby empirical evaluation and performance measurementson an embedded platform.

The performance evaluation of the SCD algorithmshows that, for example in a system with up to 25 mixedVRs, the algorithm terminates in 99.99% of the caseswithin 45000 iterations, and within the same number ofiterations the processor reaches an average utilisation of98%. Based on the upper bound equation (Equation 5),the worst-case execution time for 45000 iterations and25 VRs is equivalent to 142 ms on an MPC555 micro-controller with a system clock of 40 MHz. The MPC555is not however a sufficiently powerful processor to sup-port 25 application components.

On faster processors, the cost for one iteration of theSCD algorithm, as well as the overall execution time,decreases. Therefore the complexity of a system, mea-sured in terms of the number of active VRs, for whichthe SCD algorithm can be considered applicable, in-creases. For example, a processor with approximately10 times the performance of a 40MHz MPC555 mightbe used in Avionics or Telecommunications applicationsthat need to support 10 to 25 application components. Inthis case, such a processor would require at most 15msto execute the SCD algorithm.

The SCD algorithm shown in this paper has been in-tegrated into the FRESCOR framework, giving it thecapability to distribute spare capacity among differentapplication components with the objective of fully us-ing the available processor capacity and maximising theQoS. While the algorithm is based on the current imple-mentation of FRESCOR on fixed priorities, we believethat it is easily extensible to other scheduling policiesand tests. As future work we will investigate the modechange protocols used to make effective the calculationof a new resource allocation as a result of the SCD algo-rithm. Furthermore, the allocation of multiple resources(e.g. processor, network bandwidth, memory, etc.) toapplication components and their interdependency willbe examined.

AcknowledgementsThis work was funded in part by the EU FRESCOR

project (contract number FP6/2005/IST/5-034026). Wewould also like to thank Rapita Systems Ltd.3 for pro-viding the necessary equipment and tools for the per-formance measurements. Furthermore, we would liketo thank Daniel Sangorrın Lopez for his valuable com-ments.

References[1] L. Abeni and G. C. Buttazzo. Integrating multimedia appli-

cations in hard real-time systems. InProceedings of the 19thIEEE Real-Time Systems Symposium, pages 4–13, Madrid,Spain, Dec 1998.

3Rapita Systems Ltd. Available at http://www.rapitasystems.com(8 January 2009)

[2] M. Aldea Rivas, G. Bernat, I. Broster, A. Burns, R. Do-brin, J. M. Drake, G. Fohler, P. Gai, M. Gonzalez Harbour,G. Guidi, T. L. J. Javier Gutierrez Garcia, G. Lipari, J. L.M. P. Jose M. Martınez, J. C. Palencia Gutierrez, and M. Tri-marchi. Fsf: A real-time scheduling architecture frame-work. In Proceedings of the 12th IEEE Real-Time andEmbedded Technology and Applications Symposium, pages113–124, 2006.

[3] L. Almeida, S. Fischmeister, M. Anand, and I. Lee. Adynamic scheduling approach to designing flexible safety-critical systems. InProceedings of the 7th ACM & IEEEinternational conference on embedded software, pages 67–74, 2007.

[4] E. Bini and G. C. Buttazzo. Measuring the performance ofschedulability tests.Real-Time Systems, 30(1-2):129–154,2005.

[5] G. C. Buttazzo, G. Lipari, and L. Abeni. Elastic taskmodel for adaptive rate control. InProceedings of the IEEEReal-Time Systems Symposium, pages 286–295, Washing-ton, DC, USA, 1998. IEEE Computer Society.

[6] G. C. Buttazzo, G. Lipari, M. Caccamo, and L. Abeni. Elas-tic scheduling for flexible workload management.IEEETransactions on Computers, 51(3):289–302, 2002.

[7] R. I. Davis and A. Burns. Response time upper bounds forfixed priority real-time systems. InProceedings of the 29thIEEE Real-Time Systems Symposium, 2008.

[8] R. I. Davis, A. Zabos, and A. Burns. Efficient exact schedu-lability tests for fixed priority real-time systems.IEEETransactions on Computers, 57(9):1261–1276, 2008.

[9] Z. Deng, J. W.-S. Liu, and J. Sun. A scheme for schedulinghard real-time applications in open system environment. InProceedings of the 9th Euromicro Workshop on Real-TimeSystems, pages 191–199, Toledo, Spain, Jun 1997.

[10] M. Gonzalez Harbour and M. T. de Esteban. Architectureand contract model for integrated resources. Technical Re-port D–AC.2v1, Universidad de Cantabria, 2007.

[11] M. Gonzalez Harbour, D. S. Lopez, and M. T. de Esteban.Mode change protocol for budget changes in contract-basedscheduling. Technical report, Universidad de Cantabria,2008.

[12] J. Kay and P. Lauder. A fair share scheduler.Communica-tions of the ACM, 31(1):44–55, 1988.

[13] T.-W. Kuo and C.-H. Li. A fixed-priority-driven open en-vironment for real-time applications. InIEEE Real-TimeSystems Symposium, pages 256–267, 1999.

[14] J. Y.-T. Leung and J. Whitehead. On the complexity offixed-priority scheduling of periodic real-time tasks.Per-formance Evaluation, 2(4):237–250, Dec 1982.

[15] C. Lin, T. Kaldewey, A. Povzner, and S. A. Brandt. Diversesoft real-time processing in an integrated system. InPro-ceedings of the 27th IEEE International Real-Time SystemsSymposium, pages 369–378, 2006.

[16] J. Liu. Real-Time Systems. Prentice-Hall, Inc., 2000.[17] R. R. Rajkumar, C. Lee, J. P. Lehoczky, and D. P. Siewiorek.

A resource allocation model for qos management. InIEEEReal-Time Systems Symposium, pages 298–307, 1997.

[18] D. Rosu, K. Schwan, S. Yalamanchili, and R. Jha. On adap-tive resource allocation for complex real-time application.In Proceedings of the 18th IEEE International Real-TimeSystems Symposium, pages 320–329, 1997.

[19] L. Sha, J. P. Lehoczky, and R. R. Rajkumar. Solutions forsome practical problems in prioritizing preemptive schedul-ing. In Proceedings of the 7th IEEE Real-Time Sytems Sym-posium, pages 181–191, 1986.

[20] B. Sprunt, L. Sha, and J. P. Lehoczky. Aperiodic taskscheduling for hard real-time systems.Real-Time Systems,1(1):27–60, 1989.

[21] K. W. Tindell and A. Alonso. A very simple protocol formode changes in priority preemptive systems. Technicalreport, Universidad Politecnica de Madrid, 1996.

[22] A. Zabos, R. I. Davis, and A. Burns. Utilization basedspare capacity distribution. Technical Report YCS-2008-427, University of York, 2008.

10