**3.3.2 Acceptance test of blue instances under RLP/T**

The question we ask now can be formulated as follows: "Given any occurring blue instance *B*, can *B* be accepted?". *B* will be accepted provided a valid schedule exists, i.e. a schedule in which *B* will complete within its deadline while all periodic instances previously accepted will still meet their deadlines. Let *τ* be the current time which coincides with the release of a blue instance *B*. *B*(*r*, *c*, *d*) is characterized by its release time *r*, its execution time *c* and its deadline *d*, with *r* + *c* ≤ *d*. We assume that the system supports several uncompleted blue instances at time *τ* previously accepted. Let's denote by B(*τ*) = {*Bi*(*ci*(*τ*), *di*), *i*=1 to *blue*(*τ*)}, 10 Will-be-set-by-IN-TECH

Consider the periodic task set T defined in Table 1. The relating RLP scheduling is illustrated in Figure 7. The number of deadline misses has been reduced to four. Missed deadlines occur at instants *t* = 36 (task *T*3), *t* = 54 (task *T*2) and *t* = 72 (tasks *T*<sup>1</sup> and *T*3). Observe that the first blue instance *T*<sup>2</sup> which failed to complete within its deadline under BWP scheduling (see Figure 4) has enough time to succeed under RLP scheduling. The execution of the first red instances of *T*<sup>1</sup> and *T*<sup>0</sup> is postponed. Red instances are scheduled as soon as possible until time *t* = 12 and execute as late as possible in the presence of blue instances from time *t* = 12

> ✻ ✻ ✲✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻

0 36 72 0 24 48 72 0 18 36 54 72 0 12 24 36 48 60 72

The *Red tasks as Late as Possible with blue acceptance Test (RLP/T)* algorithm (Marchand & Chetto,

RLP/T runs as follows: red instances enter the system directly at their arrival time whereas blue instances integrate the system upon acceptance. A blue instance is scheduled as soon as possible together with red ones once accepted. All the ready instances are of the same importance. Deadline ties are broken in favor of the task with the earliest release time.

Processor idle times are computed according to the EDL strategy once a new blue instance is released. We assume that the instance immediately following a blue instance is also blue in the EDL schedule established at time *τ*. All blue instances previously accepted at *τ* are guaranteed by the schedulability test. It ensures there are enough idle times to accommodate

The question we ask now can be formulated as follows: "Given any occurring blue instance *B*, can *B* be accepted?". *B* will be accepted provided a valid schedule exists, i.e. a schedule in which *B* will complete within its deadline while all periodic instances previously accepted will still meet their deadlines. Let *τ* be the current time which coincides with the release of a blue instance *B*. *B*(*r*, *c*, *d*) is characterized by its release time *r*, its execution time *c* and its deadline *d*, with *r* + *c* ≤ *d*. We assume that the system supports several uncompleted blue instances at time *τ* previously accepted. Let's denote by B(*τ*) = {*Bi*(*ci*(*τ*), *di*), *i*=1 to *blue*(*τ*)},

2008) is an improvement of RLP designed to maximize even more the actual QoS.

up to the end of the hyperperiod. This enhances the actual QoS of periodic tasks.

Fig. 7. A schedule produced by the RLP scheduling algorithm (*si* = 2)

the new blue instance within its deadline, as described hereafter.

**3.3.2 Acceptance test of blue instances under RLP/T**

*: processing red instance : processing blue instance*

✻*: release time*

**3.2.2 Illustrative example**

*T*0 *T*1 *T*2 *T*3

**3.3 The RLP/T algorithm 3.3.1 Algorithm description** the blue instance set at time *τ*. The value *ci*(*τ*) is called *dynamic execution time* and represents the remaining execution time of *Bi* at *τ*. B(*τ*) is ordered such that *i* < *j* implies *di* ≤ *dj*.

Theorem 2 presents the acceptance test of blue instances within a system involving RLP skippable tasks. This test is based on theoretical results established in (Silly-Chetto et al., 1990) for the acceptance of sporadic requests that occur in a system composed of non-skippable periodic tasks.

**THEOREM 2.** *Instance B is accepted if and only if, for every instance Bi* ∈ B(*τ*) ∪ {*B*} *such that di* ≥ *d, we have δi*(*τ*) ≥ 0*, with δi*(*τ*) *defined as:*

