For a good summary, visit: Real-Time Scheduling Module 3.2 For a good summary, visit: http://www.cs.uah.edu/~weisskop/osnotes_html/M8.html

Characteristics of Real-Time Operating Systems A key characteristic is the variability or jitter. i.e., level of its consistency concerning the amount of time it takes to accept and complete an application's task A hard real-time operating system has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category. A real-time OS that can usually or generally meet a deadline is a soft real-time OS, but if can meet a deadline deterministically it is a hard real-time OS.

Characteristics of Real-Time Operating Systems Responsiveness/Predictability How long, after acknowledgment, it takes the operating system to service the interrupt Includes amount of time to begin execution of the interrupt Includes the amount of time to perform the interrupt The effect of interrupt nesting will introduce more delays Keep interrupt handling and context switching to minimal. In some RTOS, disable interrupts altogether.

Characteristics of Real-Time Operating Systems User Control User control in non-RTOS has no or limited control (say scheduling function and priority) User control in RTOS may include: User specifies priority User task priority can be higher than priority of system tasks Specify paging or not for a process What processes must always reside in main memory Disks algorithms to use Rights of processes

Characteristics of Real-Time Operating Systems Reliability Rebooting is unacceptable way of handling failures. Degradation of performance may have catastrophic consequences (financial loss or loss of life.) When there is a failure, a core dump is not acceptable. RTOS attempt either to correct the problem or minimize its effects while continuing to run Most critical, high priority tasks must always be met. Stability issue.

Features of Real-Time Operating Systems Fast context switch Small size with minimal functionality Ability to respond to external interrupts quickly Multitasking with IPC primitives such as semaphores, signals, and events Preemptive scheduling base on priority Minimization of intervals during which interrupts are disabled Delay tasks for fixed amount of time

RT Scheduler The heart of RTOS is the short term scheduler. What is important is meeting the deadline of hard RT tasks and the completion of as many soft RT tasks as possible. Issues like fairness, minimizing turnaround time, etc are not that important. Military aircraft requires time constraints in the range of 10 to 100 microseconds.

RT Scheduling RTOS schedulers must be able to guarantee that a process will complete by its required deadline. Failure leads to catastrophe; late execution is no better than no execution. One criteria is that the execution time of all processes (including operating system processes) be predictable. When a new task arrives, the system can decide whether or not it can be guaranteed. Scheduling algorithms can use static or dynamic techniques. When combined with traditional scheduling notions of preemption and priority, several classes of algorithms result

Scheduling of a Real-Time Process

Scheduling of a Real-Time Process

Scheduling of a Real-Time Process

Scheduling of a Real-Time Process

Real-Time Scheduling Approaches Static table-driven can be developed when tasks are periodic, and have a known duration. Execution schedule can be planned off-line. Of course such systems have little or no ability to respond to unexpected events. Predictable but inflexible (change to any task means redoing the schedule.) EDF is an example Static priority-driven preemptive assigns static priorities off-line and then applies them in some form of preemptive priority scheduler. Traditional priority-driven scheduler is used Priority is based on time constraints Rate monotonic scheduling (RMS) is an example. Dynamic planning-based tries to build achievable schedules on the fly, i.e. feasibility analysis. When a new task arrives, the system tries to fit it into the existing schedule. If this can be done, and all deadlines can still be met, the task will be accepted. Dynamic best effort No feasibility analysis. Admit every process Commercially available, it is easy to implement System assigns priority to the task when it arrives Does not guarantee meeting deadlines

Deadline Scheduling Real-time applications are not concerned with speed but with completing or starting tasks Scheduling tasks with the earliest deadline minimized the fraction of tasks that miss their deadlines

Deadline Scheduling Information used Ready time Periodic times are examples Starting deadline Completion deadline Usually either starting or completion deadline Processing time Either supplied or exponentially estimated Resource requirements Priority Hard vs. soft RT task Subtask scheduler Some tasks have a mandatory and optional subtasks. Only mandatory subtask possesses a hard deadline.

Two Tasks A runs every 20ms for 10ms, and B runs every 50ms for 25ms. The system can do a scheduling decision every 10ms.

Execution time of each task is 20ms.

Rate Monotonic Scheduling Assigns priorities to tasks on the basis of their periods Highest-priority task is the one with the shortest period

Periodic Task Timing Diagram

Features of RMS Widely adopted for use in industrial applications. Utilization as high as 90% is often achieved. Adjustment of priority is easily achieved by making the task periods shorter. This is done whenever task starts missing its deadline.