Misconceptions About Real Time


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Misconceptions About Real Time

  1. 1. Misconceptions About Real-time Computing : A Serious Problem for Next-generation Systems J. A. Stankovic, Misconceptions about Real-Time Computing: A Serious Problem for Next Generation Systems , IEEE Computer, 21(10), pp. 10-19, October 1988.
  2. 2. Real-Time Computing <ul><li>The correctness of the system </li></ul><ul><ul><li>Logical result of the computation </li></ul></ul><ul><ul><ul><li>Functional correctness </li></ul></ul></ul><ul><ul><li>Time to produce the result </li></ul></ul><ul><li>Next generation RT system </li></ul><ul><ul><li>Distributed/adaptive </li></ul></ul><ul><ul><li>Online guarantees </li></ul></ul><ul><ul><li>Long lifetime </li></ul></ul>
  3. 3. There is no science in RT system design <ul><li>Most good science grew out of attempts to solve practical problems </li></ul><ul><li>Real-time system engineers need help </li></ul><ul><ul><li>The first flight of a space shuttle was delayed due to a subtle timing bug due to a transient overload during system initialization </li></ul></ul><ul><ul><li>A scientific framework to prevent such a bug to be included is needed </li></ul></ul><ul><ul><li>Real-time scheduling, resource management, RT programming language, … </li></ul></ul>
  4. 4. Advances in supercomputer hardware will cover RT requirements <ul><li>One can exploit parallel processors to improve throughput </li></ul><ul><ul><li>It does not mean timing constraints can be met automatically </li></ul></ul><ul><li>Unless HW is designed to perfectly match the application, the processors and their communication subsystems may not be able to handle all of the task load and time-critical traffic </li></ul><ul><ul><li>Real-time task and communication scheduling can get harder as more hardware is used </li></ul></ul>
  5. 5. <ul><ul><li>Demand for computational power often exceeds supply </li></ul></ul><ul><ul><li>Intelligent management of finite resources is required </li></ul></ul>
  6. 6. RT Computing = Fast Computing <ul><li>RT computing </li></ul><ul><ul><li>The objective of fast computing is to minimize the average response time </li></ul></ul><ul><ul><li>The objective of real-time computing is to meet the individual timing requirement of each task </li></ul></ul><ul><ul><ul><li>Meet individual task deadlines </li></ul></ul></ul><ul><ul><li>Fast computing cannot necessarily provide predictability </li></ul></ul><ul><ul><ul><li>Fastest hardware & software used in the space shuttle failed to support the timing requirements </li></ul></ul></ul><ul><ul><ul><li>Testing is not the answer </li></ul></ul></ul>
  7. 7. <ul><ul><li>Fast is relative </li></ul></ul><ul><ul><li>Worst case, not average case, response time matters </li></ul></ul><ul><ul><li>Not speed but predictability is the goal </li></ul></ul><ul><ul><li>Functional and timing behaviors should be as deterministic as necessary to satisfy system specification </li></ul></ul><ul><ul><li>Guarantee the delay is shorter than the upper bound </li></ul></ul><ul><ul><li>Predictability is not only hardware or algorithmic issue </li></ul></ul><ul><ul><ul><li>The delay statement in Ada only specifies the minimum delay before the next task is scheduled </li></ul></ul></ul><ul><ul><ul><li>Many things, including scheduling theory, software design, formal methods, RTOS, can change things </li></ul></ul></ul>
  8. 8. RT Programming = Assembly Coding, Priority Interrupt Programming, Device Driver Writing <ul><li>Hand-coding may have bugs, especially large RT program </li></ul><ul><li>Objective in RT research </li></ul><ul><ul><li>Automate </li></ul></ul><ul><ul><li>Customized resource scheduler from timing-constraint spec. </li></ul></ul>
  9. 9. RT System Research = Performance Engineering <ul><li>To investigate effective resource allocation strategies to satisfy timing-behavior requirement (≈Perf. Engineering) </li></ul><ul><li>Specification & verification of timing behavior </li></ul><ul><li>Programming language semantics </li></ul><ul><li>Theoretical problems </li></ul>Common misconceptions(5)
  10. 10. Real-time systems function in static environment <ul><li>Not necessarily true </li></ul><ul><li>Once deployed, real-time systems stay for more than 10 years </li></ul><ul><li>Many embedded real-time systems these days need configurable, composable RTOS </li></ul>
  11. 11. Main Research Issues <ul><li>Specification and verification </li></ul><ul><ul><li>Modeling and verification of systems that are subject to timing constraints </li></ul></ul><ul><li>RT scheduling theory </li></ul><ul><ul><li>Meet the specified timing requirements </li></ul></ul><ul><ul><li>Support the utilization bound to meet all deadlines </li></ul></ul><ul><ul><li>Meet as many deadlines as possible, if it is impossible to meet all deadlines </li></ul></ul>
  12. 12. Main Research Issues <ul><li>RTOS </li></ul><ul><ul><li>Guarantee RT constraint </li></ul></ul><ul><ul><li>Support FT and distribution </li></ul></ul><ul><ul><li>Scheduling time-constrained resource allocation </li></ul></ul><ul><li>RT programming language and design methodology </li></ul><ul><ul><li>High level abstraction to deal with complex real-time systems </li></ul></ul><ul><ul><li>Management of time </li></ul></ul><ul><ul><li>Schedulability check </li></ul></ul><ul><ul><li>Reusable RT software module </li></ul></ul>
  13. 13. Main Research Issues <ul><li>(Distributed) RTDB </li></ul><ul><ul><li>Concurrency in transaction processing </li></ul></ul><ul><ul><li>RT scheduling algorithm </li></ul></ul><ul><li>Fault tolerance </li></ul><ul><ul><li>Formal specification of the timing constraints </li></ul></ul><ul><ul><li>Error handling </li></ul></ul><ul><li>RT system architecture </li></ul><ul><ul><li>Interconnection topology (process, I/O) </li></ul></ul><ul><ul><li>Fast, reliable, and time-constrained communication </li></ul></ul><ul><ul><li>Cost-effective and integrated fashion </li></ul></ul><ul><ul><li>WCET analysis </li></ul></ul>
  14. 14. Main Research Issues <ul><li>RT communication </li></ul><ul><ul><li>End-to-end deadlines </li></ul></ul><ul><ul><li>Packet scheduling </li></ul></ul><ul><ul><li>Dynamic routing </li></ul></ul><ul><ul><li>Network buffer management </li></ul></ul><ul><li>Wireless Sensor Networks </li></ul><ul><ul><li>Newly emerging area </li></ul></ul><ul><ul><li>Small, inexpensive, wireless sensors for RT sensing & control </li></ul></ul>
  15. 15. Rate Monotonic, EDF (Earliest Deadline First), and Deadline Monotonic Scheduling Algorithms <ul><li>C. Liu and J. Layland, Scheduling Algorithm for Multiprogramming in a Hard Real-time Environment , Journal of the ACM, 20(1), pp. 41-61, January 1973. </li></ul><ul><li>N.C. Audsley, A. Burns, M.F. Richardson, and A. J. Wellings, Hard real-time scheduling: The deadline monotonic approach, IEEE Workshop on Real-Time Operating Systems, 1992. </li></ul><ul><li>N.C. Audsley, A. Burns, M.F. Richardson, and A. J. Wellings, Applying new scheduling theory to static priority preemptive scheduling, Software Engineering Journal, 8(5):284-292, Sept 1993. </li></ul>
  16. 16. Terminologies <ul><li>Job </li></ul><ul><ul><li>Each unit of work that is scheduled and executed by the system </li></ul></ul><ul><li>Task </li></ul><ul><ul><li>A set of related jobs </li></ul></ul><ul><ul><li>For example, a periodic task Ti consists of jobs J1, J2, J3, … coming at every period </li></ul></ul><ul><li>Release time </li></ul><ul><ul><li>Time instant at which a job becomes available for execution </li></ul></ul><ul><ul><li>It can be executed at any time at or after the release time </li></ul></ul><ul><li>Deadline </li></ul><ul><ul><li>Time instant by which a job should be finished </li></ul></ul><ul><ul><li>Relative deadline: Maximum allowable response time </li></ul></ul><ul><ul><li>Absolute deadline = release time + relative deadline </li></ul></ul>
  17. 17. <ul><li>Periodic task T i </li></ul><ul><ul><li>Period P i </li></ul></ul><ul><ul><li>Worst case execution time C i </li></ul></ul><ul><ul><li>Relative deadline D i </li></ul></ul><ul><li>Job J ik </li></ul><ul><ul><li>Absolute deadline = release time + relative deadline </li></ul></ul><ul><ul><li>Response time = finish time – release time </li></ul></ul><ul><li>Deadline miss if </li></ul><ul><ul><li>Finish time > absolute deadline </li></ul></ul><ul><ul><li>Response time of J ik > D i </li></ul></ul>
  18. 18. Optimal Scheduling Algorithm <ul><li>A scheduling algorithm S is optimal if S cannot schedule a real-time task set T, no other scheduling algorithm can schedule T </li></ul><ul><li>E.g., Rate Monotonic & EDF </li></ul>
  19. 19. Assumptions <ul><li>Single processor </li></ul><ul><li>Every task is periodic </li></ul><ul><li>Deadline = period </li></ul><ul><li>Tasks are independent </li></ul><ul><li>WCET of each task is known </li></ul><ul><li>Zero context switch time </li></ul>
  20. 20. Fixed Priority vs. Dynamic Priority Scheduling Algorithms <ul><li>Fixed priority system </li></ul><ul><ul><li>Assign the same priority to all the jobs in each task </li></ul></ul><ul><ul><li>Rate monotonic </li></ul></ul><ul><li>Dynamic priority system </li></ul><ul><ul><li>Assign different priorities to the individual jobs in each task </li></ul></ul><ul><ul><li>EDF </li></ul></ul>
  21. 21. Rate Monotonic <ul><li>Optimal fixed priority scheduling algorithm </li></ul><ul><li>Shorter period -> Higher priority </li></ul><ul><ul><li>Higher rate -> higher priority </li></ul></ul><ul><li>Utilization bound </li></ul>
  22. 22. RM Example  1  2  3 time Task Execution Time (C) End Of Period (T = Period Length)
  23. 23. Utilization Bound (UB) Test Processor Utilization for a task, i Utilization Bound for n tasks <ul><li>Results: </li></ul><ul><li>If U (=  U i ) ≤ U(n) then the set of tasks is schedulable . </li></ul><ul><li>If U(n) <  U i ≤ 1 then the test is inconclusive . </li></ul><ul><li>U < U(n) is sufficient but not necessary </li></ul>U i = C i T i U(n) = n(2 - 1) 1 n
  24. 24. Utilization Bound Test U(3) = 3(2 1/3 – 1) = 0.779 U 1 = 40 / 100 = 0.4 U 2 = 40 / 150 = 0.267 U 3 = 100 / 350 = 0.286 U total = 0.953 Result: U 1+2 = 0.667, schedulable. However, 0.779 < 0.953 < 1 Therefore, inconclusive for  3 . 350 100  3 150 40  2 100 40  1 Period (T) Execution Time (C) Task
  25. 25. EDF <ul><li>Shorter absolute deadline -> Higher priority </li></ul><ul><li>Utilization bound U b = 1 </li></ul><ul><li>U b is necessary and sufficient </li></ul>
  26. 26. Comparisons <ul><li>RMS </li></ul><ul><ul><li>RMS may not guarantee schedulability even when U < 1 </li></ul></ul><ul><ul><li>Low overhead: Priorities do not change for a fixed task set </li></ul></ul><ul><li>EDF </li></ul><ul><ul><li>EDF guarantee schedulability as long as U <= 1 </li></ul></ul><ul><ul><li>High overhead: Task priorities may change dynamically </li></ul></ul><ul><li>For more comparisons, refer to “ Rate Monotonic vs. EDF: Judgment Day ” </li></ul>
  27. 27. Assumptions <ul><li>Single processor </li></ul><ul><li>Every task is periodic </li></ul><ul><li>Relative deadline = period </li></ul><ul><li>Tasks are independent </li></ul><ul><li>WCET of each task is known </li></ul><ul><li>Zero context switch time </li></ul><ul><li>What happens if relative deadline < period ? </li></ul>
  28. 28. Deadline Monotonic Scheduling Algorithm <ul><li>Shorter relative deadline -> higher priority </li></ul><ul><li>RMS is a special case of DMS where D i = P i </li></ul><ul><li>Necessary and sufficient schedulability analysis, called response time analysis , exists </li></ul>
  29. 29. Optimal Scheduling Algorithms Relative Deadline < Period <ul><li>DMS </li></ul><ul><ul><li>Shorter relative deadline -> Higher priority </li></ul></ul><ul><ul><li>Optimal preemptive fixed priority scheduling </li></ul></ul><ul><li>EDF </li></ul><ul><ul><li>Shorter absolute deadline -> Higher priority </li></ul></ul><ul><ul><li>Optimal preemptive dynamic priority scheduling </li></ul></ul>
  30. 30. DMS Response Time Analysis Audsley et al. <ul><li>Tasks are sorted in non-increasing order of priority. (T i has the highest priority) </li></ul>for (each task T i ) { I = 0; R=0; while (I + C j > R) { R = I + C i; if (R > D i ) return Unschedulable; I = ∑ k=1, i-1  R/Pi  Ci; } } return Schedulable
  31. 31. Summary Note: EDF is optimal for aperiodic tasks too EDF Processor demand analysis EDF Utilization bound Dynamic Priority DMS Response time analysis RMS Utilization bound Response time analysis Fixed Priority D < P D i = P i