$$\delta\_{\dot{l}}(\tau) = \Omega\_{\mathcal{T}(\tau)}^{EDL}(\tau, d\_{\dot{l}}) - \sum\_{j=1}^{\dot{l}} c\_{j}(\tau) \tag{6}$$

*δi*(*τ*) is called *slack of instance Bi at time τ*. It defines the maximum units of time during which *Bi* could be delayed without violating its deadline. Ω*EDL* T (*τ*) (*τ*, *di*) denotes the total units of time that the processor is idle in the time interval [*τ*, *di*]. The total computation time required by blue instances within [*τ*, *di*] is given by ∑*<sup>i</sup> <sup>j</sup>*=<sup>1</sup> *cj*(*τ*).

The acceptance test is based on the computation of EDL idle times which gives the slack of any blue instances. Then, this slack is compared to zero. The acceptance test runs in *<sup>O</sup>*(� *<sup>R</sup> <sup>p</sup>* �*n* + *blue*(*τ*)) in the worst-case, where *n* is the number of periodic tasks, *R* is the longest deadline and *p* is the shortest period. *blue*(*τ*) denotes the number of blue instances at time *τ* whose deadline is greater or equal to the deadline of *Bi*. A specific updating of additional data structures with slack tables may reduce the complexity to *O*(*n* + *blue*(*τ*)) as proved in (Tia et al., 1994).

#### **3.3.3 Illustrative example**

✲ ✲ ✲

> Figure 8 gives an illustration of RLP/T scheduling for the periodic task set T defined in Table 1. Clearly, RLP/T improves on both RLP and BWP. Only three deadline violations relative to blue instances are observed: at instants *t* = 36 (task *T*3), *t* = 54 (task *T*2) and *t* = 72 (task *T*3). The acceptance test contributes to compensating for the time wasted in starting the execution of blue instances which are not able to complete before deadline. The blue instance *T*<sup>2</sup> released at time *t* = 36 is aborted at time *t* = 54 – 8 units of time were indeed wasted – in the RLP case (see Figure 7). This rejection performed with RLP/T permits us to save time recovered for the successful completion of the blue instance *T*<sup>1</sup> released at time *t* = 48.

#### **4. Performance analysis**

#### **4.1 Simulation details**

We report part of a performance analysis composed of three simulation experiments in order to evaluate RLP/T with respect to RTO, BWP and RLP.

We successively measure:


in the Firm Real-Time Systems 13

Quality of Service Scheduling in the Firm Real-Time Systems 203

The QoS observed for BWP, RLP and RLP/T is higher for a given processor utilization when the task's computation time is less than the task's worst-case execution time. As the amount of time given by *WCET* − *ACET* is not used by each instance, additional CPU time permits

Moreover, note that BWP and RLP outperform RLP/T for low overloads with ACET=0.75\* WCET. This comes from the admission test in RLP/T which uses WCET values and not ACET ones. Consequently, RLP/T rejects instances that after all could have been accepted on the basis of their ACET. This is exactly what we observe for *Up* equal to 130%: RLP/T temporarily offers lower performances than BWP and RLP. Note that this phenomenon is no

Finally, other tests (Marchand, 2006) – not reported here – show that the higher the skip factor is, the more significant the advantage of RLP/T over the other scheduling algorithms.

We study here the CPU time wasted in incomplete executions of blue instances. The

(a) *si* = 2 (b) *si* = 6

The wasted CPU time is equal to zero for RTO since all red instances execute successfully. It is also equal to zero under RLP/T for any CPU utilization. This is due to the admission test that prevents from the abortion of blue instances. A blue instance is accepted if and only if it

The wasted CPU time is always positive under BWP and RLP once the system is overloaded (*Up* > 1). BWP and RLP involve the largest wasted CPU time – 24% et 26% respectively – for *Up* = 115% and *si* = 2. The BWP and RLP curves present a decline beyond that load. More red instances have to be executed under high overload. Less available CPU time is consequently

Additional results reported in (Marchand, 2006) show that wasted CPU time is all the less

us to successfully complete a higher number of instances.

longer observable once the skip factors are higher (e.g. *si* = 6).

simulation results for *si* = 2 and *si* = 6 are depicted in Figure 10.

Fig. 10. Wasted CPU time for low and high skips

available for the execution of blue instances.

can complete before deadline.

significant as skip factors grow.

**4.1.2 Experiment 2**

