Designing User Interfaces Spring 1999

1
Examples of periodic tasks

• Audio sampling in hardware
• Audio sample processing
• Video capture and processing
• Feedback control (sensing and processing)
• Navigation
• Temperature and speed monitoring

2
Scheduling periodic tasks

• Preemptive scheduling is an effective approach
  for scheduling real-time DSP systems
• modularity simplifies the overall design
• Application can be viewed as a collection of
  independent tasks or jobs
• complexity is reduced as the functionality
  becomes encapsulated into a set of well defined
  tasks

3
Scheduling periodic tasks

• Systems designed using preemptive scheduling are
  also more maintainable
• issue of changes to one task in the system
  affecting other jobs in the system is removed
• New functionality can easily be added by adding a
  new task

4
Scheduling periodic tasks

• Preemptive scheduling approach also makes the
  system more efficient
• preemptive scheduling is more efficient at
  utilizing time slots that may not be fully
  utilized
• Scheduling algorithms
• rate monotonic scheduling
• deadline monotonic scheduling

5
cost of handling event C 4
Periodic Arrivals with Fixed Cost of Processing
4
4
4
---- 10 ----
periodic arrivals. period T 10
System Utilization C/T .40
System will be able to meet all deadlines. It can
finish processing arrivals before the next
arrival occurs.
6
Can a second periodic event be accommodated?
4
4
4
---- 10 ----
1. periodic arrival, period T 10 and C4 2.
periodic arrival, T10 and C3 ??
7
Can a second periodic event be accommodated?
4
4
4
---- 10 ----
1. periodic arrival, period T 10 and C4 2.
periodic arrival, T10 and C3 ??
System Utilization C/T .70
8
How about 2nd periodic event with T6 and C3?
4
4
4
---- 10 ----
1. periodic arrival, period T 10 and C4 2.
periodic arrival, T6 and C3 ??
9
How about 2nd periodic event with T6 and C3?
4
4
4
---- 10 ----
1. periodic arrival, period T 10 and C4 2.
periodic arrival, T6 and C3 ??
System Utilization C/T .90
10
Event 2
Event 1
If we process Event 1 before Event 2 then, 2nd
event processing will not complete before the
next comparable event occurs Cant Meet Deadline!
11
Try Event 2 before Event 1- We still cannot
complete task 1 before the next task 2 event
occurs at t6 unless...
Event 2
Event 1
12
Try Event 2 before Event 1- We still cannot
complete task 1 before the next task 2 event
occurs at t6 unlesswe Interrupt task 1
Event 2
Event 1
13
Try Event 2 before Event 1- We still cannot
complete task 1 before the next task 2 event
occurs at t6 unlesswe Interrupt task 1
Event 2
Giving event 2 priority means that we can meet
our deadline IF we preempt the processing of
event 1 when event 2 occurs
Event 1
14
Rate Monotonic Analysis
15
Rate Monotonic Analysis

• Assume a set of n periodic tasks
• period Ti
• worst case execution time Ci
• Rate-monotonic priority assignment
• task with a shorter period (higher rate) assigned
  a fixed higher priority

16
Rate Monotonic Analysis

• Rate Monotonic scheduling addresses how to
  determine whether a group of tasks, whose
  individual CPU utilization is known, will meet
  their deadlines
• assumes a priority preemption scheduling
  algorithm
• assumes independent tasks (no communication or
  synchronization)

17
Rate Monotonic Analysis

• restriction of no communication or
  synchronization may appear to be unrealistic, but
  there are techniques for dealing with this
• Each task is a periodic task which has a period
  T, which is the frequency with which it executes

18
Rate Monotonic Analysis

• An execution time C, which is the CPU time
  required during the period
• A utilization U, which is the ratio C/T
• A task is schedulable if all its deadlines are
  met (i.e., the task completes its execution
  before its period elapses.)
• A group of tasks is considered to be schedulable
  if each task can meet its deadlines

19
Rate Monotonic Analysis

