A Deferrable Scheduling Algorithm for Real-Time
Transactions Maintaining Data Freshness
Ming Xiong
Bell Labs Research, Lucent Technologies
Song Han, Kam-yiu Lam
City University of Hong Kong
Deferrable Scheduling – RTSS 2005
Outline
 Overview and motivation
 Deferrable scheduling alg and
analysis:
– Deferrable Scheduling (DS): A
fixed priority scheduling algorithm
for maintaining freshness of realtime data
– Processor utilization analysis
 Performance Studies
 Conclusions and Future Work
2
Deferrable Scheduling – RTSS 2005
RTDB Model for Maintaining Temporal
Validity of Real-Time Data
Sensor 1
Network
Real-Time
Databases
Sensor 2
....
Sensor N
•
•
A real-time object in RTDBs models a real world entity, e.g., position of an aircraft
Values are sampled by sensors, and propagated to RTDBs
1. Assume that propagation delay is zero
2. Non-zero delay can be transformed to zero delay
Validity Length (zero delay) = Validity Length (non-zero delay) – Max Delay
•
Real-time data in RTDBs must remain fresh in order to react to abnormal situations
timely
•
Transactions may be triggered to deal with abnormal situations
3
Deferrable Scheduling – RTSS 2005
What is Data Temporal Validity in
RTDBs?
Temporal Validity: keep data valid relative to real world
Value
X
0 1
2
3
4
5
Time
• Real-time data values change continuously
• Data values are sampled periodically
• A validity interval is associated with a data value
• Within validity interval, a data value is fresh (temporally valid)
– deviation from real world is acceptable
4
Deferrable Scheduling – RTSS 2005
Applications with Temporal Validity
in RTDBs
 Air traffic control [Huo, Kuo & Mok 97]:
– Real-time data: aircraft position, speed, direction,
altitude, etc.
• 20,000 data entities
• validity intervals of 1 ~ 10 seconds
 Auto engine process control [Hansson 04]:
– Real-time data: pressure, temperature, etc.
5
Deferrable Scheduling – RTSS 2005
Maintaining Temporal Validity of
Real-Time Data
V
V : Validity length
t
t+V
V
t’
t’+V
• Real-time data Xi is sampled by periodic update sensor
transaction Ti
– Xi has to be refreshed before its validity interval expires
– Validity duration updated upon refresh
• Prior work guaranteeing successful completion of two instances
(jobs) of Ti within Vi: Periodic scheduling approaches
– Temporal validity maintenance in RTDBs
– Real-time age-constraint scheduling
6
Deferrable Scheduling – RTSS 2005
Prior Work:
Half-Half (HH) & More-Less (ML)
Definition:
 X : Real-Time Data
 V : Validity Interval Length
 T : Trans Updating X
 P : Period of T
 D : Relative Deadline of T
P=D
t
P=D
t +V
t+V/2
D
P
t
HH
t+V/2
ML
t +V
V
Observation : Data validity can be guaranteed if
Period + Relative Deadline  Validity Length
Half-Half
: Sample at twice the rate of change (P = D = V/2)
More-Less : P  V/2 & D  V/2
7
Deferrable Scheduling – RTSS 2005
More-Less Principle: Definition
More-Less [Xiong and Ramamritham]: For a set of
transactions {Ti} (1  i  m)
• Validity Constraint (to ensure data validity) :
Period + Relative Deadline  Validity Length
• Deadline Constraint (to reduce workload) :
Computation Time  Relative Deadline  Period
• Schedulability Constraint (by deadline monotonic) :
Response time of the 1st instance  Relative Deadline
Note: 1st instance response time is the longest response time
of all instances of a transaction if all periodic transactions
start synchronously (at same time)
Is more-less the best in terms of minimizing CPU workload ?
8
Deferrable Scheduling – RTSS 2005
Intuition of Deferrable Scheduling

More-Less: Periodic approach that is unnecessarily pessimistic
– More-Less uses the worst-case response time (WCRT) of a transaction as its
relative deadline
– Period (Ti) = Validity Length (Ti) - WCRT (Ti)
– Relative deadline and period are fixed for all instances of a transaction