Fig. 8. A schedule produced by the RLP/T scheduling algorithm (*si* = 2)

• *the CPU idle time ratio* (i.e. the percentage of time during which the processor is not processing any task).

We make the processor utilization *Up* vary. The simulator generates 50 sets of periodic tasks. Each set contains 10 tasks with a least common multiple of periods equal to 3360 time units. The tasks have a uniform skip factor *si*. Worst-case computation times depend on *Up*. Deadlines are equal to periods and greater than or equal to computation times. Simulations have been processed over 10 hyperperiods.

#### **4.1.1 Experiment 1**

Figure 9 depicts the simulation results for *si*=2. The results are given for an actual computation time (ACET) equal to 100% and 75% of the worst-case computation time (WCET) respectively. Let us recall that the tasks have variable actual computation times assumed to be less than an estimated worst-case computation time. The assumption that a task consumes its WCET in every activation is not necessarily true. This implies that the actual CPU utilization never exceeds the estimated one used in the schedulability test.

Fig. 9. QoS for *si*=2

BWP and RLP outperform RTO – for which the QoS is constant and minimal – for any processor workload. Both BWP and RLP succeed in completing all blue instances that respectively execute after and before red instances for *U p* ≤ 1. RLP and BWP give almost the same performances under overload. Nevertheless, RLP/T provides a significant improvement in performance compared with RLP.

The QoS observed for BWP, RLP and RLP/T is higher for a given processor utilization when the task's computation time is less than the task's worst-case execution time. As the amount of time given by *WCET* − *ACET* is not used by each instance, additional CPU time permits us to successfully complete a higher number of instances.

Moreover, note that BWP and RLP outperform RLP/T for low overloads with ACET=0.75\* WCET. This comes from the admission test in RLP/T which uses WCET values and not ACET ones. Consequently, RLP/T rejects instances that after all could have been accepted on the basis of their ACET. This is exactly what we observe for *Up* equal to 130%: RLP/T temporarily offers lower performances than BWP and RLP. Note that this phenomenon is no longer observable once the skip factors are higher (e.g. *si* = 6).

Finally, other tests (Marchand, 2006) – not reported here – show that the higher the skip factor is, the more significant the advantage of RLP/T over the other scheduling algorithms.

## **4.1.2 Experiment 2**

✲ ✲ ✲

12 Will-be-set-by-IN-TECH

• *the CPU idle time ratio* (i.e. the percentage of time during which the processor is not

We make the processor utilization *Up* vary. The simulator generates 50 sets of periodic tasks. Each set contains 10 tasks with a least common multiple of periods equal to 3360 time units. The tasks have a uniform skip factor *si*. Worst-case computation times depend on *Up*. Deadlines are equal to periods and greater than or equal to computation times. Simulations

Figure 9 depicts the simulation results for *si*=2. The results are given for an actual computation time (ACET) equal to 100% and 75% of the worst-case computation time (WCET) respectively. Let us recall that the tasks have variable actual computation times assumed to be less than an estimated worst-case computation time. The assumption that a task consumes its WCET in every activation is not necessarily true. This implies that the actual CPU utilization never

(a) ACET=WCET (b) ACET=0.75\*WCET

BWP and RLP outperform RTO – for which the QoS is constant and minimal – for any processor workload. Both BWP and RLP succeed in completing all blue instances that respectively execute after and before red instances for *U p* ≤ 1. RLP and BWP give almost the same performances under overload. Nevertheless, RLP/T provides a significant

*T*0 *T*1 *T*2 *T*3

processing any task).

**4.1.1 Experiment 1**

Fig. 9. QoS for *si*=2

*: processing red instance : processing blue instance*

Fig. 8. A schedule produced by the RLP/T scheduling algorithm (*si* = 2)

✻*: release time*

have been processed over 10 hyperperiods.

exceeds the estimated one used in the schedulability test.

improvement in performance compared with RLP.

✻ ✻ ✲✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻

0 36 72 0 24 48 72 0 18 36 54 72 0 12 24 36 48 60 72

> We study here the CPU time wasted in incomplete executions of blue instances. The simulation results for *si* = 2 and *si* = 6 are depicted in Figure 10.

Fig. 10. Wasted CPU time for low and high skips

