In online scheduling, the decision when to run a task is done at runtime. The
scheduler has more work to perform at runtime and might find a proper schedule
that could be found with offline scheduling. In addition, it is also more difficult to
take all task constraints into account.
However, online schedulers are much more flexible to match requirements of
performance—or reliability—or energy-smart functioning. Under reliability “flag”,
we can consider an ability of the system to react on unforeseen or exceptional
situations. Dynamic allocation of new tasks for testing purposes introduced by just
standard user or us here tasks both at runtime is also only possible using online
scheduling. In this first example, we would like to use static scheduling, as this
better shows our approach.
Consider now case (a) of Sect. 7.2 where T c and all task completion times are
known. Assume there exists a deadline for a maximum value of T c .
In other words, in the time interval 0 … T c , all hardware units (processors) of the
set U must be diagnosed where T c has a given upper bound. We now divide the set
of units U = {u i , …, u n } into two subsets U 1 and U 2 taking the relation between the
user task finishing time T compl and T c into account.
In a first step, we add every unit u i in U either U 1 (u i 2 U 1 ) if the completion time
t i of the task running on unit u i satisfies t i + T ad
T c , or we add u i to U 2 (u i 2 U 2 )
if t i + T ad > T c . Obviously, it is impossible to test any unit in U 2 asynchronously,
so this step seems logical.
But even if U 2 = {}, it is not possible to reliably guarantee testing of all units in
U 1 asynchronously. In fact, when a user task has finished on one unit while a testing
process is running on another processor, the scheduler will assign a new task to the
just released processor according to the constraint that only one diagnostic procedure should run concurrently. This case is triggered if one task finishes while
another is diagnosed: t j − t i < T ad .
Even though both tasks finish before T c − T ad , there is not enough time left to
test both in asynchronous mode. Therefore, the separation of units to two subset U 1
and U 2 is necessary but not sufficient.
We present below the procedure T1 that chooses a subset of units R for thef
synchronous SDD in accordance with T c and the task completion times. The subset
R & U1 formed by procedure T1 is tested synchronously as well as all units from
subset U 2 . R [ U 2 is, therefore, tested synchronously.
To find a solution to the mode problem for every unit of the system, the user
should consider two extreme positions. The first concerns with the minimization of
the diagnostic time boundary, i.e., the length of the time span in which all units
should be diagnosed and the second deals with the minimization of the performance
overheads, i.e., the minimization of the number of required task load and unload
operations and having only one checking process running at the time. We propose
here a natural approach to this problem.
78
7 Testing, Checking, and Hardware Syndrome
scheduler has more work to perform at runtime and might find a proper schedule
that could be found with offline scheduling. In addition, it is also more difficult to
take all task constraints into account.
However, online schedulers are much more flexible to match requirements of
performance—or reliability—or energy-smart functioning. Under reliability “flag”,
we can consider an ability of the system to react on unforeseen or exceptional
situations. Dynamic allocation of new tasks for testing purposes introduced by just
standard user or us here tasks both at runtime is also only possible using online
scheduling. In this first example, we would like to use static scheduling, as this
better shows our approach.
Consider now case (a) of Sect. 7.2 where T c and all task completion times are
known. Assume there exists a deadline for a maximum value of T c .
In other words, in the time interval 0 … T c , all hardware units (processors) of the
set U must be diagnosed where T c has a given upper bound. We now divide the set
of units U = {u i , …, u n } into two subsets U 1 and U 2 taking the relation between the
user task finishing time T compl and T c into account.
In a first step, we add every unit u i in U either U 1 (u i 2 U 1 ) if the completion time
t i of the task running on unit u i satisfies t i + T ad
T c , or we add u i to U 2 (u i 2 U 2 )
if t i + T ad > T c . Obviously, it is impossible to test any unit in U 2 asynchronously,
so this step seems logical.
But even if U 2 = {}, it is not possible to reliably guarantee testing of all units in
U 1 asynchronously. In fact, when a user task has finished on one unit while a testing
process is running on another processor, the scheduler will assign a new task to the
just released processor according to the constraint that only one diagnostic procedure should run concurrently. This case is triggered if one task finishes while
another is diagnosed: t j − t i < T ad .
Even though both tasks finish before T c − T ad , there is not enough time left to
test both in asynchronous mode. Therefore, the separation of units to two subset U 1
and U 2 is necessary but not sufficient.
We present below the procedure T1 that chooses a subset of units R for thef
synchronous SDD in accordance with T c and the task completion times. The subset
R & U1 formed by procedure T1 is tested synchronously as well as all units from
subset U 2 . R [ U 2 is, therefore, tested synchronously.
To find a solution to the mode problem for every unit of the system, the user
should consider two extreme positions. The first concerns with the minimization of
the diagnostic time boundary, i.e., the length of the time span in which all units
should be diagnosed and the second deals with the minimization of the performance
overheads, i.e., the minimization of the number of required task load and unload
operations and having only one checking process running at the time. We propose
here a natural approach to this problem.
78
7 Testing, Checking, and Hardware Syndrome