• RMA is a mathematical solution to the scheduling
  problem for periodic tasks with known cost
• assumption is that the total utilization must
  always be less than or equal to 100
• Any more and you are exceeding the capacity of
  the CPU
• Are you asking for more computing power than you
  have? IF so, forget it!

20
Rate Monotonic Analysis

• For a set of independent periodic tasks, the rate
  monotonic algorithm assigns each task a fixed
  priority based on its period, such that the
  shorter the period of a task, the higher the
  priority

21
Rate Monotonic Analysis

• For three tasks T1, T2, and T3 with periods of 5,
  15 and 40 msec respectively the highest priority
  is given to the task, T1, as it has the shortest
  period, the medium priority to task T2, and the
  lowest priority to task T3
• priority assignment is independent of the
  applications priority i.e. how important
  meeting this deadline is to the functioning of
  the system or user concerns

22
Rate Monotonic Analysis

• A mathematical solution to the scheduling problem
  for Periodic Tasks with known Cost
• Tasks will have
• Cost (Time to complete a task)
• Period (Time between events)
• Utilization ( Cost/Period)
• Assumption
• Total Utilization must always be lt 100

23
3 levels of analysis using RMA

• Utilization bound test
• Completion time test
• Response time test

24
Utilization bound test

• If this simple rule is followed, then all tasks
  are guaranteed to meet their requirements if the
  following holds true

25
Utilization bound test

• In this rule, the bound is 1.0 for harmonic task
  sets
• A task set is said to be harmonic if the periods
  of all its tasks are either integral multiples or
  sub-multiples of one another
• On the average, for random Cs and Ts, this
  number will be about 0.88.

26
Utilization bound test

• Theory is a worst case approximation
• For a randomly chosen group of tasks, it has
  been shown that the likely upper bound is 88
• Harmonic periods can give even higher upper
  bounds
• The algorithm is stable in conditions where there
  is a transient overload

27
Utilization bound test

• In this case, there is a subset of the total
  number of tasks, namely those with the highest
  priorities that will still meet their deadlines

28
Example of UB test

• Task t1 C120 T1 100 U1 .2
• Task t2 C230 T2 150 U2 .2
• Task t3 C360 T3 200 U3 .3
• The total utilization for this task set is .2
  .2 .3 .7. Since this is less than the 0.779
  utilization bound for this task set, all
  deadlines will be met.

29
ExampleCan these 4 tasks be scheduled?
Task Ci Ti Ui 1 3 10 .30 2 3 12 .25 3 4 16 .25 4 7
20 .35

• Can the system run and meet all hard deadlines?

30
ExampleCan these 4 tasks be scheduled?
Task Ci Ti Ui 1 3 10 .30 2 3 12 .25 3 4 16 .25 4 7
20 .35

• Can the system run and meet all hard deadlines?
• NO! The Total Utilization 115

31
Example
Task Ci Ti Ui 1 6 20 .30 2 4 16 .25 3 3 12 .25

• Can these tasks always meet their deadlines?
• Total Utilization 80
• It MAY be possible - Rate Monotonic Scheduling
  applies!

32
Rate Monotonic Theorem

• For PERIODIC Tasks
• Most frequent task gets highest priority
• THEOREM (Simple Version)
• IF the utilization of all tasks is less than or
  equal to 69, then all tasks will ALWAYS meet
  their deadlines

33
Are These Tasks Schedulable?
Task Ci Ti Ui 1 2 20 .10 2 4 16 .25 3 3 12 .25 4 1
20 .05
34
Are These Tasks Schedulable?
Task Ci Ti Ui 1 2 20 .10 2 4 16 .25 3 3 12 .25 4 1
20 .05
Yes. Total CPU Utilization is 65 lt 69
35
Are These Tasks Schedulable?
Task Ci Ti Ui 1 2 20 .10 2 4 16 .25 3 3 12 .25 4 3
20 .15
36
Are These Tasks Schedulable?
Task Ci Ti Ui 1 2 20 .10 2 4 16 .25 3 3 12 .25 4 1
20 .05
Total CPU Utilization is 65 ???
37
Exercise

