RealTime Tasks with Data Output.
 Citations (12)
 Cited In (0)

Conference Paper: Fairness in periodic realtime scheduling
[Show abstract] [Hide abstract]
ABSTRACT: The issue of temporal fairness in periodic realtime scheduling is considered. It is argued that such fairness is often a desirable characteristic in realtime schedules. A concrete criterion for temporal fairnesspfairnessis described. The weightmonotonic scheduling algorithm, a static priority scheduling algorithm for generating pfair schedules, is presented and proven correct. A feasibility test is presented which, if satisfied by a system of periodic tasks, ensures that the weightmonotonic scheduling algorithm will schedule the system in a pfair mannerRealTime Systems Symposium, 1995. Proceedings., 16th IEEE; 01/1996  SourceAvailable from: psu.edu[Show abstract] [Hide abstract]
ABSTRACT: Given a set ofn tasks andm resources, where each taskx has a rational weightx.w=x.e/x.p,0periodic schedule is one that allocates a resource to a taskx for exactlyx.e time units in each interval [x.pk, x.p(k+1)) for allkN. We define a notion of proportionate progress, called Pfairness, and use it to design an efficient algorithm which solves the periodic scheduling problem.Algorithmica 01/1996; 15(6):600625. · 0.49 Impact Factor  [Show abstract] [Hide abstract]
ABSTRACT: The scheduling of generalized pinwheel task systems is considered. It is shown that pinwheel scheduling is closely related to the fair scheduling of periodic task systems. This relationship is exploited to obtain new scheduling algorithms for generalized pinwheel task systems. When compared to traditional pinwheel scheduling algorithms, these new algorithms are both more efficient from a runtime complexity point of view, and have a higher density threshold, on a very large subclass of generalized pinwheel task systemsIEEE Transactions on Computers 08/1998; · 1.38 Impact Factor
Page 1
RealTime Task with Data Output
Deji Chen*!, Aloysius K. Mok!, Mark Nixon*, and Rusty Shepard*
*Emerson Process Management !Department of Computer Sciences
8627 Mopac North The University of Texas at Austin
Austin, TX 78759 Austin, TX 78712
Abstract
A realtime task usually generates data. The study
on realtime tasks either ignores this fact like most of
the research do, or models data as execution time like
when handling multimedia data. On the other hand,
the network research community usually pays little
attention to the data source other than assuming
certain characteristics. There are many real world
applications where data is not generated at a constant
rate during task execution, and the average data rate
is not the same among tasks. In this paper we study a
new task model with data output as an explicit
parameter. We analyze the data output of such task set.
We shall derive the data source parameters assumed
by network studies. Different scheduling policy results
in different data output curve, we look at this in detail
with simulations. Our work extends the realtime
research to cover a new set of real world applications;
it also complements the network study on data
transmission.
1. Introduction
Many real world applications produce data output.
Many realtime applications also produce data output.
The principal role of a sensor application is to produce
environment data; a stock analysis package provides
trend information and purchase recommendations. For
the same amount of data, different applications require
different amount of execution time to produce due to
different nature of the data. A temperature
measurement requires reading of the thermal sensor; a
speed measurement of water in a pipeline requires
reading of related sensors and then deriving the speed
from related sensor values. In addition, it varies in
when and how data is produced during an application’s
execution. Sensor data is produced at the end of a
sensor application. Most applications run extra
housekeeping code after data is generated. A digital
camera generates MPEG videos that vary frame by
frame. A realtime system may have both data
producing applications
applications. In certain network router, package
routing task is run on the host machine. The routing
task could be considered a data producing task. It has
to compete with all other host applications that
contribute no data to the network. Data should be a
first class citizen in realtime research
Yet when we consider a realtime task model, we
either do not consider data output, or assume that the
execution is data. Most of the realtime task models
have parameters for start time, period, execution
requirement, deadline [4, 10, 11, 12], etc. In those
models, data output is never of any concern. When
data becomes an issue, people try to rationalize the
execution requirement as data output. In other words,
when we schedule a task, we interpret it as the task has
produced a proportional amount of data. A typical
example is scheduling data packages in a network
router. The multiframe task model [13] was partly
motivated to model data size as execution time.
Data produced is to be transmitted. The network
community investigates heavily on how to efficiently
transmit data from the source to the destination. Yet
the characteristics of the data source falls outside the
realm of network research and is seldom looked into.
Normally some data source parameters are defined and
the topic becomes how to transmit the data given those
parameters [6, 9]. The parameters are usually average
rate, burstiness, etc. It is assumed that these values are
known a priori. One could hope that a thorough study
of the data source produces more insight into its
characteristics which could lead to improved network
transmission.
In this paper we present a realtime task model with
data output as an explicit parameter. We look at the
data output curve from this model and the effect on it
by different scheduling policies. We shall study how to
calculate the data source parameters defined in the
network community
and nodataoutput
Page 2
The model was initially introduced in [5] to analyze
the effect of limited network bandwidth on data
buffering for realTime tasks. It was motivated by the
idea that processor power and memory capacity
outpace the network bandwidth. The bottleneck of a
realtime system was the network bandwidth. [5]
looked at the data buffer size when transmitting data
with a given bandwidth and derived some bounds on
the buffer size. This paper is separate but based on [5].
It includes parts of [5] to be selfcontained.
The next section introduces the model. Section 3
analyzes the data output curve. Section 4 relates the
work to network transmission. Section 5 looks at the
effect of different scheduling policies on the output
curve. We conclude the paper in Section 6.
2. The task model
In this section, we define a series of terms. We shall
use the periodic task model. We use the integral
functions loosely here; we do not distinguish between
a time point and a time unit.
•
A task T is (C, P, O) where C is the
execution time, P is the period, and O is
the total bytes of data output per execution.
P is also the relative deadline.
•
Define w = O / P to be T’s average data
generation rate.
•
A task set S is a set of all n tasks in the
system.
DefineW
∑=
•
to be S’s average
data generation rate.
Define L to be the least common multiple
of all the periods in S.
A task T‘s data output function o(t), 0 ≤ t ≤
C, is T‘s data output at the point when t of
∫0
=
n
k
k
w
1
•
•
C is executed.
. We
consider three types of output functions. In
the first type the data is constantly
generated during the execution, where o(t)
= O / C. We name it constantdatarate
task. In the second type all the data is
generated upon the job’s completion,
≤
t
O,
where
. We name it
dataatend task. In the third type all the
data is ready when the job starts,
whereo
. We name it
dataatstart task.
Given a scheduling algorithm, the schedule
function s(t), t ≥ 0, for a task T equals 1 if
T is scheduled at time t, equals 0
otherwise. No two tasks have their
schedule functions equal to 1 at the same
time.
Given a scheduling algorithm, data output
function of
( )
t
( )
tOdto
C
=
=
<
C
Ct
( )
t
=
o
0 , 0
( )
t
≤<
=
=
Ct
tO
0 , 0
0,
( )
t%
0
=
∫
Cdtso
t
)( )
t
0,
1
≥=∑=
ti
n
k
k
( )
t
( )
t
0,
0
≥=∫
tdtI
t
•
•
a task T
isi
.
0, ≥
t
•
Given a scheduling algorithm, the data
output function of the task set S
is (tI
.
•
Given a scheduling algorithm, the data
output curve of the task set S
is
.
J
We stipulate that all tasks start at time 0. The
analysis could be extended to cases where tasks have
different starting times other than 0. Note our study is
limited to the case where O is a constant. We do not
study the case where a task generates different amount
of data during each request. A task could be modeled
as a dataatend task if we buffer up all the data
generated during its execution and release at the end.
Example 1: (a) In process control a smart device
runs function blocks periodically to return sensor data.
The data is ready at the end of the execution. The
function blocks are dataatend tasks. (b) The DVD
player scans the disk continuously for movie data. The
DVD reader application is a constantdatarate task. (c)
In a Foundation Fieldbus network, each node transmits
data as soon as it receives the token. It then passes the
token back. The token processing method is a task that
generates data at the constant Fieldbus baud rate in the
beginning, then prepares for the next transmission
which sends no data to the network. (d) A digital
converter for analog TV shows MPEG movies. The
decoder translates one MPEG frame into two
interlaced TV frame signals. It is a task that generates
data discretely during its execution, each time
producing a line. Figure 1 displays the data output
functions for above 4 applications. Except in (b), the
data output is not in proportion to the execution and
could not be represented by the execution time
parameter.
Page 3
o(t) o(t)
byte
20
O
O/C
t t
C C
(a) (b)
10
o(t) o(t)
time
0
36 9 12
t
t
C C
T1
T2
T1
T2
T1
T2
T1
(c) (d)
Figure 1: Data output functions in Ex. 1
Figure 2: Schedule, data output curve in Ex. 2
Example
{
1
=
T
datarate task; T2 is a dataatend task. w1 = 0.666. w2 =
1. W = w1 + w2 = 1.666. L = 12. Figure 2 shows the
ratemonotonic schedule and the resulting data output
curve J(t) over L. The earliest deadline policy happens
to produce the same schedule. So Figure 2 also shows
those of the earliest deadline schedule.
In network, jitter refers to the variation of distance
between two consecutive transmissions/arrivals. In
realtime task scheduling, jitter refers to the variation
of consecutive job request/finish time. It is awkward to
use the finish time because any time between when the
job is finished and the deadline could be defined as a
“finish time”. Or we could reserve a very small last
amount of the job and schedule it arbitrarily before the
deadline in order to reduce the jitter. It is hard to find
real applications that benefit from this type of artificial
jitter reduction. With our task model, jitter could be
defined as the jitter to the data generated from the task
instead of the jitter of when the task is scheduled. This
avoids the problem with previous task models and is in
congruence with the jitter concept in the network area.
Sometimes a value function is associated with a
realtime task models. A task still provides value if
partially completed or missed deadline. A shorter
weaker version of the task could be executed in place
of the full version [12]. Our model could provide
semantics to the value functions. The value of the
accumulated data during the task execution represents
the value of the executed part of the task. If a partial
data could be used in a heavy loaded system, then the
partial execution that produces that partial data could
be the amount of an imprecise computation.
2:
) (
,
Task
. T
set
}(
2 , 3 , 1
{
4 , 4 , 1,
2
=
TS
)}
1 is a constant
Data generated from a task may also have priority
to be transmitted. Let’s assume the priority is fixed per
task. The data priority may be the same as the task’s
fixed priority, or may be assigned independently of the
task priority. The analysis of a task set with data
priority could be reduced to that of a task set with no
data priority. For a given task T in a task set S with
data priority, we define a task set S’ with no data
priority that is the same as S except that no task
generates data except T. The data output analysis of T
is equivalent to that of S’. The transmission of all the
data in S is not a concern to us here as it is considered
a network problem to transmit a set of data sources
with different priorities and output curves. The same is
true if data from different tasks should be considered
differently in transmission. In this paper we study data
from the task set, which is the data as a whole from all
tasks.
3. Data Output curve
The data output curve J(t) could be calculated once
the schedule is determined. For a given task set,
different scheduling policy produces different J(t). The
best way a task set generates data is at a constant rate.
So we consider the best J(t) to be a straight line with
slope equals W. The quality of a J(t) could be defined
as how close it is to the best one. Another way to
measure J(t) is to compare the minimum buffer
required if the data is to be transmitted with a certain
bandwidth. The transmission is workconserving, i.e.,
data is transmitted as soon as bandwidth is available.
We shall find this buffer size in this section.
Of course the bandwidth must be at least equal to
W, the average data generation rate. Given unlimited
buffer size, all data will be eventually transmitted.
Different algorithm schedules task at different times,
hence generates data at different times. If data
Page 4
generation is concentrated at certain time period,
buffer requirement and delay will be big at that period;
if data is generated smoothly over time, then it could
be transmitted as soon as it is ready. If we could
schedule the tasks so that the data is generated at a
constant rate, in theory the required buffer size could
be 0.
We first give some more definitions for a task set
and bandwidth .
•
The network to transmit data generated
from S has a bandwidth of B bytes per time
unit.
•
The bandwidth utilization is W / B.
•
Given a scheduling algorithm, define v(t), t
≥ 0, to be the actual data transmission rate
at time t.
•
Given a
( )
0
•
Given a scheduling algorithm, define q(t), t
≥ 0, to be the bytes of data in the buffer at
time t.
•
Given a scheduling algorithm, define Q to
be the minimum buffer size required so
that no data will be lost.
•
Given a scheduling algorithm, define D to
be the minimum data transmit delay.
We shall not consider D in this paper as D = Q / B.
The network can only transmit as much data as is
generated, V(t) ≤ J(t) should hold for t ≥ 0.
Since we assume that W is no more than B, and the
task schedule repeats itself every L time units, this
inequality
hold: ( )
O
P
k
8.1. The exact value of Q
As soon as new data is generated, transmission
starts. The transmission rate will match the data
generation rate until the latter is higher than B, when
the transmission rate stays at B and extra data is cached
in the buffer. The transmission rate will then stay at B
until the buffer is empty, at which point the rate will
drop to the new data generation rate. It’s apparent that
v(t) depends on the history of I(t) and itself:
( )( )
∫
At any time, the data in the buffer should be the
difference between data
scheduling
( )
dttv
algorithm,
defineV
.
0,
≥=∫
tt
t
must
LBLW
L
LJ
k
n
k
≤==∑=1
.
( )
t
( )
t
( )
t
(
( )
t
( )
t
( )
t
()
>
<
≤
=
=
∫
∫∫
−−
−−
BIdtIdtvB
BI dtI dttvtI
v
tt
tt
,
&,
00
00
)
)
generated and data
transmitted. In other words, q(t) = J(t) – V(t). Now we
can derive Q:
( )( )(
−==
≥≥
tt
VtJtqQ
00
maxmax
( )
t
)( )
t
(
−=
∫∫
≥
tt
t
dttvdtI
00
0
max
We started integration from 0 in above expressions,
which is to simplify the presentation. We could
integrate from the latest time when v(t) = I(t) < B
∫
0
To find Q, we need to search the whole time line.
Just as for task schedulability test, we hope that
searching from 0 to some multiple of L suffices. In
Example 2, I(t) and v(t) repeats every L. We only need
to search the first L. This is not always the case as in
many cases the buffer is not empty at L. A simple
example is a single dataatend task set {(1, 1, 1)}. In
this case the data generated in one L = 1 segment is
transmitted in the next L segment. I(t) repeats every L
time units because the task schedule repeats every L
time units. We shall prove that v(t) also repeats every L
time units, but not necessarily starting from 0.
Lemma 1: I(t) repeats every L time units from 0.
Lemma 2: v(t) repeats every L time units after L .
Proof Sketch: If V(L) = J(L), q(L) = 0. At time L
there is no outstanding data, all tasks start requests.
This is exactly the same situation as at time 0. So v(t)
repeats every L time units since 0.
If V(L) < J(L), q(L) > 0. There is outstanding data at
L. Hence the transmission rate has to be B at L. Let t0
to be the latest time before L when the transmission
rate is less than B. t0 must exist otherwise the
transmission rate is B all through [0, L]. This is not
possible because then there is no less data (V(L) = LB)
transmitted than data (J(L)) generated.
The left half of Figure 3 shows the two curves V(t)
and J(t) in [0, L]. Let’s look at them in [L, 2L]. I(t)
repeats in [L, 2L], so we can copy the curve of J(t)
from [0, L]. Let’s also copy the curve of V(t) from [0,
L] to [L, 2L] with the starting point at the coordination
(L, J(L)), as is shown in Figure 3, and extend the curve
V(t) from L at the same rate of B until it intersects the
copied curve at t1. We shall prove that this extended
line plus the copied curve in [t1 2L] form the curve of
V(t) in [L, 2L].
First, this extended line intersects the copied curve
before or at L + t0, otherwise this line could be
extended to 2L under both copied curves, and intersect
the vertical line at 2L no higher than V(L) + J(L). This
implies that we start at L with q(L) = J(L) – V(L) bytes
in the buffer, transmit at the rate of B until 2L, but we
still have more than q(L) bytes in the buffer. This
contradicts the assumption that B is no less than W. In
[L, t1], v(t) must be B as the buffer is not empty. Total
data generated in [L, t1] equals total data generated in
because then at t we have
.
( )
t
( )
t
∫
−−
=
tt
dtI dtv
0
Page 5
[0, t1L]; total data transmitted in [L, t1] equals total
data transmitted in [0, t1  L] plus the data buffered at
L. The data in the buffer at t1 is the same as at t1  L. So
v(t) in [t1, 2L] is the same as v(t) in [t1  L, L].
Figure 3: J(t) and V(t) in [0, 2L] Figure 3: J(t) and V(t) in [0, 2L]
Finally we could prove that v(t) in [L, 2L] repeats
after 2L. The data size in the buffer at time L is the
same as at time 2L. Since I(t) in [L, 2L] repeats after
2L, so does v(t). ■ 2L, so does v(t). ■
We haveQ
So Theorem 1 follows: So Theorem 1 follows:
Theorem 1: Q equals the biggest buffer size during
[0, 2L]. [0, 2L].
[0, 2L] is still a large range to search. One could
wonder if a shorter length is available. Since v(t) is
calculated progressively, we have to always start from
time 0. From the proof of Lemma 2, we know q(t) ≥
q(t  L) if L ≤ t ≤ t1. So we have to search at least until
t1. We also know q(t) = q(t  L) if t > t1. So in practice
searching the range [0, t1] suffices. In addition, we
only need to calculate v(t) in [0, L] as for L ≤ t ≤ t1, q(t)
= J(t) – V(t) = (J(L) + J(t  L)) – (V(L) + (t  L)B) = J(t
 L) + (J(L)  V(L))  (t  L)B = J(t  L) + q(L)  (t  L)B
= q(t  L) + (V(t  L) + q(L)  (t  L)B. = q(t  L) + (V(t  L) + q(L)  (t  L)B.
For fixed priority scheduling algorithms, the critical
instant of a task is the instant when it simultaneously
requests execution with all higher priority tasks. It has
been proved that a task’s schedulability could be tested
at its critical instant. The question is if we could find
such instant when Q could be found. Let’s name it
critical output instant. We are unable to find such
instant. At least the critical instant may not be critical
output instant. For example, consider a task set with
only the lowest priority task generating data at
constantdatarate. The worst data buffering situation
is when this task is executed without preemption. In its
critical instant, the task is most likely to be scheduled
in pieces. If all tasks in a set are constantdatarate and
have identical data output function, the critical instant have identical data output function, the critical instant
Finally we could prove that v(t) in [L, 2L] repeats
after 2L. The data size in the buffer at time L is the
same as at time 2L. Since I(t) in [L, 2L] repeats after
because of Lemma 2. because of Lemma 2.
We haveQ
( ) t
( ) tqq
LL
tt
22
00
max=
max=
==
Theorem 1: Q equals the biggest buffer size during
[0, 2L] is still a large range to search. One could
wonder if a shorter length is available. Since v(t) is
calculated progressively, we have to always start from
time 0. From the proof of Lemma 2, we know q(t) ≥
q(t  L) if L ≤ t ≤ t1. So we have to search at least until
t1. We also know q(t) = q(t  L) if t > t1. So in practice
searching the range [0, t1] suffices. In addition, we
only need to calculate v(t) in [0, L] as for L ≤ t ≤ t1, q(t)
= J(t) – V(t) = (J(L) + J(t  L)) – (V(L) + (t  L)B) = J(t
 L) + (J(L)  V(L))  (t  L)B = J(t  L) + q(L)  (t  L)B
produces the longest processor busy period. This looks
like a critical output instant, but we could not stop
checking the buffer size after the processor idles as the
next processor busy period might add more data to the
buffer. buffer.
8.2. The bound for Q 8.2. The bound for Q
For task schedulability, we could either test it out
on the time line, or simply check if the task set
utilization is within a certain bound. In this section, we
derive some buffer size bounds so that if we provide
buffer as big as the bounds, no data will be lost. buffer as big as the bounds, no data will be lost.
We assume workconserving data transmission in
this paper. Data can also be transmitted with other
policies in which the network transmits at less than its
maximum rate while extra data is cached in the buffer. maximum rate while extra data is cached in the buffer.
Theorem 2: The maximum data buffer size is the
smallest if workconserving data transmission policy is
used. used.
Proof Sketch: The statement is intuitively correct as
the more data is transmitted, the less data is in the
buffer. We formally prove it by converting any data
transmission schedule produced by any policy to the
data transmission schedule produced by the work
conserving policy. conserving policy.
In a data transmission schedule produced by work
conserving policy, v(t) = B as long as q(t) > 0. conserving policy, v(t) = B as long as q(t) > 0.
For I(t) produced by any scheduling algorithm and
v(t) produced by any transmission policy, we convert
v(t) to v’(t) as follows. Starting from time 0, we set
v’(t) = v(t) until the first t when q(t) > 0 and v(t) < B.
We then set v’(t) = B until q’(t) = 0, when we set v’(t)
with workconserving policy until V’(t) = V(t). Then
we set v’(t) = v(t) and repeat what we started from time
0. Repeat this procedure forever. From the
construction we know v’(t) is a workconserving
schedule. And the curve V’(t) always stays between
J(t) and V(t) So q’(t) ≤ q(t) and we have J(t) and V(t) So q’(t) ≤ q(t) and we have
( )
(max'max
00
qtq
tt
≥≥
≤
Corollary 1: For a task set, let Q1 to be the value of
Q with bandwidth B1; let Q2 to be the value of Q with
bandwidth B2. If B1 ≥ B2, then Q1 ≥ Q2.
Proof Sketch For bandwidth B1, we design a
transmission policy like this: Reserve (B1  B2)
bandwidth and use the rest B2 to transmit data with
workconserving policy. By definition, Q = Q2. Since
Q1 ≥ Q according to Theorem 2, we have Q1 ≥ Q2. ■
∑=
k
OQ
1
Proof Sketch: We only need to give an example
whose buffer size reaches∑=
For fixed priority scheduling algorithms, the critical
instant of a task is the instant when it simultaneously
requests execution with all higher priority tasks. It has
been proved that a task’s schedulability could be tested
at its critical instant. The question is if we could find
such instant when Q could be found. Let’s name it
critical output instant. We are unable to find such
instant. At least the critical instant may not be critical
output instant. For example, consider a task set with
only the lowest priority task generating data at
constantdatarate. The worst data buffering situation
is when this task is executed without preemption. In its
critical instant, the task is most likely to be scheduled
in pieces. If all tasks in a set are constantdatarate and
produces the longest processor busy period. This looks
like a critical output instant, but we could not stop
checking the buffer size after the processor idles as the
next processor busy period might add more data to the
byte
2J(L)
J(t)
V(t)
For task schedulability, we could either test it out
on the time line, or simply check if the task set
utilization is within a certain bound. In this section, we
derive some buffer size bounds so that if we provide
J(L)
V(L)
We assume workconserving data transmission in
this paper. Data can also be transmitted with other
policies in which the network transmits at less than its
time
0
2L L
t0
t1
L+t0
Theorem 2: The maximum data buffer size is the
smallest if workconserving data transmission policy is
Proof Sketch: The statement is intuitively correct as
the more data is transmitted, the less data is in the
buffer. We formally prove it by converting any data
transmission schedule produced by any policy to the
data transmission schedule produced by the work
In a data transmission schedule produced by work
For I(t) produced by any scheduling algorithm and
v(t) produced by any transmission policy, we convert
v(t) to v’(t) as follows. Starting from time 0, we set
v’(t) = v(t) until the first t when q(t) > 0 and v(t) < B.
We then set v’(t) = B until q’(t) = 0, when we set v’(t)
with workconserving policy until V’(t) = V(t). Then
we set v’(t) = v(t) and repeat what we started from time
0. Repeat this procedure forever. From the
construction we know v’(t) is a workconserving
schedule. And the curve V’(t) always stays between
)t
. So Q’ ≤ Q. ■
Theorem 3:
≥
n
k
.
n
k
k
O
1
. Consider a set of
Page 6
all dataatstart tasks. At time 0, all tasks request
execution with data ready, which totals
∑=
k
O
1
∑=
k 1
Q.
Proof Sketch: We design a transmission policy like
this: For each task T we exclusively reserve w of the
bandwidth for it. This is possible as W ≤ B. We use
workconserving policy of this w for T.
The theorem is true if C = P. In this case S contains
a single task that occupies the processor full time. The
maximum buffer size is O regardless of what o(t) is. maximum buffer size is O regardless of what o(t) is.
()
∑
k
w
∑
k
w
. So
we haveQ
. ■
(
2
∑=
n
k
k
O
1
)
−
22
kkkk
PPO −
O
≥
n
k
n
==
−−
nn
kk
kkkk
CCOO
12
( )dt t i
( )dt t i
∫ ∫
( ) t
( ) tv∫
12
v∫
Theorem 4:
is a bound for
−
kkk
wCO
And And
= =
= 2O  O = O. = 2O  O = O.
Now let’s look at the worst case buffer size
requirement for T if C < P. Data waiting to be
transmitted is always bigger if T is scheduled
continuously. In a schedule if two segments of C are
scheduled separately, we could move them together so
data accumulated from the first segment will be added
to the second segment before it is transmitted. Given
the constraint that T is finished before the deadline, the
worst possible buffer requirement occurs when T is
scheduled at the end of one period and immediately
scheduled at the beginning of the next period, i.e., T is
scheduled continuously over a 2C period as is shown
in Figure 4. We do not need to worry about the period
before or after them as we allocate enough bandwidth
to transmit O bytes of data in one period. v(t) is the
data transmission rate function for T. data transmission rate function for T.
ns
a single task that occupies the processor full time. The
()(())
∑=
∑=
11
11
kk
kk
ww
Now let’s look at the worst case buffer size
requirement for T if C < P. Data waiting to be
transmitted is always bigger if T is scheduled
continuously. In a schedule if two segments of C are
scheduled separately, we could move them together so
data accumulated from the first segment will be added
to the second segment before it is transmitted. Given
the constraint that T is finished before the deadline, the
worst possible buffer requirement occurs when T is
scheduled at the end of one period and immediately
scheduled at the beginning of the next period, i.e., T is
scheduled continuously over a 2C period as is shown
in Figure 4. We do not need to worry about the period
before or after them as we allocate enough bandwidth
to transmit O bytes of data in one period. v(t) is the
Figure 4: Worst case buffer requirement Figure 4: Worst case buffer requirement
The left half of Figure 4 shows the two integration The left half of Figure 4 shows the two integration
dt dt
curvescurves
andand in [PC, P]. Let’s look at in [PC, P]. Let’s look at
them in [P, P + C]. i(t) repeats in [P, P + C], so we can them in [P, P + C]. i(t) repeats in [P, P + C], so we can
copy the curve of copy the curve of
( )dt
( )dtt
t i∫
v∫
from [P  C, P]. Let’s also
copy the curve of from [P  C, P] to [P, P +
C] with the starting point at the coordination (P, O), as
is shown in Figure 4. Let’s call this curve Y. We then
( )dttv∫
reaches P + C. We shall prove that this extended line is
( )dttv∫
w is the maximum transmission rate. We only need
to prove that, in [P, P + C], there is always data
waiting to be transmitted. We shall prove that the
extended line falls under curve Y, which is under
extend
from P at the same rate of w until it
the curve of
in [P, P + C].
( )dtt i∫
( ) t
∫−
P
=
0t
C
vdt
)()(
tP
0
bO
0
−+−
(
=
n
k 12
(
(∫
n
dt
)
t i
(
∑
O2
curve
. If the extended line intersects curve Y at
time t, then curve Y right of t plus the extended line left
of t form a transmission schedule within [P, P + C]
that transmits O bytes of data. This is not possible as
the maximum possible data transmitted = Cw < Pw =
O. So the transmission rate is a constant w in [P, P +
C].
We now look at the buffer size. Let t0 to be the
latest time within [P  C, P] when the transmission rate
is less than w. t0 could be P  C or P.
Let
. The worst buffer requirement is
( )dttv∫
in [P, P + C] where the curve
falls under the
curve Y. So the worst buffer requirement is either
(
wb0+
b0 at time t0 + C. The former may occur with dataat
end task and the latter may occur with dataatstart
task. 2O  Cw is the bound for both. So the worst
buffer requirement for T is 2O  Cw. The total data in
buffer for S is no more than∑
∑
Theorem 2. ■
In above theorem we assign bandwidth of w to T.
Since W ≤ B, We could further improve the bound by
assigning some leftover bandwidth to T with the
condition that the proof of the theorem is still valid. To
better make use of this, we could assign as much
leftover bandwidth to tasks with bigger C as possible.
We could also replace the terms in the summation with
smaller values for constantdatarate tasks or
max
0 b
)
at time P, or 2O – Cw 
. So
Q is bounded by
()
−
)
kkwC
=
n
k
k
O
12
−
C
kkw
k
O
according to
byte
2O
calculated from
( ) )
dtt
∫
C
−
v
directly.
Corollary 2:
)
=
−
k
kkk
w
1
is a bound for
Q for a set of all constantdatarate tasks.
0
P P+C
time
∫v(t)dt
∫i(t)dt
t0
t0+C
O
b0
PC
Page 7
The proof follows from the proof of Theorem 4 in
( )dtt i∫
which both
andcurves are straight
lines. Constantdatarate tasks fare better in deriving
the bound.
We might get even better bounds. For example, we
ignored the fact in the proof that the worst cases of
different tasks won’t happen at the same time. Some
other bounds were given in [5]. Note also that the
bounds we derived do not depend on B or the
scheduling policy.).
4. Related work in network
In this section, we related our work to the research
in the network community. We study how to
complement with ways to find the parameter values of
a network data source. We shall look at two literatures,
network delay calculus developed in [6] and VNET in
[9]. In the network community data source is described
as an arrival curve which is the total accumulated
amount of data generated from the source at a time [8].
We call this curve data output curve in our model. We
defined bandwidth utilization, but we leave the study
of its impact on Q and others to the network
community, where they belong.
4.1. Network calculus
We first briefly describe related concept in [6], then
explain why our work supplies the missing part.
In [6] R(t) represents the instantaneous rate of
traffic from the stream flowing on the link at time t.
For any function R and constant ρ > 0 define the
function
( )( )(
∫
ts
( )( ) tRWρ
( )dttv∫
.
is the size of the backlog at time t in a
workconserving system, which accepts data at a rate
described by R and transmits data at a rate ρ. Its
geometric interpretation is as follows. Suppose t’ is
fixed and we want to findW
by considering all lines with slope ρ and choosing the
. We can do this
highest line such that the line is below
for all t ≤
t’. The value of W
∫
0
If b is any function defined on the nonnegative reals
and R is a nonnegative function such that
is then the difference
between
and the height of the chosen line at t’.
)
∞<<∞−
−−=
≤
tstRtRW
t
s
,max
ρ
ρ
( )( ) ' tR
ρ
∫
tR
0
( )( ) ' tR
ρ
'tR
for any y ≥ x, we write R ~ b.
Define b
write R ~ (σ, ρ), i.e., for all x, y satisfying y ≥ x there
(
xy −
ρ
(
xybR
y
x
−≤
∫
R
y
x
+≤
∫
σ
)
)
0(t) = σ + ρt with σ ≥ 0 and ρ ≥ 0. If R ~ b0, we
holds
. Clearly
( )( ) σ
ρ
tRW
≤
for all t if and only if R ~ (σ, ρ). If R ~ (σ, ρ), R
satisfies burstiness constraints. There is an upper
bound to the amount of traffic contained in any
interval that is equal to a constant σ plus a quantity
proportional to the length of the interval. ρ determines
an upper bound to the long term average rate of traffic
flow; σ allows for some burstiness. The larger σ is, the
more potential for burstiness.
A multiplexer has two or more input links and a
single output link. Consider a multiplexer with output
capacity Co and two input streams R1 and R2. The total
input traffic is R1 + R2. The size of the backlog in the
multiplexer at any time t is
( )( ) tRR
o
C21+
W
. Let R1
~ b1 and R2 ~ b2, then R1 + R2 ~ b12 = b1 + b2. If we
can find a constant α such that b12 ≤ α + Co x for all x,
then R1 + R2 ~ (α,
( )( )
α
≤+
tRRW
o
C21
for any t. The smallest such α
could be found from the concave conjugate of b. [6]
gave an expression defining such α but no algorithm to
actually calculate it.
While [6] assumes the data source characteristics
and develops its theory on top of it, we provide the
foundation to support this assumption and deliver
actual data source functions. By definition, R(t) = I(t).
Defined for different purpose and given different
formulae,
( )( ) tRWρ
in [6] and q(t) in our model are
closely related. Q could
of
( )( ) tR
ρ
W
. We are able to actually derive Q or get
the bound of Q whereas W
infinite area. Clearly data generated from our task set
satisfies the burstiness constraint. In our model, for Q
derived from any bandwidth B that is no less than the
average data rate, R ~ (Q, B). Since ρ corresponds to
the average data rate in [6], we should provide a value
as small as possible as the data source for the network.
Hence σ = Q
data source parameters, where QW is Q derived with
bandwidth W.
We could consider data from each task as a separate
data stream. For a task T, it outputs O bytes of data
every P time, the average data rate is w, its output
function repeats every L instead of P because T may be
scheduled at different time during each period within
L. For [6], if we set ρ = w, σ could be derived if we do
Co) and hence
be the maximum
is defined over an
( )( ) tR
ρ
W and ρ = W should be our answer to the
Page 8
not let other tasks to generate data and calculate Q for
the whole task set, or we could use the bound 2O – Cw
(refer to Theorem 4). We could model the data output
of the task set as the output of a multiplexer whose
input streams are the data output from all tasks in the
set. This, however, probably would not help us getting
a better R for the task set. We still have to find Rs for
individual tasks to apply this method. Besides,
applying this method ignores the fact that at any time
point, only one task could generate data. This means
the worst cases will not occur at the same time among
tasks. Although [6] gives a theorem to find the exact
output delay bound based on a multiplexer’s input
streams, the exact bound will still be larger than Q
derived in our work. By definition the method in that
theorem does not consider fixedtime offset among
tasks. In addition, it is hard to come up with an
algorithm to apply this method.
4.1. Vnet
If data generated from a realtime task has realtime
requirement, then we need a realtime network to
deliver data in time. Here we pick a realtime network
architecture VNet [9] to illustrate how our work fits
in.
VNet supports flexible delay guarantees for
applications in realtime networks. Applications
communicate over the VNet by using endtoend
network connections which support realtime and
reliability characteristics to meet the application’s
specific requirements. It is possible and efficient to
determine an upper bound on the delay of realtime
traffic when using the pernode delay assignment.
The realtime traffic specification in VNet is based
on a Linear Bounded Arrival Process (LBAP). LBAP
is characterized by a maximum burst size m, an
interval r, and the number of packets n, generated per
interval r. Once admitted by the VNet, the α percent of
data will be delivered to the destination within a
maximum endtoend delay and a maximum endto
end delay jitter.
For a task set, we could define m = 0, r = L, and n
()(
∑=
i
i
PL
1
/
=
. Normally L is too big for this to
be effective. It could put a big burden on the VNet.
We could define m = Q, r = any value, and n = rW.
Since in VNet extra data defined in m do not get
guaranteed delay, and since we do not know which
task’s data nor which part of the task’s data contributes
to the burst, data output from our task set could not be
modeled satisfactorily for the VNet traffic. In general
our model has no corresponding element for m in V
Net. A better approach is if we consider each task
separately. For one task, we have m = 0, r = P, and n =
O. The value α in VNet could be defined according to
each task’s feature.
[6] defines a set of network elements such as
constant delay line, receive buffer, multiplexer, etc.
What is missing is a data source element. Our work
describes such a network element. Note so far we try
to fit our model into the data source description
defined in the network architectures. To apply network
research result into real world examples, one first must
abstract the real world data source to fit the network
model, which might loose information. One could
imagine that if the data source description gets closer
to the real world examples, the performance
guaranteed by the network architectures will be
improved. Out work is a step towards to this direction.
If the network model accepts our data output curve
directly, better utilization of the network might be
achieved.
5. Scheduling policy’s effect
Data is generated during a task’s execution.
Different scheduling policies run a task at different
times, hence result in different output curves. So far
we have not considered the effect of a scheduling
policy on the data output curve. The buffer bounds we
derived in Section 3 are independent of the scheduling
policy used as long as no task misses deadlines. If a
task set is scheduled, any task T will generate O size of
data every P time units. However, the actual Q will be
different for different scheduling policy. Before we get
into the details of the differences, we need to justify
why it is necessary to minimize Q through the way we
schedule the task set.
The first subsection will demonstrate the need to
reduce Q with an oil drilling system. We then briefly
mention the difficulty of finding the optimal schedule
in the next subsection. The subsection afterwards is
devoted to comparing the Qs produced by different
scheduling policies. Some other simulation produced
comparisons are listed in the last subsection.
5.1. The reason for a smaller Q
A smaller Q means smoother data output pattern.
Any network architecture likes smooth data source.
The smoother the data source is, the less delay, less
jitter, less buffer, and bigger throughput the network
can manage. A smaller Q also means added benefit for
the data source itself. A smaller Q means less cache
required in the source system; a smaller Q means less
bandwidth idle waste when no data is generated. This
n
iO
)
Page 9
may become critical in embedded systems, which has
limited resources.
As an embedded example, Figure 5 depicts one of
many offshore oil drilling platforms. The drill bit at the
well bottom is controlled by the high speed mud
pumped in from the rig. The mud goes down within
the pipes, exits from the bit, and comes back between
the pipe and the drilling well. The pipe behind the bit
contains lots of sensors and control electronics. The
drilling engineer on the rig sends command to the drill
bit to control its speed and direction based on the
sensor data. The command is transmitted by adjusting
the mud pressure and speed. The data collected from
the sensors is sent back also through the mud by
modulating the mud upward flow with flapper valves
positioned on the pipe cylinder. Waves traveling in the
dense mud cannot be compared with electronic waves;
the data rate here is measured in bits per second. It is
so slow that a wellknown oil service company even
trumps its competition by holding patents sustaining up
to 16 bits/second upward rate. The company is now in
serious situation as one of the key patents is expiring
soon. There are companies putting a wire through the
drill pipe for communication, but the cost is too high
for the method to become main stream.
Figure 5: Offshore oil drilling
It is desirable that the uplink is kept to its full
capacity to transmit as much data as possible.
However, the average data generation rate from all
tasks should not exceed the bandwidth. In this drilling
example, extra data is saved within the pipe down
hole. It is dumped to the surface system each time the
drill bit is pulled out of the well. This is called
“recorded mode” in the drilling business.
There are hundreds of measuring devices that could
be used. Different combinations are used for different
geographical environment and custom needs. One
typical example includes orientation devices and one
or two formation evaluation
accelerometers placed mutually 90˚ apart could be
devices. Three
used to measure the orientation. Each accelerometer
outputs a real number between 1.0 and 1.0 at the end
of the measurement. A gamma ray detector could help
determine what kind of material the formation is
composed of. It measures the amount of gamma rays
per energy window. It periodically generates a list of
integers representing counts per second in the energy
windows. A neutron device helps determine the
density of the formation. A series of detectors are
placed in different distances from the neutron source.
The device periodically outputs the list of data from
the detectors. If not saved in the recorded mode, data
generated from above devices must be transmitted to
the surface at the mud baud rate. It is critical to save
resources in this drilling and measuring system. The
system down inside the well could be modeled as a
task set of three accelerometer tasks, one gamma ray
task, and a neutron task. We would like to have the
data ready exactly when the turn for it to transmit
comes. If possible, we would like to adjust the gamma
ray detector’s data output function to best suit
transmission.
5.3. The Difficulty to Compare Different
Scheduling Policies
Traditional realtime scheduling problem does not
consider data. If no deadline is missed under a
scheduling policy, the policy is considered good. For a
given task set, the comparison among scheduling
policies is normally if the task set is schedulable under
one policy but not under another policy. Many of the
scheduling problems are as hard as NP. Adding in the
data factor makes the problem even more difficult. We
have to meet the deadlines of all the tasks and
minimize the data in the buffer. Some samples of the
problem are listed here.
•
Given a task set, is there a fixed priority
schedule so that deadlines are met and Q is
smaller than a constant?
•
Given a task set, is there a schedule so that
deadlines are met and Q is smaller than a
constant?
•
Given a task set and a bandwidth
utilization, is there a schedule so that
deadlines are met and Q is smaller than a
constant?
•
Given a task set, find the best scheduling
policy in which the set is schedulable and
Q is minimized.
These problems are generally hard to solve. For the
first problem, if we set the constant to arbitrarily large,
it reduces to the problem to if there is a fixed priority
Page 10
schedule, which is NPhard. For any schedule
produced by a policy, we need to search at least L time
to find Q. L itself is already ( )
of the related problems to be NPhard.
5.3. Compare different scheduling policies
In this subsection we compare Qs with randomly
generated task sets. We run a schedule on randomly
generated task sets and then compare the data output
functions. We use three representing scheduling
policies, ratemonotonic (RMA) from fixed priority
policies, earliest deadline first (EDF) from dynamic
priority policies, and proportional fairness (PF) which
gives equal emphasis on the tasks. RMA gives priority
to a task. Higher priority tasks turn to be executed
continuously. EDF does not discriminate tasks, which
could be arbitrarily segmented by earlier deadline
tasks. Both RMA and EDF are workconserving. This
may be bad from data output perspective as
concentrated execution results in concentrated data
output. PF is not workconserving. It schedules a task
in proportion to its expected quota. We expect data
output to be evenly distributed by PF.
We first use a set of 10 tasks. The utilization is kept
no more than 0.7, which guarantees that all task sets
are schedulable by three scheduling policies. For each
test, we generate 1000 task sets. The periods range
from 10 to 50. To distinguish different o(t), the
execution time of a task is at least 2. So a 10task set
represents a set of short execution tasks, which is more
and more common with the fast increase of processor
powers. This also implies that a task is usually
scheduled in one piece during each request. To make
the distinction among scheduling policies bigger, we
also test with 5task sets, which have more execution
per task and more interference among tasks. First we
test the case when all tasks generate data; next we only
allow one task per set to generate data; last we provide
some other comparisons with regard to the experiment.
5.3.1. All Tasks Generate Data. First we consider the
case where all tasks may generate data. We compare
the Qs of different scheduling policies. We divide Q
by the bound in Theorem 4 and then take the average
of the 1000 tests. Between two policies, we divide
better smaller Qs by worse bigger Qs, count the
occurrences, and take the averages. Tables 1 through 4
show the result.
Table 1: Data output function could be any
n
e
Θ
. So we expect most
RMA EDF PF
Tasks per set 10 5 10 5 10 5
Q/bound(%) 40.3 45.5 40.3 45.5 32.5 37.1
Smallest Qs
Over
RM
A
Over
EDF
12
N/A
71 18
427
72
189
977
980
913
916 Count
Q1/Q 99.6 99.6 80.1 79.4
Count 288 207 977 915
Q1/Q2
Count
99.8
20
99.2
84
N/A
80.2
N/A
79.3
23 85 Over
PF
Q1/Q2 97.8 96.9 97.7 96.9
Table 2: All tasks are constantdatarate
RMA EDF PF
Tasks per set
Q/bound(%)
10
39.6
5
44.0
10
39.6
5
44.0
10
19.7
5
19.3
Smallest Qs
Over
RM
A
Over
EDF
0
N/A
0 0
315
0
168
1000
1000
1000
1000 Count
Q1/Q 100 100 49.7 43.9
Count 289 165 1000 1000
Q1/Q2
Count
99.9
0
99.5
0
N/A
49.7
N/A
43.9
0 0 Over
PF
Q1/Q2 NaN NaN NaN NaN
Table 3: All tasks are dataatend
RMA EDF PF
Tasks per set
Q/bound(%)
10
40.4
5
46.9
10
40.4
5
46.8
10
42.1
5
46.5
Smallest Qs
Over
RM
A
Over
EDF
552
N/A
411 613
360
483
280
135
141
447
477 Count
Q1/Q 99.8 98.6 97.6 94.7
Count 302 149 139 451
Q1/Q2
Count
99.9
859
99.3
519
N/A
97.6
N/A
94.8
861 545 Over
PF
Q1/Q2 95.0 96.4 95.0 96.4
Table 4: All tasks are dataatstart
RMA EDF PF
Tasks per set
Q/bound(%)
10
41.3
5
46.7
10
41.2
5
46.6
10
44.3
5
48.1
Smallest Qs
Over
RM
A
Over
EDF
466
N/A
658 762
521
723
222
25
26
157
154 Count
Q1/Q 99.3 99.6 98.3 96.1
Count 221 160 25 154
Q1/Q2
Count
99.9
974
99.6
841
N/A
98.3
N/A
96.0
975 840 Over
PF
Q1/Q2 93.0 95.6 92.7 95.6
Page 11
In many cases EDF and RMA produces the same Q
value. In Table 2 we use the bound in Corollary 2
since it is constantdatarate. In all the tests, the
average Q is always less than 50% of the bound. This
is because the bound is about twice of∑
normally a task generates O bytes per period. If o(t) is
random, PF has much more cases with the smallest Q
among 1000 tests. PF is always the best if all tasks are
constantdatarate. And the Qs for PF are much smaller
than those for RMA and EDF. This is because the only
variation is the data rate among tasks, and PF
schedules tasks at the proportional scale. Hence data is
more evenly generated. However, if all tasks are data
atend or dataatstart, RMA and EDF are better than
PF. But no one is a clear winner as the Q’s are within
90% or each other for all three policies. There is no
clear difference between RMA and EDF in any cases.
This can be explained that both policies are work
conserving and preempt tasks regardless of how the
data output function is. Q to bound ratio is mostly
bigger in 5task sets than 10task sets because 5task
sets have more intertask interferences and data from
different tasks collide more often. There is only one
exception with all constantdatarate task sets and PF,
where the difference (19.69% and 19.34%) is small.
We compare average data buffer in Tables 5 through
( )
qq
0
, and
=
n
k
k
O
1
8. In the tables
. We take the
averages of 1000 sets.
Table 5: Data output function could be any
()
L dtt
L
2/
2
=∫
RMA EDF PF
Tasks per set
Q/bound(%)
10
56.4
5
53.5
10
56.4
5
53.6
10
42.4
5
41.5
Smallest Qs
Over
RMA
0
N/A
20 0
527
28
433
1000
1000
959
961 Count
Q1/Q
Count
99.8
N/A
99.5 75.3
1000
76.7
962 473 367 Over
EDF
Q1/Q2
Count
99.7
0
98.9
39
75.3
N/A
76.6
0 38 Over
PF
Q1/Q2 NaN 96.2 NaN 96.4
Table 6: All tasks are constantdatarate
RMA EDF PF
Tasks per set
Q/bound(%)
10
54.4
5
57.4
10
54.4
5
46.6
10
28.5
5
23.7
Smallest Qs
Over
0
N/A
0 0
525
0
434
1000
1000
1000
1000 Count
RM
A
Over
EDF
Q1/Q 99.8 99.7 49.7 43.6
Count 475 366 1000 1000
Q1/Q2
Count
99.7
0
99.4
0
N/A
49.7
N/A
43.5
0 0 Over
PF
Q1/Q2 NaN NaN NaN NaN
Table 7: All tasks are dataatend
RMA EDF PF
Tasks per set
Q/bound(%)
10
57.0
5
54.7
10
57.0
5
54.5
10
53.0
5
50.1
Smallest Qs
Over
RM
A
Over
EDF
69
N/A
66 46
368
83
350
885
894
873
897 Count
Q1/Q 99.5 98.1 92.1 90.4
Count 632 450 892 877
Q1/Q2
Count
99.7
106
99.5
103
N/A
92.0
N/A
90.5
108 123 Over
PF
Q1/Q2 98.1 97.4 98.3 97.1
Table 8: All tasks are dataatstart
RMA EDF PF
Tasks per set
Q/bound(%)
10
55.6
5
52.8
10
55.6
5
52.7
10
57.8
5
53.7
Smallest Qs
Over
RM
A
Over
EDF
240
N/A
269 624
720
655
640
136
145
230
243 Count
Q1/Q 99.8 99.7 97.3 95.0
Count 280 160 137 238
Q1/Q2
Count
99.8
855
98.8
757
N/A
97.2
N/A
94.8
863 762 Over
PF
Q1/Q2 95.3 96.2 95.2 96.2
The result for q is similar to the result for Q. This
tells us that at least for these three policies, the data
output curves are normal. In other words, if a policy
generates larger Q, then q(t) turns to be larger as well.
Note in above tests a task may not generate any data
at all.
5.3.2. Single data task case. A task set with a single
data generating task is of interest by itself. As we have
mentioned it also helps analyzing prioritized data and
cases where a tasks data need to be transmitted
separately.
For RMA, the data generating task may have
different priorities, we consider three cases: highest,
lowest, and middle priorities. To save space, we list the
result for constantdatarate only task set because the
effect of different schedule is bigger. Where a task is
Page 12
scheduled directly affects the data output function. For
other two data output functions, only the time when the
task is started or finished is important. We have the
same set of tests as in above subsection. In addition,
we have three different results for each set of test.
Tables 9 through 11 show the result.
Table 9: Shortest period task generates
data
RMA EDF PF
Tasks per set
Q/bound(%)
10
50.8
5
51.6
10
51.4
5
52.1
10
26.5
5
26.0
Smallest Qs
Over
RM
A
Over
EDF
6
N/A
4 6
0
4
0
1000
994
1000
996 Count
Q1/Q NaN NaN 52.3 50.2
Count 140 100 994 996
Q1/Q2
Count
91.7
0
91.0
0
N/A
51.6
N/A
49.9
0 0 Over
PF
Q1/Q2 NaN NaN NaN NaN
Table 10: Middle period task generates data
RMA EDF PF
Tasks per set
Q/bound(%)
10
62.9
5
59.7
10
64.0
5
61.2
10
30.7
5
24.8
Smallest Qs
Over
RM
A
Over
EDF
4
N/A
4 4
189
4
79
1000
996
1000
996 Count
Q1/Q 100 100 48.9 41.9
Count 433 283 996 996
Q1/Q2
Count
96.4
0
92.1
0
N/A
48.0
N/A
40.8
0 0 Over
PF
Q1/Q2 NaN NaN NaN NaN
Table 11: Longest period task generates
data
RMA EDF PF
Tasks per set
Q/bound(%)
10
70.5
5
64.8
10
70.5
5
64.8
10
34.1
5
24.2
Smallest Qs
Over
RM
A
Over
EDF
3
N/A
2 3
251
2
68
1000
997
1000
998 Count
Q1/Q 100 100 48.4 37.2
Count 356 175 997 998
Q1/Q2
Count
100
0
100
0
N/A
48.4
N/A
37.2
0 38 Over
PF
Q1/Q2 NaN NaN NaN NaN
Although only one task generates data, PF still
performs significantly better than RMA or EDF simply
because we have constantdatarate tasks. This does
not matter if the data generating task has the highest
priority task in RMA. It is hard to compare q(t)s
among highest, lowest, middle priority tasks in three
tables. So we could not say if different priority
associated with the data task makes much difference.
Since the highest priority task will be executed in one
piece per request, we assume it will result in the worst
Q. However, given that the data for RMA and EDF are
close in all three tables and EDF does not assign fixed
priority to the data task, it seems that in RMA the
priority of the data task does not make a big difference.
5.3.3. Other comparisons. In this subsection we make
use of the simulation data gather above to compare
other aspects of the model. We first compare different
data output functions, then we look at the effect of
increased bandwidth. Again in table 12 we tested 1000
5task sets. We schedule each set 3 times with the
same Os but different o(t)s.
Table 12: Compare data output functions
consta
nt
data
rate
1000
41.58
978
1000
41.62
983
1000
18.29
1000
1000
56.42
1000
1000
57.83
1000
1000
23.66
1000
data
atend
data
at
start
Smallest Qs
Q/bound(%)
Smallest qs
Smallest Qs
Q/bound(%)
Smallest qs
Smallest Qs
Q/bound(%)
Smallest qs
Smallest Qs
Q/bound(%)
Smallest qs
Smallest Qs
Q/bound(%)
Smallest qs
Smallest Qs
Q/bound(%)
Smallest qs
0
46.90
22
0
46.76
17
0
46.52
0
4
60.06
2
4
61.52
2
4
54.94
2
0
46.65
0
0
46.64
0
0
48.10
0
4
60.06
2
4
61.47
2
4
55.17
2
RMA
EDF
All tasks
may
generate
data
PF
RMA
EDF
Only the
middle
period
task
generates
data
PF
Every task could be modeled as dataatend by
caching data generated during execution. We see the
benefit of more precise modeling of the task by
comparing the columns with the dataatend column.
The constantdatarate column has the best result. The
dataatstart and dataatend columns have similar
results. Other kinds of data output functions should
have Qs in between.
Page 13
As we have mentioned in Corollary 1, increasing B
reduces Q. The best Q may come from a different
policy when B increases. To show this point, let’s look
at Figure 6. There are two data output curves J1 and J2
for the same task set. If B = W, Q1 for J1 occurs at time
t1, Q2 for J2 occurs at time t0. We have Q1 > Q2. If we
set B equal to I1(0), the initial data output rate of J1, the
data transmission curve V1 for J1 coincides with J1. So
Q1 becomes 0. We can see that Q2 is still larger than 0.
We have Q1 < Q2. The order of Q1 and Q2 changes.
Table 13 shows the statistics for 5task sets when we
calculate Q’s improvement with B to be W versus
1.5W. 1.5W.
Figure 6: Q and data output curve Figure 6: Q and data output curve
In Table 13, the first column means: 1 – All tasks
may generate data; 2 – Only the shortest period task
generates data; 3 – Only the middle period task
generates data; 4 – Only the longest period task
generates data. generates data.
Table 13: The bandwidth’s effect Table 13: The bandwidth’s effect
In Table 13, the first column means: 1 – All tasks
may generate data; 2 – Only the shortest period task
generates data; 3 – Only the middle period task
generates data; 4 – Only the longest period task
Improvement on Q
(%) (%)
RM. EDF
Improvement on Q Q’s order switches
between schedules between schedules
RM.
EDF PF
24 283
3 0
35 333
15 139
0 0
0 0
0 0
0 0
0 0
0 0
36 0
44 0
38 0
Q’s order switches Output
function
PF RM. EDF
PF
286
0
339
137
0
0
0
0
0
0
0
0
0
Mixed
Constant
at end
at start
Constant
at end
at start
Constant
at end
at start
Constant
at end
at start
33.2
49.4
28.0
28.8
8.4
3.2
3.2
19.6
15.3
15.3
24.6
21.5
21.1
33.4
49.5
29.1
29.0
9.3
4.0
4.0
21.5
17.1
17.2
24.9
22.1
21.6
23.9
46.8
19.0
18.5
18.4
6.3
6.4
21.4
7.6
8.0
22.1
7.6
7.9
1
2
3
4
In general the improvement is smaller for task sets
with only one datagenerating task. In general PF has
less improvement than RMA and EDF. It is interesting
in the number of Q’s order switches when all tasks
may generate data. PF is the best for constantdatarate
because it is two times better than the other two. But
for other rows, there are a significant number of
switches between PF and the other two.
6. Conclusions
There is a need to model data output as an
independent aspect of a realtime task. Many real
world applications generate data in different ways
during their executions. In this paper we introduced a
data outputting realtime task model. In this model a
task produces a fixed amount of data during each
execution. The data may be generated at any instant of
the execution. Our model is the first to distinguish
execution and data, and is able to combine them into
one system. It provides more reasonable meaning to
the issues of jitter and task value functions. Our model
is also the first to study the arrival curve of the data
source for the network community.
We investigated the data output function of a task
set, derived bounds of the maximum buffer size in
order not to lose data during transmission. Our work
provides parameter values to describe input traffic to
network transmission architectures, which is often
ignored by either realtime or network communities.
We also looked into the effect of different scheduling
policies on the data output curve. In the past a
scheduling policy is valued with schedulability only.
Detailed experiment is conducted to provide the
insight comparing scheduling policies, data output
curves, and transmission bandwidths.
We motivated our work with real world examples.
The actual problems may be more complex than is
abstracted here. For example, we do not allow varied
output per execution. This is our first step towards
considering data as one important factor in a realtime
task. There are many interesting topics about the model
itself, many of which are mentioned throughout the
paper. Study on these problems will be reported in the
future.
7. References
[1] S. K. Baruah, Fairness in Periodic RealTime
Scheduling, IEEE RealTime Systems Symposium,
December 1995, P200209
[2] S. K. Baruah, N. K. Cohen, C. G. Plaxton, and D. A.
Varvel, Proportionate Progress: A Notion of Fairness in
Resource Allocation, Algorithmica, December 1996,
Vol15, P600625
byte
J1
J2
time
t0
0 t1
L
Page 14
[3] S. K. Baruah and S.S. Lin, Pfair Scheduling of
Generalized Pinwheel Task Systems, IEEE Transactions
on Computers, July 1998, Vol 47(7), P812816
[4] D. Chen, A. K. Mok, and S. K. Baruah, On Modeling
Realtime Task Systems, Lecture Notes in Computer
Science  Lectures on Embedded Systems, October
1997, Vol1494
[5] D. Chen, M. Nixon, R. Shepard, and A. K. Mok, The
Effect of Limited Network Bandwidth on Data
Buffering for RealTime Tasks, IEEE Workshop on
ConstraintAware Embedded Software, December 2003
[6] R. L. Cruz, A calculus for network delay. I. Network
elements in isolation, IEEE Transactions on Information
Theory, 1991, Vol37(1), P114131
[7] R. L. Cruz, A calculus for network delay. II. Network
analysis, IEEE Transactions on Information Theory,
1991, Vol37(1), P132141
[8] R. L. Cruz, Quality of service guarantees in virtual
circuit switched networks, IEEE Journal on Selected
Areas in Communications, 1995, Vol13 (6), P1048
1056
[9] B. Field and T. Znati and D. Mosse, VNET: A
Versatile Network Architecture for Flexible Delay
Guarantees in RealTime Networks, IEEE Transactions
on Computers, 2000, Vol 49(8), P841858
[10] K. Jeffay and S. Goddard, A Theory of RateBased
Execution, IEEE RealTime Systems Symposium,
December 1999, P304314
[11] C. L. Liu and J. W. Layland, Scheduling Algorithms for
Multiprogramming in a HardRealTime Environment,
Journal of ACM, 20(1), January 1973
[12] J. W. S. Liu and K.J. Lin and W.K. Shih, and A. C.
Yu, Algorithms for
Computations, IEEE Computer, 1991, P5868
[13] A. K. Mok and D. Chen, A Multiframe Model for Real
Time Tasks, IEEE
Engineering, October 1997, Vol 23(10), P635645
[14] A. K. Mok, Fundamental Design Problems of
Distributed Systems
Environment, Ph.D. Thesis, MIT 1983
[15] B. Sprunt, L. Sha, and J. P. Lehoczky, Aperiodic Task
Scheduling for Hard RealTime Systems, RealTime
Systems: The International Journal of TimeCritical
Computing Systems, Vol1, 1989, P2760
Scheduling Imprecise
Transactions on Software
for the HardRealTime
View other sources
Hide other sources
 Available from Aloysius Mok · Jul 15, 2014
 Available from cs.utexas.edu