1. 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

2. 2 Outline  Overview and motivation  Deferrable scheduling alg and analysis: –Deferrable Scheduling (DS): A fixed priority scheduling algorithm for maintaining freshness of real- time data –Processor utilization analysis  Performance Studies  Conclusions and Future Work

3. Deferrable Scheduling – RTSS 2005 3 RTDB Model for Maintaining Temporal Validity of Real-Time Data Real-Time Databases Network Sensor 1 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

4. Deferrable Scheduling – RTSS 2005 4 What is Data Temporal Validity in RTDBs? Temporal Validity: keep data valid relative to real world Time Value X 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 0 1 2 3 4 5

5. Deferrable Scheduling – RTSS 2005 5 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.

6. Deferrable Scheduling – RTSS 2005 6 Maintaining Temporal Validity of Real-Time Data V t+V t V : Validity length t’+V t’ V Real-time data X i is sampled by periodic update sensor transaction T i – X i has to be refreshed before its validity interval expires – Validity duration updated upon refresh Prior work guaranteeing successful completion of two instances (jobs) of T i within V i : Periodic scheduling approaches – Temporal validity maintenance in RTDBs – Real-time age-constraint scheduling

7. Deferrable Scheduling – RTSS 2005 7 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 V t P=D t+V/2 t +V t 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 P=D D t t+V/2 t +V t P ML HH

8. Deferrable Scheduling – RTSS 2005 8 More-Less [Xiong and Ramamritham]: For a set of transactions {T i } (1  i  m) Validity Constraint (to ensure data validity) : Period + Relative Deadline  Validity Length More-Less Principle: Definition Deadline Constraint (to reduce workload) : Computation Time  Relative Deadline  Period Schedulability Constraint (by deadline monotonic) : Response time of the 1 st instance  Relative Deadline Note: 1 st 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 ?

9. Deferrable Scheduling – RTSS 2005 9 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 (T i ) = Validity Length (T i ) - WCRT (T i ) –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(T i,j, T i,j+1 ) = Validity Length(T i ) – ResponseTime(T i,j+1 ) –Relative deadline and separation of two instances are varied for all instances of a transaction  DS increases the average separation of two consecutive instances, but it lacks scheduling theory (e.g., sufficient condition for feasibility)

10. Deferrable Scheduling – RTSS 2005 10 Deferrable Scheduling: Illustration Validity Length V i r i,0 d i,1 r i,1 d i,1 r’ i,1 T i,0 T i,1 Higher-priority preemption d i,0 DiDi DiDi How to determine the response time of T i,1 if it completes at d i,1 ? r i,j : Sampling(Release) time of T i,j d i,j : Absolute deadline of T i,j ViVi d i,2 ViVi d’ i,2

11. Deferrable Scheduling – RTSS 2005 11 Deferrable Scheduling: Key Steps  Release time r i,j for transaction instance T i,j is derived backwards from its deadline d i,j : 1)d i,j+1 = r i,j + V i (validity constraint) 2)r i,j+1 = d i,j+1 – ResponseTime(T i,j+1 ) 3)ResponseTime(T i,j+1 ) = HPPreemption(r i,j+1, d i,j+1 ) + C i HPPreemption(r i,j+1, d i,j+1 ) is the total amount of processor demand from higher priority transactions during [r i,j+1, d i,j+1 ]. 4)HPPreemption(r i,j+1, d i,j+1 ) can be derived only if the schedule of all higher priority transactions of T i up to d i,j+1 have been determined  Note that Eq 2) above can be solved by an iterative algorithm in fixed priority scheduling

12. Deferrable Scheduling – RTSS 2005 12 Example: Comparison of More-Less and DS Example: ML Parameters CiCi ViVi DiDi PiPi T1T1 1514 T2T2 21037 T3T3 220614

13. Deferrable Scheduling – RTSS 2005 13 Example: Comparison of More-Less and DS Example: ML Parameters CiCi ViVi DiDi PiPi T1T1 1514 T2T2 21037 T3T3 220614

14. Deferrable Scheduling – RTSS 2005 14 Example: Comparison of More-Less and DS Example: ML Parameters CiCi ViVi DiDi PiPi T1T1 1514 T2T2 21037 T3T3 220614

15. Deferrable Scheduling – RTSS 2005 15 Deferrable Scheduling: Processor Utilization Estimation  Given transaction set T = {T i } ( 1  i  m) that can be scheduled by More-Less, suppose T i has higher priority than T j if i<j.  Processor utilization estimation for deferrable scheduling: –D i : Average relative deadline (response time) of transaction T i –P i : Average period of transaction T i –D i = C i + –P i = V i – D i –Average period and deadline of transaction T i ( 1  i  m) can be computed from the highest priority transaction (T 1 ) to the lowest priority transaction (T m ) based on the above two formulas. Estimated Processor Utilization: U est =

16. Deferrable Scheduling – RTSS 2005 16 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

17. Deferrable Scheduling – RTSS 2005 17 Performance Studies: Processor Utilization Comparison Deferrable Scheduling (DS): theoretical estimation matches experimental results DS significantly outperforms More-Less DS processor utilization is very close to the lower bound sum(C i /(V i -C i ))

18. Deferrable Scheduling – RTSS 2005 18 Performance Comparison: Average Period Comparison DS Average Period (P ds ) is significantly larger than More-Less period (P ml ) ! Difference of average period increases with the decrease of trans. priority

19. Deferrable Scheduling – RTSS 2005 19 Performance Studies: Response Time Comparison for Triggered Transactions Triggered transactions do not have deadlines Triggered transactions under DS significantly outperform those under More-Less

20. Deferrable Scheduling – RTSS 2005 20 Performance Studies: Average Age of Data Average age of data of triggered transactions at commit time under DS is slightly older than that under ML

21. Deferrable Scheduling – RTSS 2005 21 Performance Studies: Missed Deadline Ratio for Triggered Transactions Triggered transactions have deadlines Triggered transactions under DS significantly outperform those under More-Less

22. Deferrable Scheduling – RTSS 2005 22 Conclusions Proposed Deferrable Scheduling (DS) for fixed priority transactions maintaining real- time 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

23. Deferrable Scheduling – RTSS 2005 23 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 ?

24. Backup Slides

25. Deferrable Scheduling – RTSS 2005 25 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]

26. Deferrable Scheduling – RTSS 2005 26 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

27. Deferrable Scheduling – RTSS 2005 27 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

28. Deferrable Scheduling – RTSS 2005 28 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

29. Deferrable Scheduling – RTSS 2005 29 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

30. Deferrable Scheduling – RTSS 2005 30 Reducing DS On-line Scheduling Overhead  Worst-case time complexity of on-line scheduling is O(mV m 2 ) –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

31. Deferrable Scheduling – RTSS 2005 31 Deferrable Scheduling with Hyper- period (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 U est  Off-line Schedule Adjustment (DESH-SA) Alg –Finds an interval [0, t end ] in a partial DS schedule that has its utilization close to U est –Adjusts the schedule backwards from t end so that the schedule in [0, t end ] can be repeated on-line without violating the validity constraint

32. Deferrable Scheduling – RTSS 2005 32 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)

33. Deferrable Scheduling – RTSS 2005 33 Performance Results: DESH Algs DESH-SA has CPU utilization close to DS DESH-SC only works when CPU workload is low (<= 30 sensor trans)

34. Deferrable Scheduling – RTSS 2005 34 Performance Results: Hyper-period Length Comparison DESH-SC Hyper-period length increases rapidly as the sensor transaction workload increases