The wasted CPU time is equal to zero for RTO since all red instances execute successfully. It is also equal to zero under RLP/T for any CPU utilization. This is due to the admission test that prevents from the abortion of blue instances. A blue instance is accepted if and only if it can complete before deadline.

The wasted CPU time is always positive under BWP and RLP once the system is overloaded (*Up* > 1). BWP and RLP involve the largest wasted CPU time – 24% et 26% respectively – for *Up* = 115% and *si* = 2. The BWP and RLP curves present a decline beyond that load. More red instances have to be executed under high overload. Less available CPU time is consequently available for the execution of blue instances.

Additional results reported in (Marchand, 2006) show that wasted CPU time is all the less significant as skip factors grow.

in the Firm Real-Time Systems 15

Quality of Service Scheduling in the Firm Real-Time Systems 205

CLEOPATRE components have been prototyped under *Linux/RTAI (Real-Time Application Interface)* (Racciu & Mantegazza, 2006) and distributed under the LGPL license. The LGPL allows proprietary code to be linked to the GNU C library, glibc. When a program is linked with a library – whether statically or using a shared library – the combination of the two is legally speaking a combined work, a derivative of the original library. Companies do not have to release the source to code that which has been dynamically linked to an LGPLed library.

The CLEOPATRE library offers selectable COTS (Commercial-Off-The-Shelf) components dedicated to dynamic scheduling, aperiodic task servicing, resource control access, fault-tolerance and QoS scheduling. An additional task named *TCL (Task Control Logic)* interfaces all the CLEOPATRE components and has the highest priority. It has been added as a dynamic module in \$*RTAID IR*/*modules*/*TCL*.*o* and interfaces with the legacy RTAI

The CLEOPATRE interface is totally independent from the RTAI core layer. It can be directly used with Xenomai – which supports the RTAI API – and easily adapted to any other real-time

CLEOPATRE applications are highly portable to any new CPU architecture thanks to this OS abstraction layer which makes the library of services generic (Silly et al., 2007). The CLEOPATRE Off-the-Shelf components are optional except for the OS abstraction layer (TCL) and the scheduler. At most one component per shelf can be selected. Since all components of a given shelf have the same programming interface, they become interchangeable. Everything needed to use or extend CLEOPATRE can be downloaded from the project web

The memory and disk footprints of the operating system turn out to be key issues for embedded real-time applications as well as the time overhead incurred by the operating system itself. Table 2 gives the footprints for the schedulers provided by CLEOPATRE.

scheduler defined in \$*RTAID IR*/*modules*/*rtai*\_*sched*.*o*, as depicted in Figure 12.

This makes the use of such codes much more attractive.

Fig. 12. Cleopatre Library within Linux/RTAI

site *http://cleopatre.rts-software.org*.

**4.2.2 Overheads and footprints**

Linux extension.

#### **4.1.3 Experiment 3**

Finally, we study the CPU idle time ratio given by the percentage of time during which the processor is not processing any task. This measure quantifies the ability to face a dynamic processing surplus (e.g. the arrival of an aperiodic task). Simulation results for *si* = 2 and *si* = 6 are presented in Figure 11.

Fig. 11. CPU idle time for low and high skips

We note that the CPU idle time ratio under RTO is the highest one compared with all strategies. This ratio declines in a linear fashion according to *Up*. It varies from 55% for *Up* = 90% to 10% for *Up* = 180% and *si* = 2. Note the singular points of the curves *si* = 2 and *si* = 6: when *Up* = 100% idle time ratios are respectively equal to <sup>1</sup> <sup>2</sup> <sup>=</sup> 50% and <sup>1</sup> <sup>6</sup> = 16.7% which correspond exactly to the skip factors.

Idle time ratios are identical and positive – e.g. idle time = 10% for *Up* = 90% – when *Up* < 100% under BWP, RLP and RLP/T. They decline in a linear fashion until reaching a zero value for *Up* = 100%.

Results differ for overloaded systems (*Up* > 100%). RLP involves no CPU idle time whatever the skip factors are. We observe that BWP involves a low idle time ratio only under low skip ratios. RLP/T clearly appears as the most efficient strategy, still offering idle time under light overloads. For example, the idle time ratio under RLP/T for *si* = 2 and *Up* = 115% is equal to 9%. RLP/T gives a low and still positive idle time ratio even when the system is highly overloaded.

In summary, RLP/T proves to be the most suitable scheduling strategy to cope with transient overloads while providing the highest Quality of Service.