DS: Sporadic approach that allows variable separations and
relative deadlines for instances of a transaction
– DS uses response time of an instance as the relative deadline of the
instance
– Separation(Ti,j, Ti,j+1) = Validity Length(Ti) – ResponseTime(Ti,j+1)
– Relative deadline and separation of two instances are varied for all instances
of a transaction

9
DS increases the average separation of two consecutive
instances, but it lacks scheduling theory (e.g., sufficient
condition for feasibility)
Deferrable Scheduling – RTSS 2005
Deferrable Scheduling: Illustration
Ti,0
Validity
Length Vi
ri,0
Di
di,0
Ti,1
Higher-priority
preemption
ri,1
ri,j: Sampling(Release) time of Ti,j
di,j: Absolute deadline of Ti,j
Di
di,1
Vi
di,2
r’i,1
Vi
di,1
d’i,2
How to determine the response time of Ti,1 if it completes at di,1?
10
Deferrable Scheduling – RTSS 2005
Deferrable Scheduling: Key Steps

Release time ri,j for transaction instance Ti,j is
derived backwards from its deadline di,j :
1)
2)
3)
4)

11
di,j+1 = ri,j + Vi
(validity constraint)
ri,j+1 = di,j+1 – ResponseTime(Ti,j+1 )
ResponseTime(Ti,j+1 ) = HPPreemption(ri,j+1, di,j+1 ) + Ci
HPPreemption(ri,j+1, di,j+1 ) is the total amount of processor
demand from higher priority transactions during [ri,j+1,
di,j+1 ].
HPPreemption(ri,j+1, di,j+1 ) can be derived only if the
schedule of all higher priority transactions of Ti up to di,j+1
have been determined
Note that Eq 2) above can be solved by an
iterative algorithm in fixed priority scheduling
Deferrable Scheduling – RTSS 2005
Example: Comparison of
More-Less and DS
Ci
Vi
Di
Pi
T1
1
5
1
4
T2
2
10
3
7
T3
2
20
6
14
Example:
ML Parameters
T1
r 3 ,1
0
5
10
15
T2
r 2 ,3
20
T3
r 2 ,4
25
30
(a ) M L S c h e d u le
r 2 ,3
0
5
10
15
20
(b ) D S S c h e d u le (T 1 & T 2 )
12
Deferrable Scheduling – RTSS 2005
r 2 ,4
25
30
Example: Comparison of
More-Less and DS
Ci
Vi
Di
Pi
T1
1
5
1
4
T2
2
10
3
7
T3
2
20
6
14
Example:
ML Parameters
T1
r 3 ,1
0
5
10
15
T2
r 2 ,3
20
T3
r 2 ,4
25
30
(a ) M L S c h e d u le
r 3 ,1
0
5
10
15
20
(b ) D S S c h e d u le (T 1 , T 2 & T 3 )
13
r 2 ,4
r 2 ,3
Deferrable Scheduling – RTSS 2005
25
30
Example: Comparison of
More-Less and DS
Ci
Vi
Di
Pi
T1
1
5
1
4
T2
2
10
3
7
T3
2
20
T1
6
Example:
ML Parameters
T2
S a m p lin g
T im e
S h iftin g
14
T2
T3
r 3 ,1
0
5
10
15
(a ) M L S c h e d u le
0
5
10
r 2 ,3
20
r 3 ,1
15
T3
S a m p lin g
T im e
S h iftin g
25
30
r 2 ,4
r 2 ,3
20
(b ) D S S c h e d u le
14
r 2 ,4
Deferrable Scheduling – RTSS 2005
25
30
Deferrable Scheduling:
Processor Utilization Estimation
 Given transaction set T = {Ti} ( 1  i  m) that can be scheduled
by More-Less, suppose Ti has higher priority than Tj if i<j.
 Processor utilization estimation for deferrable scheduling:
