A Time-Driven Scheduling Model for Real-Time Operating Systems
Jense, Locke, and Tokuda


Real-Time - completion of a process or a set of processes has a value
to the system which can be expressed as a function of time.

Examine SPT, Deadine, SST, FIFO, and fixed priority.


-----

1.1 The Scheduling Problem

Scheduling is a branch of OR - produce a sequence of jobs which must
utilize a shared resource such that some metric is optimized.
- maximize process flow or minimize lateness

Most solutions are NP-complete

The choice of a metric is crucial to the generation of a processing
sequence which will meet the goals of the system for which the
schedule is being prepared.

In contrast to OR, most scheduling tasks are dynamic.

1.2 Real-Time Systems

The most important difference between real-time operating systems and
other computer systems is that in a real-time system, the completion
of a process has a value to the system which varies with time.

Hard vs. Soft Real-Time

1.3 Scheduling in Existing Real-Time Systems

- Simple, minimal overhead, minimal function.  Virtual storage, file
  systems limited or absent.  I/O minimal.  Simple scheduling.

- Simple support for real-time clock.

- Missing support for explicitly managing user-defined deadlines.  Not 
  part of the API.

- Sometimes partitioned into important and unimportant classes.

- Transient overloads are a problem.

1.4 Evaluating a Real-Time Scheduler

Time-value functions.

Is this a valid metric?

-----

2 Time-Driven Scheduling Model

Each process pi has a request time Ri, and estimated computation time
Ci, and a value function Vi(t), where t is a time for which the value
is to be determined.

Value function comes from 
- process implementer
- system architect

deadline = critical time

Can define both hard and soft real-time environments.

Question: can an iteration have value wrt next iteration?  In other
words, even if the current value isn't used now, can it be used later.

-----

3 Simulation Results

vi(t) = k1 + k2t - k3t^2 + k4e^-k5t

The simulator first uses a statistical model of a "typical" real-time
processor load to generate a set of processes, including both periodic 
and aperiodic processes.

The statistical model defines a real-time workload based on experience 
with several actual real-time systems with which this author is
familiar.

Question: do you believe him?

3.1.1 A Set of Classical Algorithms

1. SPT (=SJN)
2. Deadline (=EDF)
3. Slack (=LLF)
4. FIFO (=Earliest Release Time)
5. Random
6. RandPRTY (Priority = highest obtainable)

Observations
- Value Density (V/C) will produce value at every point in time at
  least as high as any other schedule
- Given a set of processes whose deadlines can all be met, EDF works.
- Most value functions have their highest value immediately prior to
  their critical time.

Implications
- Without overload, EDF is fine
- With overload, Value Density produces a high value, but might miss
  some deadlines which could otherwise have been met.

New Algorithms
- BEValue1 - greedy on value density
  - misses deadlines when all could be met
- BEValue2 - in overload, gives priority to processes whose deadlines
  can't be met.  After computing the probability of overload, choose
  processes with low value density as candidates for being removed from
  an overloaded deadline schedule until a deadline schedule is produced
  which has an acceptably low probability of producing an overload.

Starts with a deadline ordered sequence of available processes.
Sequenctially check for probability of overload
Whenever overload seems likely, remove previously viewed lowest value
density process.

BEValue2 matches BEValue1 in cases without overload, and beats it in
situations of low overload.

40% probability threshold used