• Using Rate Monotonic Scheduling, determine if the
  following task set is schedulable

38
More on Rate Monotonic Analysis
39
Rate Monotonic Theorem

• For PERIODIC Tasks
• Most frequent task gets highest priority
• RMS THEOREM (Mathematical Version)
• n periodic tasks scheduled by the rate monotonic
  algorithm will always meet their deadlines if the
  total utilization of all tasks is less than
• n (21/n - 1)
• this converges to ln2 69 for large n

40
Tasks Utilization n n(2(1/n) -1) 1 1 2 0.82842
712 3 0.77976315 4 0.75682846 5 0.74349177 6 0
.73477229 7 0.7286266 8 0.72406186 9 0.72053765
10 0.71773463 11 0.71545198 12 0.71355713
In a Nutshell The more tasks you try and
schedule, the more slack time you must be willing
to tolerate to mathematically guarantee
schedulability
converges toward 69
41
Priority Inversion
Taskh
Taskmed
Tasklow
Priority inversion
Normal execution
Execution in critical section
42
Unbounded Priority Inversion
Taskh
Uncontrolled priority inversion
Taskmed
Taskmed
Tasklow
Priority inversion
Normal execution
Execution in critical section
43
Priority Inheritance Protocol
Taskh
Taskmed
Tasklow
Priority inversion
Execution in critical section at higher priority
Normal execution
Execution in critical section
44
What Happened on Mars ?
45
What happened on Mars ?

• Mars pathfinder flawless in early days of
  mission
• unconventional landing with airbags
• deployment of Sojourner rover
• gathering and transmitting data back to earth
• A few days into the mission the Pathfinder began
  experiencing total system resets, each including
  losses of data

46
What happened on Mars ?

• Press reported these as software glitches
• VxWorks RTOS provides preemptive priority
  scheduling of tasks
• tasks executed as threads
• priorities assigned reflecting relative urgency
  of the tasks

47
What happened on Mars ?
48
What happened on Mars ?

• Combination worked fine most of the time
• Possible for interrupt to occur that caused the
  long running medium priority task to be scheduled
  during the short interval while the high priority
  task was blocked waiting on the semaphore that
  the low priority task had.

49
What happened on Mars ?

• Watchdog timer would go off, notice data bus task
  not in use for some time, conclude that something
  bad went wrong, and initiate a total system reset
• Classic case of priority inversion

50
How was this debugged ?

• VxWorks can run in trace mode, recording
  interesting events.
• JPL engineers spent hours in lab trying to
  reproduce the problem on the ground.
• When finally reproduced, the trace data indicated
  the priority inversion problem

51
How was this problem corrected?

• Mutex object accepts boolean parameter indicating
  whether priority inheritance should be used
• Initialized with parameter off
• if on, the low-pri thread would have inherited
  the pri of the high-pri thread
• medium pri thread would never have been executed

52
How was this problem corrected?

• VxWorks has a C language interpreter that allows
  C commands to be executed on the fly
• JPL engineers left this in the software
• Changed global variables by uploading a short
  program to the spacecraft
• No more system resets occurred after
  re-programming!

53
Analysis and Lessons

• Diagnosing this problem as a black box would have
  been impossible
• trace data was required
• Leaving debugging facilities in the system saved
  the day
• Time critical situations requires additional
  correctness measures even at the expense of some
  performance

54
Human nature, Deadline Pressures

• One or two system resets had occurred on the
  ground prior to launch
• Never reproducable or explainable
• it was probably caused by a hardware glitch
• Engineer focus caused part of the problem
• extremely focused on ensuring quality and
  flawless operation of landing software
• the occasional glitch was dismissed

55
Importance of good Theory/Algorithms

• Some of the heros were people from CMU who
  published a paper years ago on the priority
  inversion problem
• An Approach to Real-Time Synchronization IEEE
  Transaction on Computers, Vol39, pp1175-1185,
  September 1990

56
End of session