CprE 458/558: Real-Time Systems

1. CprE 458/558: Real-Time Systems Fault-Tolerant Scheduling Techniques CprE 458/558: Real-Time Systems (G. Manimaran)

2. Scheduling RT Tasks with FT Requirement PB-based Fault-Tolerance • Space exclusion – primary and backup scheduled on two different processors. • Time exclusion – primary and backup should not overlap in execution. • Variants of PB-based Scheduling • PB-Exclusive – Both time and space exclusion • PB-Concurrent – Space exclusion, but concurrent execution • PB-Overlap – Space exclusion, but overlap in execution CprE 458/558: Real-Time Systems (G. Manimaran)

3. Variants of PB-scheduling: Example PB-OVERLAP Processor#0 P1 P3 Processor#1 B1 PB-CONCURRENT Processor#2 P2 B3 Processor#3 B2 PB-EXCLUSIVE CprE 458/558: Real-Time Systems (G. Manimaran)

4. Scheduling RT Tasks with FT Req. (contd.) • Each of the above three schemes has merits under certain workload and fault scenarios. • PB-Concurrent: at high fault rates, tight deadlines • PB-exclusive: at low fault rates, relaxed deadlines, high resource needs • Generalized scheme • That adapts (estimating) the “primary-backup overlap interval” based on task parameters (e.g., deadline) and fault rate has the potential to offer the best schedulability under all scenarios. TMR/NMR based FT: Space Exclusion only CprE 458/558: Real-Time Systems (G. Manimaran)

5. Schedulability-Reliability Tradeoff • Too much redundancy increases reliability, but it could potentially decrease the schedulability. • Too little redundancy decreases reliability, but increases schedulability • Also, designing and managing redundancy incurs additional cost, time, space, and power consumption • Therefore, appropriate use of redundancy is important CprE 458/558: Real-Time Systems (G. Manimaran)

6. Schedulability Enhancement Techniques in PB-based FT scheduling • Backup overloading • Two backups can be scheduled in a overlapping manner if their primaries achieve space exclusion. • Assumes, at most only one fault at a given time, i.e., before the second fault, the first fault is recovered. • Flexible overloading (static-grouping) • Partition the processors into groups • Schedule the primary and its backup in the same group • If primary is scheduled in group 1, its backup must also be scheduled in the group exploiting the backup overloading • Distance Concept • Relative position of primary and its backup in the task queue. • This has impact on the schedulability on branch-bound algos like the Spring scheduling. CprE 458/558: Real-Time Systems (G. Manimaran)

7. Backup overloading: example Space exclusive primaries Processor#0 P1 P3 P4 Backups scheduled in overlapping manner on the same processor Processor#1 P2 P4 B3 B1 Processor#2 B2 CprE 458/558: Real-Time Systems (G. Manimaran)

8. Flexible overloading- details • In flexible overloading, all “m” processors are partitioned into different groups • Rules • Every processor is a member of exactly one group • For backup overloading to take place in a group, it must have at least three processors • The size of each group is the same (except for one group, when (m/gsize) is not an integer) • Backup overloading can take place only among the processors within a group CprE 458/558: Real-Time Systems (G. Manimaran)

9. Flexible overloading: example Backup overloading within the group Processor#0 P1 Processor#1 P2 B1 Processor#2 B2 Backup overloading within the group Processor#3 P3 Processor#4 P4 B4 Processor#5 B3 CprE 458/558: Real-Time Systems (G. Manimaran)

10. Distance concept: details • Distance concept – the relative position of a primary task and its backup task in the task queue • For a given set of “N” active tasks and a given distance of “d” • For all tasks, Ti • Distance (Pri, Bki) is equal to • d for the (N – (N mod d)) tasks • N mod d for the (N mod d) tasks CprE 458/558: Real-Time Systems (G. Manimaran)

11. Distance concept: example • N= 4 • d = 3 The distance concept introduces a tradeoff between performance and fault tolerance in the myopic algorithm. Distance should be appropriately chosen. The distance should be neither too low nor too high P1 P2 P3 B1 B2 B3 P4 B4 • N= 4 • d = 2 P1 P2 B1 B2 P3 P4 B3 B4 CprE 458/558: Real-Time Systems (G. Manimaran)

12. Distance – some implications • Backup postponement • If backup task is too closer (in queue position) relative to its primary, holes get created in the schedule, resulting in lower schedulability. • Forced backtrack • If backup task is too far (in queue position) relative to its primary, missing the deadlines of backup could happen which would result in backtrack. [Read pages 108-115 in the book] CprE 458/558: Real-Time Systems (G. Manimaran)

13. Performability measures • Which is better? High schedulability or high relaibility • Overall system metric is required • Performability metrics combine schedulability and reliability into a single metric that captures the overall system goal • Goal: Determining Redundancy level to maximize the performance index (PI) CprE 458/558: Real-Time Systems (G. Manimaran)

14. Determining Redundancy Levels (contd.) • Performance index (PI) is a measure that captures both performance and reliability requirements • PI is defined as follows: For a task Ti, PIi = Vi * Ri– Pi * Fi if Ti is guaranteed -Qi if Ti is notguaranteed Where, Vi = reward if Ti completes successfully Ri = reliability of a task (1 – Fi) Fi = Failure probability Pi = penalty if Ti fails after being guaranteed Qi = if Ti has not been guaranteed The total PI = ∑i=1n PIi CprE 458/558: Real-Time Systems (G. Manimaran)

15. Determining Redundancy Levels • Goal: Given the relevant parameters for each of the “n” tasks to be scheduled on a set of “m” processors, the goal is to determine the appropriate redundancy levels for each task in order to maximize the total PI. • Let Ri be the reliability of the task with one version, the reliability of the task with “n” versions is given by 1 – (1 - Ri)n CprE 458/558: Real-Time Systems (G. Manimaran)

16. Determining Redundancy Levels: example Given task-set PI is maximum at u = 2. Therefore, a redundancy level of 2 is optimal Calculations U: redundancy level CprE 458/558: Real-Time Systems (G. Manimaran)

17. Fault-tolerance -- conclusions • Dependability concepts • Fault-tolerant design techniques • Fault-tolerant scheduling • Primary-backup scheduling • Schedulability enhancement techniques • Redundancy level determination • Imprecise computations • Imprecise computational model • (m,k)-firm model CprE 458/558: Real-Time Systems (G. Manimaran)