–
–
–
–
–
15
Di : Average relative deadline (response time) of transaction Ti
Pi : Average period of transaction Ti
i 1
Di = Ci +  j  1 ( D i / P j )  C j
Pi = Vi – Di
Average period and deadline of transaction Ti ( 1  i  m) can be
computed from the highest priority transaction (T1) to the lowest
priority transaction (Tm) based on the above two formulas.
m
• Estimated Processor Utilization: Uest =  i 1 ( C i / Pi )
Deferrable Scheduling – RTSS 2005
Performance Studies
 Experiments are conducted by simulation
– Single CPU RTDB with all real-time data in
main memory
– Sensor and triggered transactions are
generated following an air traffic control
application
16
Deferrable Scheduling – RTSS 2005
Performance Studies:
Processor Utilization Comparison
Sum (Ci / ( Vi - Ci))
DS (Expt.)
DS (Theoretical Est.)
More-Less
Processor Utilization
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
50
100
150
200
250
300
Number of Sensor Transactions
• Deferrable Scheduling (DS): theoretical estimation matches experimental results
• DS significantly outperforms More-Less
• DS processor utilization is very close to the lower bound sum(Ci/(Vi-Ci))
17
Deferrable Scheduling – RTSS 2005
Performance Comparison:
Average Period Comparison
Pds - Pml
4000
3500
Pds - Pml
3000
2500
2000
1500
1000
500
0
1
51
101
151
201
251
Transaction Priority
• DS Average Period (Pds) is significantly larger than More-Less period (Pml) !
• Difference of average period increases with the decrease of trans. priority
18
Deferrable Scheduling – RTSS 2005
Performance Studies:
Response Time Comparison
for Triggered Transactions
More-Less
DS
Response Time (Triggered
Trans)
250
200
150
100
50
0
50
100
150
200
250
Number of Sensor Transactions
• Triggered transactions do not have deadlines
• Triggered transactions under DS significantly outperform those under More-Less
19
Deferrable Scheduling – RTSS 2005
Performance Studies:
Average Age of Data
DS
ML
1.00006
Data Age at Commit
1.00005
1.00004
1.00003
1.00002
1.00001
1
0.99999
0.99998
0.99997
50
100
150
200
250
No. of Sensor Transactions
• Average age of data of triggered transactions at commit time under DS is slightly
older than that under ML
20
Deferrable Scheduling – RTSS 2005
Performance Studies:
Missed Deadline Ratio
for Triggered Transactions
ML
DS
0.35
Missed Deadline Ratio
(Triggered Trans.)
0.3
0.25
0.2
0.15
0.1
0.05
0
50
100
150
200
250
No. of Sensor Transactions
• Triggered transactions have deadlines
• Triggered transactions under DS significantly outperform those under More-Less
21
Deferrable Scheduling – RTSS 2005
Conclusions
• Proposed Deferrable Scheduling (DS) for
fixed priority transactions maintaining realtime data freshness
• Proposed processor utilization analysis for
DS
• Demonstrated that DS is optimal for
minimizing processor utilization in
experiments
• Demonstrated that DS significantly
outperforms More-Less in experiments
22
Deferrable Scheduling – RTSS 2005
Future Work
 Open questions:
– Is time 0 a critical instant for synchronous
sensor transactions ?
– What is a sufficient and necessary condition
for DS feasibility ?
– What is processor utilization bound for DS
feasibility ?
– How much can DS improve the feasibility of
More-Less ?
23
Deferrable Scheduling – RTSS 2005
Backup Slides
Related Work
 Deterministic approaches for temporal
consistency maintenance
– Half-Half (HH) approach
• Period = Deadline = V/2
– [Ramamritham, Distributed & Parallel DBs,
1993]
– [Ho, Kuo & Mok, RTSS, 1997]
– More-Less (ML) approach
• Deadline <= Period,
• Deadline + Period = V,
• Deadline monotonic scheduling
– [Xiong & Ramamritham, RTSS, 1999]
– [Xiong & Ramamritham, IEEE TC, 2004]
25
Deferrable Scheduling – RTSS 2005
Overview of RTDBs (I)
 What are RTDBs ?
– database systems that deal with workloads with timing
constraints (e.g., deadlines)
• Transactions
• Queries
 What timing constraints do RTDBs have ?