#### **4.2 Integration into an open-source operating system**

#### **4.2.1 The CLEOPATRE Library**

From 2002 until 2006, we developed a library of free software components within the French National project *CLEOPATRE (Software Open Components on the Shelf for Embedded Real-Time Applications)*. This project aims to provide efficient services to real-time applications (Silly et al., 2007). It enriches real-time Linux variants with enhanced real-time facilities.

14 Will-be-set-by-IN-TECH

Finally, we study the CPU idle time ratio given by the percentage of time during which the processor is not processing any task. This measure quantifies the ability to face a dynamic processing surplus (e.g. the arrival of an aperiodic task). Simulation results for *si* = 2 and

(a) *si* = 2 (b) *si* = 6

We note that the CPU idle time ratio under RTO is the highest one compared with all strategies. This ratio declines in a linear fashion according to *Up*. It varies from 55% for *Up* = 90% to 10% for *Up* = 180% and *si* = 2. Note the singular points of the curves *si* = 2 and

Idle time ratios are identical and positive – e.g. idle time = 10% for *Up* = 90% – when *Up* < 100% under BWP, RLP and RLP/T. They decline in a linear fashion until reaching a zero

Results differ for overloaded systems (*Up* > 100%). RLP involves no CPU idle time whatever the skip factors are. We observe that BWP involves a low idle time ratio only under low skip ratios. RLP/T clearly appears as the most efficient strategy, still offering idle time under light overloads. For example, the idle time ratio under RLP/T for *si* = 2 and *Up* = 115% is equal to 9%. RLP/T gives a low and still positive idle time ratio even when the system is highly

In summary, RLP/T proves to be the most suitable scheduling strategy to cope with transient

From 2002 until 2006, we developed a library of free software components within the French National project *CLEOPATRE (Software Open Components on the Shelf for Embedded Real-Time Applications)*. This project aims to provide efficient services to real-time applications (Silly et

al., 2007). It enriches real-time Linux variants with enhanced real-time facilities.

<sup>2</sup> <sup>=</sup> 50% and <sup>1</sup>

<sup>6</sup> = 16.7%

*si* = 6: when *Up* = 100% idle time ratios are respectively equal to <sup>1</sup>

**4.1.3 Experiment 3**

*si* = 6 are presented in Figure 11.

Fig. 11. CPU idle time for low and high skips

which correspond exactly to the skip factors.

overloads while providing the highest Quality of Service.

**4.2 Integration into an open-source operating system**

value for *Up* = 100%.

**4.2.1 The CLEOPATRE Library**

overloaded.

CLEOPATRE components have been prototyped under *Linux/RTAI (Real-Time Application Interface)* (Racciu & Mantegazza, 2006) and distributed under the LGPL license. The LGPL allows proprietary code to be linked to the GNU C library, glibc. When a program is linked with a library – whether statically or using a shared library – the combination of the two is legally speaking a combined work, a derivative of the original library. Companies do not have to release the source to code that which has been dynamically linked to an LGPLed library. This makes the use of such codes much more attractive.

The CLEOPATRE library offers selectable COTS (Commercial-Off-The-Shelf) components dedicated to dynamic scheduling, aperiodic task servicing, resource control access, fault-tolerance and QoS scheduling. An additional task named *TCL (Task Control Logic)* interfaces all the CLEOPATRE components and has the highest priority. It has been added as a dynamic module in \$*RTAID IR*/*modules*/*TCL*.*o* and interfaces with the legacy RTAI scheduler defined in \$*RTAID IR*/*modules*/*rtai*\_*sched*.*o*, as depicted in Figure 12.

The CLEOPATRE interface is totally independent from the RTAI core layer. It can be directly used with Xenomai – which supports the RTAI API – and easily adapted to any other real-time Linux extension.

Fig. 12. Cleopatre Library within Linux/RTAI

CLEOPATRE applications are highly portable to any new CPU architecture thanks to this OS abstraction layer which makes the library of services generic (Silly et al., 2007). The CLEOPATRE Off-the-Shelf components are optional except for the OS abstraction layer (TCL) and the scheduler. At most one component per shelf can be selected. Since all components of a given shelf have the same programming interface, they become interchangeable. Everything needed to use or extend CLEOPATRE can be downloaded from the project web site *http://cleopatre.rts-software.org*.
