1 / 70

Real-Time Systems

Real-Time Systems. Real-time research repository. For information on real-time research groups, conferences, journals, books, products, etc., have a look at: http://cs-www.bu.edu/pub/ieee-rts/Home.html. Introduction.

cwatkins
Download Presentation

Real-Time Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Real-Time Systems

  2. Real-time research repository • For information on real-time research groups, conferences, journals, books, products, etc., have a look at: http://cs-www.bu.edu/pub/ieee-rts/Home.html

  3. Introduction • A real-time system is a system whose specification includes both a logical and a temporal correctness requirement. • Logical correctness: produce correct output. • Can be checked by various means including Hoare axiomatics and other formal methods. • Temporal correctness: produces output at the right time. • A soft real-time system is one that can tolerate some delay in delivering the result. • A hard real-time system is one that can not afford to miss a dealine.

  4. Characteristics of real-time systems • Event-driven, reactive • High cost of failure • Concurrency/multiprogramming • Stand-alone/continuous operation. • Reliability/fault tolerance requirements • PREDICTABLE BEHAVIOR

  5. Misconceptions about real-time systems • There is no science in real-time-system design. • We shall see… • Advances in supercomputing hardware will take care of real-time requirements. • The old “buy a faster processor” argument… • Real-time computing is equivalent to fast computing. • Only to ad agencies. To us, it means PREDICTABLE computing.

  6. Misconceptions about real-time systems • Real-time programming is assembly coding, … • We would like to automate (as much as possible) real-time system design, instead of relying on clever hand-crafted code. • “Real time” is performance engineering. • In real-time computing, timeliness is almost always more important than raw performance … • “Real-time problems” have all been solved in other areas of CS or operations research. • OR people typically use stochastic queuing models or one-shot scheduling models to reason about systems. • CS people are usually interested in optimizing average-case performance.

  7. Misconceptions about real-time systems • It is not meaningful to talk about guaranteeing real-time performance when things can fail. • Though things may fail, we certainly don’t want the operating system to be the weakest link! • Real-time systems function in a static environment. • Not true. We consider systems in which the operating mode may change dynamically.

  8. Are all systems real-time systems? • Question: Is a payroll processing system a real-time system? • It has a time constraint: Print the pay checks every month. • Perhaps it is a real-time system in a definitional sense, but it doesn’t pay us to view it as such. • We are interested in systems for which it is not a priori obvious how to meet timing constraints.

  9. Resources • Resources may be categorized as: • Abundant: Virtually any system design methodology can be used to realize the timing requirements of the application. • Insufficient: The application is ahead of the technology curve; no design methodology can be used to realize the timing requirements of the application. • Sufficient but scarce: It is possible to realize the timing requirements of the application, but careful resource allocation is required.

  10. Example: Interactive/multimedia application Requirements (performance) Sufficient but scarce resources Interactive Video High Quality Audio Network File Access Remote Login Insufficient resources Abundant resources 1980 1990 2000 Hardware resources in Year X

  11. A/D A/D D/A Example: Real-time application • Many real-time systems are control systems. • Example: A simple one-sensor, one-actuator control system. Computation Sensor Plant Actuator The system being controlled

  12. Simple control system • Pseudo-code for this system: set timer to interrupt periodically with period T; at each timer interrupt do do analog-to-digital conversion to get y; compute control output u; output u and do digital-to-analog conversion; od • T is called the sampling period. T is a key design choice. Typical range for T: seconds to milliseconds.

  13. Example Helicopter flight controller. Do the following in each 1/180-sec. cycle: validate sensor data and select data source; if failure, reconfigure the system Every sixth cycle do: keyboard input and mode selection; data normalization and coordinate transformation; tracking reference update control laws of the outer pitch-control loop; control laws of the outer roll-control loop; control laws of the outer yaw- and collective-control loop Every other cycle do: control laws of the inner pitch-control loop; control laws of the inner roll- and collective-control loop; Compute the control laws of the inner yaw-control loop; Output commands; Carry out built-in test; Wait until beginning of the next cycle Note: Having only harmonic rates simplifies the system. More complicated control systems have multiple sensors and actuators and must support control loops of different rates. Multi-rate control systems

  14. Hierarchical control systems

  15. Signal processing systems • Signal-processing systems transform data from one form to another. • Examples: • Digital filtering. • Video and voice compression/decompression. • Radar signal processing. • Response times range from a few milliseconds to a few seconds.

  16. Example: radar system

  17. Other real-time applications • Real-time databases. • Transactions must complete by deadlines. • Main dilemma: Transaction scheduling algorithms and real-time scheduling algorithms often have conflicting goals. • Data may be subject to absolute and relative temporal consistency requirements. • Multimedia. • Want to process audio and video frames at steady rates. • TV video rate is 30 frames/sec. HDTV is 60 frames/sec. • Telephone audio is 16 Kbits/sec. CD audio is 128 Kbits/sec. • Other requirements: Lip synchronization, low jitter, low end-to-end response times (if interactive).

  18. Hard vs. soft real-time • Task: A sequential piece of code. • Job: Instance of a task. • Jobs require resources to execute. • Example resources: CPU, network, disk, critical section. • We will simply call all hardware resources “processors”. • Release time of a job: The time instant the job becomes ready to execute. • Deadline of a job: The time instant by which the job must complete execution. • Relative deadline of a job: “Deadline - Release time”. • Response time of a job: “Completion time - Release time”.

  19. Example • Job is released at time 3. • It’s (absolute) deadline is at time 10. • It’s relative deadline is 7. • It’s response time is 6.

  20. Hard real-time systems • A hard deadline must be met. • If any hard deadline is ever missed, then the system is incorrect. • Requires a means for validating that deadlines are met. • Hard real-time system: A real-time system in which all deadlines are hard. • Examples: Nuclear power plant control, flight control.

  21. Soft real-time systems • A soft deadline may occasionally be missed. • Question: How to define “occasionally”? • Soft real-time system: A real-time system in which some deadlines are soft. • Examples: Telephone switches, multimedia applications.

  22. Defining “occasionally” • One Approach: Use probabilistic requirements. • For example, 99% of deadlines will be met. • Another Approach: Define a “usefulness” function for each job: • Note: Validation is trickier here.

  23. Firm deadlines • Firm deadline: A soft deadline such that the corresponding job’s usefulness function goes to 0 as soon as the deadline is reached (late jobs are of no use).

  24. Reference model • Each job Ji is characterized by its release time ri, absolute deadline di, relative deadline Di, and execution time ei. • Sometimes a range of release times is specified: [ri-, ri+]. This range is called release-time jitter. • Likewise, sometimes instead of ei, execution time is specified to range over [ei-, ei+]. • Note: It can be difficult to get a precise estimate of ei

  25. Periodic, sporadic aperiodic tasks • Periodic task: • We associate a period pi with each task Ti. • pi is the time between job releases. • Sporadic and aperiodic tasks: Released at arbitrary times. • Sporadic: Has a hard deadline. • Aperiodic: Has no deadline or a soft deadline.

  26. Examples • A periodic task Ti with ri = 2, pi = 5, ei = 2, Di = 5 executes like this:

  27. Some definitions for periodic task systems • The jobs of task Ti are denoted Ji,1, Ji,2, … . • ri,1 (the release time of Ji,1) is called the phase of Ti. • Synchronous System: Each task has a phase of 0. • Asynchronous System: Phases are arbitrary. • Hyperperiod: Least common multiple of {pi}. • Task utilization: ui = ei/pi. • System utilization: U = Σi=1..nui.

  28. Task dependencies • Two main kinds of dependencies: • Critical Sections. • Precedence Constraints. • For example, job Ji may be constrained to be released only after job Jk completes. • Tasks with no dependencies are called independent.

  29. Scheduling algorithms • We are generally interested in two kinds of algorithms: • A scheduler or scheduling algorithm, which generates a schedule at runtime. • A feasibility analysis algorithm, which checks if timing constraints are met. • Usually (but not always) Algorithm 1 is pretty straightforward, while Algorithm 2 is more complex.

  30. Classification of scheduling algorithms

  31. Optimality and feasibility • A schedule is feasible if all timing constraints are met. • The term “correct” is probably better — see the next slide. • A task set T is schedulable using scheduling algorithm A if A always produces a feasible schedule for T. • A scheduling algorithm is optimal if it always produces a feasible schedule when one exists (under any scheduling algorithm). • Can similarly define optimality for a class of schedulers, e.g., “an optimal static-priority scheduling algorithm.”

  32. Feasibility vs. schedulability • To most people in real-time community, the term “feasibility” is used to refer to an exact schedulability test, while the term “schedulability” is used to refer to a sufficient schedulability test. • You may find that these terms are used somewhat inconsistently in the literature.

  33. Clock driven (or static) scheduling • Model assumes • n periodic tasks T1,…,Tn. • The “rest of the world” periodic model is assumed. • Ti is specified by (fi, pi, ei, Di), where • fi is its phase, • pi is its period, • ei is its execution cost per job, and • Di is its relative deadline. • Will abbreviate as (pi,ei,Di) if fi=0, and (pi,ei) if fi=0 ∧ pi=Di. • We also have aperiodic jobs that are released at arbitrary times

  34. Schedule table • Our scheduler will schedule periodic jobs using a static schedule that is computed offline and stored in a table T. • T(tk) = Ti if Ti is to be scheduled at time tk I if no periodic task is scheduled at time tk • For most of this chapter, we assume the table is given. • Later, we consider one algorithm for producing the table. • Note: This algorithm need not be highly efficient. • We will schedule aperiodic jobs (if any are ready) in intervals not used by periodic jobs. {

  35. Static, timer-driven scheduling

  36. Example • Consider a system of four tasks, T1 = (4,1), T2 = (5,1.8), T3 = (20,1), T4 = (20,2). • Consider the following static schedule: • The first few table entries would be: (0,T1), (1,T3), (2,T2), (3.8,I), (4, T1), …

  37. Frames • Let us refine this notion of scheduling… • To keep the table small, we divide the time line into frames and make scheduling decisions only at frame boundaries. • Each job is executed as a procedure call that must fit within a frame. • Multiple jobs may be executed in a frame, but the table is only examined at frame boundaries (the number of “columns” in the table = the number of frames per hyperperiod). • In addition to making scheduling decisions, the scheduler also checks for various error conditions, like task overruns, at the beginning of each frame. • We let f denote the frame size.

  38. Frame size constraints • We want frames to be sufficiently long so that every job can execute within a frame nonpreemptively. So, • f ³ max1£i£n(ei). • To keep table small, f should divide H. Thus, for at least one task Ti, ëpi/fû - pi/f = 0. • Let F = H/f. (Note: F is an integer.) Each interval of length H is called a major cycle. Each interval of length f is called a minor cycle. • There are F minor cycles per major cycle.

  39. Frame size constraints • We want the frame size to be sufficiently small so that between the release time and deadline of every job, there is at least one frame. • A job released “inside” a frame is not noticed by the scheduler until the next frame boundary. • Moreover, if a job has a deadline “inside” frame k + 1, it essentially must complete execution by the end of frame k. • Thus, 2f - gcd(pi, f) £ Di.

  40. Example • Consider a system of four tasks, T1 = (4,1), T2 = (5,1.8), T3 = (20,1),T4 = (20,2). • By first constraint, f ³ 2. • Hyperperiod is 20, so by second constraint, possible choices for f are 2, 4, 5, 10, and 20. • Only f = 2 satisfies the third constraint. The following is a possible cyclic schedule.

  41. Job slices • What do we do if the frame size constraints cannot be met? • Example: Consider T = {(4, 1), (5, 2, 7), (20, 5)}. By first constraint, • f ³ 5, but by third constraint, f £ 4! • Solution: “Slice” the task (20, 5) into subtasks, (20, 1), (20, 3), and (20, 1). Then, f = 4 works. Here’s a schedule:

  42. Summary of design decisions • Three design decisions: • choosing a frame size, • partitioning jobs into slices, and • placing slices in frames. • In general, these decisions cannot be made independently.

  43. Pseudo code for cyclic executive

  44. Improving response times for aperiodic jobs • Intuitively, it makes sense to give hard real-time jobs higher priority than aperiodic jobs. • However, this may lengthen the response time of an aperiodic job. • Note that there is no point in completing a hard real time job early, as long as it finishes by its deadline.

  45. Slack stealing • Let the total amount of time allocated to all the slices scheduled in frame k be xk. • Definition: The slack available at the beginning of frame k is f - xk. • Change to scheduler: • If the aperiodic job queue is non-empty, let aperiodic jobs execute in each frame whenever there is nonzero slack.

  46. Example

  47. Implementing slack stealing • Use a pre-computed “initial slack” table. • Initial slack depends only on static quantities. • Use an interval timer to keep track of available slack. • Set the timer when an aperiodic job begins to run. If it goes off, must start executing periodic jobs. • Problem: Most OSs do not provide sub-millisecond granularity interval timers. • So, to use slack stealing, temporal parameters must be on the order of 100s of msecs. or secs.

  48. Scheduling sporiadic jobs • Sporadic jobs arrive at arbitrary times. • They have hard deadlines. • Implies we cannot hope to schedule every sporadic job. • When a sporadic job arrives, the scheduler performs an acceptance test to see if the job can be completed by its deadline. • We must ensure that a new sporadic job does not cause a previously-accepted sporadic job to miss its deadline. • We assume sporadic jobs are prioritized on an earliest deadline- first (EDF) basis.

  49. Acceptance test • Let s(i, k) be the initial total slack in frames i through k, where 1 £ i £ k £ F. (This quantity only depends on periodic jobs.) • Suppose we are doing an acceptance test at frame t for a newly-arrived sporadic job S with deadline d and execution cost e. • Suppose d occurs within frame l + 1, i.e., S must complete by the end of frame l. • Compute the current total slack in frames t through l using s (t,l) = s (t,l) - ådk £ d(ek - xk) • The sum is over previously-accepted sporadic jobs with equal or earlier deadlines. xk is the amount of time already spent executing Sk before frame t.

  50. Acceptance test • We’ll specify the rest of the test “algorithmically”…

More Related