– Hard deadlines
• Deadlines that must meet
– Soft deadlines
• Values of transactions are functions of completion
time
– Full value if a deadline is met
– Partial value if a deadline is missed
– Firm deadlines
• Full value if a deadline is met, otherwise none
26
Deferrable Scheduling – RTSS 2005
Overview of RTDBs (II)
 What scheduling algorithms are necessary ?
– Real-time scheduling (versus time sharing scheduling)
• Priority based scheduling that is cognizant of
timing constraints
• Traditional real-time scheduling algorithms
– Earliest deadline first, least slack
first, etc.
– Rate monotonic, deadline monotonic,
etc.
 Problems in RTDBs
– Data conflict and resolution
– CPU scheduling
– Disk scheduling
– Memory management
27
Deferrable Scheduling – RTSS 2005
Deriving Deadlines and Periods:
Intuition of More-Less Principle
•
•
Data validity can be guaranteed if
 Period + Relative Deadline <= Validity Length
(1)
To reduce the workload (C/P) imposed by T without
violating (1) :
 Increase period to be more than half of validity length
 Decrease relative deadline to be less than half of validity length
•
If relative deadline <= period,
 deadline monotonic scheduling is an optimal fixed priority
scheduling alg
 Shortest validity first (SVF) priority assignment: a transaction gets
higher priority if its validity length is shorter
28
Deferrable Scheduling – RTSS 2005
DS Feasibility Analysis:
A Sufficient Condition
 Theorem: Given a synchronous sensor transaction
set T, if T can be scheduled by More-Less, then it can
also be scheduled by Deferrable Scheduling.
– Synchronous means that the first instances of all transactions
are released at the same time
29
Deferrable Scheduling – RTSS 2005
Reducing DS On-line Scheduling
Overhead
 Worst-case time complexity of on-line scheduling is
O(mVm2)
– It is much higher than More-Less (O(1))
 Time complexity of on-line scheduling can be reduced
by making DS based hyper-period schedule (off-line)
– Periodic on-line scheduling (O(1))
– On-line space overhead to maintain schedule information is
low
30
Deferrable Scheduling – RTSS 2005
Deferrable Scheduling with Hyperperiod (DESH)
 Criteria for hyper-period: two consecutive instances of a
transaction satisfy the validity constraint
– Two instances in the same hyper-period
– Two instances across two hyper-periods
 Off-line Schedule Construction (DESH-SC) Alg
– Finds an interval in a partial DS schedule that is repeatable and its
utilization is close to Uest
 Off-line Schedule Adjustment (DESH-SA) Alg
– Finds an interval [0, tend] in a partial DS schedule that has its
utilization close to Uest
– Adjusts the schedule backwards from tend so that the schedule in
[0, tend] can be repeated on-line without violating the validity
constraint
31
Deferrable Scheduling – RTSS 2005
DESH-SA Alg
 Finds an idle time t
– Repeats the schedule in [0, t] for Ti if Ti and its higher
priority transactions satisfy the validity constraint for the last
instance before t and the first instance after t
– Otherwise,
• Pushes back the first Ti instance after t and sets t as its
deadline, and computes its release time
• If its release time < its prior instance’s absolute deadline,
adjusts the schedule of its prior instance (may incur ripple
effect)
32
Deferrable Scheduling – RTSS 2005
Performance Results: DESH Algs
More-Less
DS(Theoretical Est.)
DESH-SA
DESH-SC
0.8
CPU Utilization
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
10
15
20
25
30
50 100 150 200 250 300
Number of Sensor Transactions
• DESH-SA has CPU utilization close to DS
• DESH-SC only works when CPU workload is low (<= 30 sensor trans)
33
Deferrable Scheduling – RTSS 2005
Performance Results:
Hyper-period Length Comparison
DESH-SC
DESH-SA
Hyper-period Length (X 1000
ms)
2500
2000
1500
1000
500
0
10
15
20
25
30
50 100 150 200 250 300
Number of Sensor Transactions
34
• DESH-SC Hyper-period length increases rapidly as the sensor transaction
workload increases
Deferrable Scheduling – RTSS 2005