research-article

Public Access

Optimal Checkpointing Strategy for Real-time Systems with Both Logical and Timing Correctness

Authors:

Lin Zhang,

Zifan Wang,

Fanxin KongAuthors Info & Claims

ACM Transactions on Embedded Computing Systems, Volume 22, Issue 4

Article No.: 66, Pages 1 - 21

https://doi.org/10.1145/3603172

Published: 24 July 2023 Publication History

PDF eReader

Abstract

Real-time systems are susceptible to adversarial factors such as faults and attacks, leading to severe consequences. This paper presents an optimal checkpoint scheme to bolster fault resilience in real-time systems, addressing both logical consistency and timing correctness. First, we partition message-passing processes into a directed acyclic graph (DAG) based on their dependencies, ensuring checkpoint logical consistency. Then, we identify the DAG’s critical path, representing the longest sequential path, and analyze the optimal checkpoint strategy along this path to minimize overall execution time, including checkpointing overhead. Upon fault detection, the system rolls back to the nearest valid checkpoints for recovery. Our algorithm derives the optimal checkpoint count and intervals, and we evaluate its performance through extensive simulations and a case study. Results show a 99.97% and 67.86% reduction in execution time compared to checkpoint-free systems in simulations and the case study, respectively. Moreover, our proposed strategy outperforms prior work and baseline methods, increasing deadline achievement rates by 31.41% and 2.92% for small-scale tasks and 78.53% and 4.15% for large-scale tasks.

1 Introduction

As real-time systems such as automobiles become more complex and open architectures, they are vulnerable to many adversarial factors such as faults and attacks [2, 12, 40, 46]. With these adversaries, the controller may make dangerous decisions and cause serious consequences such as vehicle crashes and loss of human lives [1, 8, 21, 39, 44]. Resilience to such adversarial factors is essential to the safety of such systems [5, 9, 16].

In this paper, we study the problem of tolerating transient faults for a controller executing in computational nodes. In general, there are two popular research threads for fault resilience: redundancy and checkpointing. One thread relies on redundant components (e.g., standby processors [13, 19, 31, 33] or task replica [20, 24, 32, 42]), where if some components are faulty, other components can still process forward to finish the job. The other thread occasionally checkpoints system states, and the system rolls back to a consistent state (checkpointed in history) when detecting faults [14, 15, 17, 28]. This work aligns with the second thread and studies checkpointing protocols for real-time parallel processes.

Existing checkpointing works can be divided into two groups. One group focuses on checkpointing computing tasks in general-purpose (non-real-time) systems. The goal is to guarantee the logical consistency of checkpoints (value correctness), which represents the cause-effect relation defined by messages sent and received among tasks [14, 17, 22]. The other targets real-time systems and carries out checkpointing under timing constraints (deadlines) [29, 34, 37, 47, 48]. There are three main protocols setting checkpoints: uncoordinated checkpointing, coordinated checkpointing, and communication-induced checkpointing (CIC). Uncoordinated checkpointing enables tasks to set checkpoints when convenient for a better schedule[18, 38]. Coordinated checkpointing forces all the tasks to synchronize checkpoints and make recoveries simpler [7, 23]. Communication-induced checkpointing, also known as message induced checkpointing, enables tasks to establish separate checkpoints while also creating compulsory additional checkpoints as needed [3, 6, 41]. This approach promotes independence in detecting errors during execution. However, these works are incapable of tackling checkpointing real-time parallel processes, where both logical and timing correctness need to be guaranteed.

To fill this gap, we propose a new three-step checkpointing protocol that considers both types of correctness. In the first step, we partition the real-time parallel processes into a directed acyclic graph (DAG) of tasks, where each edge represents the message communicated between tasks. We then place compulsive checkpoints to ensure logical correctness for each task. The second step involves identifying the critical path, which is the longest execution path in the DAG. Finally, we ensure timing correctness by minimizing the overall execution time, which includes both task execution time and checkpointing overhead. To accomplish this, we propose effective and efficient algorithms for each step. Finally, we evaluate our checkpointing protocol with extensive simulations and a case study of a real system using CRIU [10]. Note that the checkpoints in this work only consider cyber states and are not related to physical states [43, 44, 45, 46].

The rest of this paper is organized as follows. Section 2 describes the overview of the optimal checkpointing strategy, gives the system model and threat model, and lists most notations. Sections 3–5 present task partition, finding the critical path, and placing optional checkpoints for timing correctness, respectively. Section 6 evaluates our method, Section 8 concludes the paper, and Section 7 discusses the limitation of this paper.

2 Preliminaries and Design Overview

In this section, we present the problem statement, an overview of the proposed checkpointing strategy, system and fault models, and notations used in this paper.

2.1 Problem Statement

We consider a multiprocessor real-time system whose processes perform repetitive tasks, where each process aims at a specific function such as sensor data collection and data processing. During process execution, each process may send messages to other processes, forming the processes’ dependencies. We study a checkpointing problem in such a system. When a fault is detected, the system rollbacks to the nearest valid checkpoint, which saves states of the processes and avoids redoing all valuable work during recovery. The objective is to determine an optimal checkpointing strategy, which achieves (i) logical consistency of checkpoints considering process dependencies and (ii) the shortest execution time considering checkpointing overhead and recovery time.

2.2 Overview of the Checkpointing Strategy

We obtain the optimal checkpoint strategy in three steps, as shown in Figure 1: (i) process partition, (ii) critical path extraction, and (iii) optional checkpoint placement. The following briefly describes these steps, and we will present their detailed design in Sections 3–5.

Fig. 1.

•

Process partition. Execution of processes is dependent on message passing, and to ensure successful fault tolerance and recovery, checkpoints must be placed considering these dependencies. This involves partitioning dependent processes into a DAG graph and placing compulsive checkpoints that meet the requirements of logical dependency, while also avoiding the domino effect.

•

Critical path extraction. In the DAG, most tasks can be executed in parallel with the multiprocessor. However, tasks in a dependent path must be executed in sequence. This step involves identifying the critical path, which is the longest dependent path in the DAG. The critical path determines the performance of the checkpointing and recovery process. While tasks in non-critical paths can also set up checkpoints, their execution time is typically less than that of tasks on the critical path. Therefore, in the proposed model, only the critical path should be considered.

•

Optional checkpoint placement. If too few checkpoints are placed, a significant amount of progress will be lost on the critical path following a fault. Conversely, if too many checkpoints are placed, the checkpointing overhead will dominate. This step involves solving optimization problems to determine the optimal number and intervals of checkpoints, striking a balance between progress loss and checkpointing overhead.

2.3 Models and Preliminaries

Symbols and notations used in this paper are listed in Table 1.

Table 1.

Symbol	Description
\(P_i\)	\(i\)-th process in the system
\(T_i\)	\(i\)-th task in the critical path
\(S_{ij}\)	\(j\)-th segment in the Task \(i\)
\(s\)	the recovery overhead from the initial state
\(r\)	the recovery overhead from checkpoints
\(t_c\)	the overhead of checkpointing
\(q_i\)	the invalid rate of optional checkpoints in the Task \(i\)
\(p_i\)	the valid rate of optional checkpoints in the Task \(i\)
\(n\)	the number of tasks in the critical path
\(m_i\)	the number of optional checkpoints in the Task \(i\)
\(m_{i*}\)	the optimal number of optional checkpoints in the Task \(i\)
\(\lambda _i\)	the failure rate of the Task \(i\)
\(w_{ij}\)	the total execution time before \(S_{ij}\) in the Task \(i\)
\(h_{ij}\)	the total execution time of \(S_{ij}\) in the Task \(i\)
\(W_{ij}\)	the expectation of \(w_{ij}\)
\(d_{ij}\)	the completion time of \(S_{ij}\) before a fault
\(D_{ij}\)	the expectation of \(d_{ij}\)
\(F_{ij}\)	the probability that the fault occurs in \(S_{ij}\)
\(I_i\)	the fault-free computation time (excluding \(t_c\)) of Task \(i\)
\(\tau _{ij}\)	the fault-free execution time (including \(t_c\)) of Segment \(S_{ij}\)

Table 1. Symbols and Notations Used in This Paper

2.3.1 System Model.

We consider a multiprocessor real-time system that has multiple processes, where the messages exchanged between these processes form the process dependencies. We partition the processes into tasks (\(t_{BC}\) represents the \(C\)-th task on the \(B\)-th process) according to the dependencies. By partitioning the processes, we obtain a directed acyclic graph (DAG) where tasks are represented as nodes and process dependencies are represented as edges. We place compulsory checkpoints (see Section 3) on this DAG to guarantee logical consistency and prevent the domino effect. Then, the critical path (see Section 4) is identified as the longest dependent path, and the tasks in this path are renamed to \(T_D\) (i.e., the \(D\)-th task in the critical path). Finally, we place optional checkpoints (see Section 5) according to our strategy to achieve a shorter execution time. The optional checkpoints split each task into some segments (\(S_{EF}\) is the \(F\)-th segment in \(T_E\)). Figure 2 is an example that illustrates the relationship among processes, tasks, and segments.

Fig. 2.

We assume that the system stores all compulsory checkpoints in the current critical path and only stores the latest optimal checkpoint because of limited resources.

2.3.2 Fault Model.

Fault occurrence is generally regarded as random and independent, so we assume that the arrival of faults is a Poisson process with a failure rate of \(\lambda\). However, our proposed method is not limited to a specific distribution and can be applied to various other distributions. The reason why our paper adopts the Poisson process is for easy presentation and its wide use in many existing works such as [11, 25, 26, 35, 36]. For generality, we set a different failure rate for each task on the critical path, and \(\lambda _{i}\) denotes the failure rate of the \(i\)-th task. Then, the time interval \(F\) between two faults is subject to an exponential distribution with a constant failure rate \(\lambda _i\), and its probability density function (PDF) is \(f_F(t)=\lambda _i e^{-\lambda _i t}, t\ge 0, \lambda \ge 0\).

When a fault arrives, there is a \(p_i\) chance for task \(T_i\) rollback to the latest checkpoint. However, there is also a \(q_i=1-p_i\) chance for a task to roll back to the latest compulsory checkpoint because of the optional checkpoint availability. If a task rollbacks to a checkpoint, there is a checkpoint recovery overhead \(r\). However, if a task rollbacks to the initial state of the critical path, there is a restart recovery overhead \(s\).

2.3.3 Notations in the Critical Path.

The critical path is illustrated in Figure 3. For the \(i\)-th task \(T_i\) on this path, the original fault-free computation time is \(I_i\). We place optional checkpoints to divide the task into \(m_i\) task segments, i.e., \(S_{i0},S_{i1},\dots ,S_{im_i}\). \(\tau _{ij}\) denotes the fault-free execution time of \(S_{ij}\) that includes task computation time and checkpoint overhead \(t_c\).

Fig. 3.

The probability that the fault occurs in Segment \(S_{ij}\) is

\begin{equation} \begin{split}F_{ij}(\tau _{ij})&=P(T\le \tau _{ij})=1-P(T\ge \tau _{ij}) =1-e^{-\lambda \tau _{ij}},\quad for\quad 1\le i \lt n, 0\le j\le m_i \end{split} \end{equation}

(1)

Besides, \(d_{ij}\) denotes the time interval from the beginning of \(S_{ij}\) to the time the fault occurs in \(S_{ij}\), that is, the task performed before the fault during \(S_{ij}\). The PDF of \(d_{ij}\) is

\begin{equation*} f_{d_{ij}}(t)=\frac{f_F(t)}{F_{ij}(\tau _{ij})}=\frac{\lambda _i e^{-\lambda _i t}}{1-e^{-\lambda _i \tau _{ij}}},\quad for\quad 0\le t\le \tau _{ij} \end{equation*}

The expectation of \(d_{ij}\) is

\begin{equation} D_{ij}=\int _{0}^{\tau _{ij}}tf_{d_{ij}}(t)dt=\frac{1}{\lambda _i}-\frac{\tau _{ij}e^{-\lambda _i \tau _{ij}}}{1-e^{-\lambda _i \tau _{ij}}} \end{equation}

(2)

Considering rollbacks, \(w_{ij}\) denotes the execution time from the beginning of Task \(i\) to the first beginning of Segment \(S_{ij}\). \(W_{ij}\) is the expectation of \(w_{ij}\). \(h_{ij}\) denotes the execution time of the segment \(S_{ij}\).

To make the derivation brief, we also define some abbreviations as follows:

\begin{align} a_i&=\frac{1}{\lambda _i}+s \end{align}

(3a)

\begin{align} b_i&=\frac{1}{\lambda _i}+p_i r+q_i s \end{align}

(3b)

\begin{align} c_i&=\frac{1}{\lambda _i}+r \end{align}

(3c)

\begin{align} u_{ij}&=e^{\lambda _i \tau _{ij}}-1 \end{align}

(3d)

\begin{align} v_{ij}&=q_i e^{\lambda _i \tau _{ij}}+p_i \end{align}

(3e)

3 Process Partition with Logical Consistency

Processes in real-time systems perform some recurrent tasks, between which the sending and receiving messages form the dependencies. When a transient fault occurs, the system needs to be recovered back to normal. We back up some checkpoints so that the systems can re-execute from these states to tolerate the fault.

In this step, our checkpoints should meet the logical consistency requirements (Definition 1) to ensure that the recovery process runs smoothly [14]. For example, the states in Figure 4(a) are inconsistent because \(P_1\) (process 1) indicates the \(m_0\) reception while \(P_0\) (process 0) does not reflect the sending of \(m_0\); the states in Figure 4(b) satisfy Definition 1 because \(P_2\) (process 2) indicates the \(m_1\) reception and \(P_1\) reflects the sending of \(m_1\), although \(P_1\) does not reflect the \(m_0\) reception particularly. We can conclude that all states satisfy Definition 1 if all processes checkpoint after sending a message.

Fig. 4.

Definition 1 (Logical Consistency).

Logical consistency is defined as an attribute of the system state that ensures that sender processes reflect the sending of messages once the corresponding receiver processes indicate the message reception.

Another notable phenomenon is the domino effect, which occurs when an invalid message reception leads to an invalid message sending. This can result in a series of rollbacks, ultimately returning the system to its initial state. The domino effect leads to a significant loss of useful work and makes real-time performance uncontrollable. For instance, Figure 5 shows a rollback scenario, in which a fault occurs on the process \(P_0\). The fault forces \(P_0\) to roll back to its latest checkpoint, and message \(m_0\) becomes invalid, which forces process \(P_1\) to roll back to its latest checkpoint as well. In turn, the message \(m_1\) becomes invalid, and this backward propagation stops until the initial state. If all processes checkpoint before receiving a message, the domino effect can be avoided.

Fig. 5.

We partition processes into tasks based on their message sending and receiving behavior. We add edges between neighboring tasks within the same process and from a task sending a message to a task receiving the message, creating a partition graph. The weight of each vertex in this graph represents the fault-free execution time of the corresponding task, while the edges represent the dependencies between tasks. We also account for checkpoint overhead in the weight of each vertex. When a process sends a message, a compulsory checkpoint is placed immediately following it to reflect the message sent and ensure logical consistency. When a process receives a message, a compulsory checkpoint is placed to backup all work before the message, avoiding the domino effect. This can typically be accomplished by piggybacking a command to set up a compulsory checkpoint with the actual processing command after receiving a message. Now, we get a task graph in which all states satisfy Definition 1. This graph is a DAG because no task can send a message back to a previous time to form a circle. For instance, Figure 6(a) shows a basic scenario with 4 processes - \(P_0\), \(P_1\), \(P_2\) and \(P_3\). After partitioning, we obtain a DAG graph, i.e., Figure 6(b). In this graph, each vertex is a task partitioning from processes. The weights of vertices in the partition graph are equal to the fault-free execution time of the corresponding task plus the overheads of the compulsory checkpoints placed on it.

Fig. 6.

Remark 3.1.

Compulsory checkpoints satisfy logical consistency and avoid the domino effect.

When a failure occurs, and the system rolls back to the compulsory checkpoints, the sender processes show that they have sent the messages, while the corresponding receiver processes indicate that they have not yet received them. This demonstrates that the messages have been sent but not yet received [14], which is in line with the definition of logical consistency. On the other hand, because the sender processes set compulsory checkpoints after sending the messages, the system will not invalidate the messages, thereby preventing further rollbacks, i.e., the domino effect.

4 Critical Path Extraction

In a system with multiple processors, most tasks can be executed in parallel. However, tasks connected by edges in the DAG must be performed in sequence because of the dependencies. Identifying the critical path (Definition 2) in the DAG gives us the maximum length of tasks that must be executed in sequence to ensure logical consistency and avoid the domino effect. This critical path determines the total execution time of these processes. It’s important to note that the critical path is extracted after inserting the compulsory checkpoints.

Definition 2 (Critical Path).

In a DAG of tasks, the critical path is a path in which the total sum of the weight of the vertices is no less than that of any other path.

Algorithm 1 shows an algorithm to find a critical path based on the topological sort and dynamic programming. First, we topologically sort the DAG and get an ordered vertex set \(V\) with a complexity of \(O(|V|)\). Then, we use dynamic programming to calculate the maximum total weight ending with vertex \(v\), i.e., \(tw(v)\). A transition function is defined as

\begin{equation} tw(v)=max\lbrace tw(u)+w(v)\rbrace \end{equation}

(4)

where \((u,v)\) is an edge in \(E\) and \(w(v)\) is the weight of the vertex \(v\). The computation is performed in the topological order of \(v\). Given that the maximum number of computing \(tw(\cdot)\) is equal to the number of edges, the algorithmic complexity is \(O(|E|)\). Finally, we select the maximum value of \(tw(v)\) as the highest total weight of \(l\) and reconstruct the critical path \(P\) using each optimal choice \(v.choice\) we record.

The critical path is the worst-case for the following analysis. Figure 7(a) shows a critical path partitioned from processes, in which we already placed compulsory checkpoints (shown in Figure 7(b)) for logical consistency. However, it’s challenging to meet real-time requirements using only compulsory checkpoints with long intervals. When a fault occurs, the system needs to roll back to a consistent state containing only compulsory checkpoints. This rollback can violate timing correctness (Definition 3), making it difficult to meet real-time requirements.

Fig. 7.

Definition 3 (Timing Correctness).

Timing Correctness means that all tasks in each process catch up with the deadline of this process in a real-time system.

5 Checkpoint Placement for Timing Correctness

In this section, we focus on placing optional checkpoints on each task of the critical path to minimize the total execution time, denoted as \(W_{n}\). If no optional checkpoints are placed, a long rollback may occur, leading to a waste of useful work. However, placing too many checkpoints results in significant checkpoint overhead. To find a balance, we formulate an optimization problem for each task to determine the appropriate number and length of checkpoint segments.

As shown in Figure 7(b), the first task \(T_0\) in the critical path starts from the initial state, while other tasks \(T_1, \dots , T_n-1\) start from a compulsory checkpoint. Thus, we apply the proposed optimization method to the two conditions separately.

5.1 Optimization for the First Task

The first task, \(T_0\), is exceptional. If the task rollbacks to an optional checkpoint, the rollback overhead is \(r\). However, if the task rollbacks to a checkpoint unsuccessfully, the task restarts with a higher overhead \(s\), because there is no checkpoint at the beginning of the task \(T_0\). In Segment \(S_{00}\), the task is restarted if a fault is detected. Hence, the total execution time is updated because of it:

\begin{equation} w_{01}= {\left\lbrace \begin{array}{ll} \tau _{00} & P=1-F_{00}(\tau _{00})\\ d_{00}+s+w_{01} & P=F_{00}(\tau _{00}) \end{array}\right.} \end{equation}

(5)

From Equations (1), (2), and (5), we can derive the expectation of \(w_{01}\):

\begin{equation} \begin{split}W_{01}&=\tau _{00}+\frac{F_{00}(\tau _{00})}{1-F_{00}(\tau _{00})}(D_{00}+s)=\left(\frac{1}{\lambda _1}+s\right)(e^{\lambda _0 \tau _{00}}-1)=a_0u_{00} \end{split} \end{equation}

(6)

In other segments, \(S_{0j}\), there is no fault with \(1-F_{0j}(\tau _{0j})\) chance. The task rollbacks to the latest checkpoint with probability \(p_0\) or restarts with probability \(q_0\) if a fault is detected. Hence, the total execution time is

\begin{equation} w_{0(j+1)}=w_{0j}+h_{0j} \end{equation}

(7)

where

\begin{equation*} h_{0j}= {\left\lbrace \begin{array}{ll} \tau _{0j} & P=1-F_{0j}(\tau _{0j})\\ d_{0j}+r+h_{0j} & P=F_{0j}(\tau _{0j})p_0\\ d_{0j}+s+w_{0(j+1)} & P=F_{0j}(\tau _{0j})q_0 \end{array}\right.} \end{equation*}

From Equations (1), (2), and (7), we can get the expectation of \(w_{0(j+1)}\):

\begin{equation} \begin{split}W_{0(j+1)} &= \frac{1-p_0F_{0j}(\tau _{0j})}{1-F_{0j}(\tau _{0j})}W_{0j}+\tau _{0j}+\frac{F_{0j}(\tau _{0j})}{1-F_{0j}(\tau _{0j})}(D_{0j}+p_0r+q_0s)\\ &=(qe^{\lambda _1 \tau _{1j}}+p_1)W_{1j}+(e^{\lambda _1\tau _{1j}}-1)\left(\frac{1}{\lambda }+p_1r+q_1s\right)=v_{0j}W_{0j}+u_{0j}b_0 \end{split} \end{equation}

(8)

Using Equations (6) and (8) recursively, we derive the expectation of the total execution time of the first task:

\begin{equation} \begin{split}W_0&=W_{0(m_0+1)}\\ &=a_0u_{00}\prod _{i=1}^{m_0}v_{0i}+b_0u_{01}\prod _{i=2}^{m_0}v_{0i}+b_0u_{02}\prod _{i=3}^{m_0}v_{0i}+ \cdots +b_0u_{0(m_0-1)}v_{0m_0}+bu_{0m_0} \end{split} \end{equation}

(9)

The optimization problem is expressed as:

\begin{equation} \begin{split}\underset{m_0,\tau _{0j}}{\arg \min } & \quad W_0\\ \mathrm{ s.t. } & \quad \sum _{j=0}^{m_0}\tau _{0j}=I_1+(m_0+1)t_c \end{split} \end{equation}

(10)

Because there are two variables in the problem, we first assume that \(m_0\) is given and try to find the relations between \(\tau _{0j}\). Then, we try to compute the optimal \(m_0\).

We introduce a Lagrange multiplier \(\theta\) and get the Lagrange function.

\begin{equation} \begin{split}\mathcal {L}(\tau _{0j},\theta)=W_0(\tau _{0j})-\theta g(\tau _{0j})\text{, where }g(\tau _{0j})= I_0+(m_0+1)t_c - \sum _{j=0}^{m_0}\tau _{0j} \end{split} \end{equation}

(11)

The optimal solution satisfies

\begin{equation} \nabla \mathcal {L}(\tau _{0j},\theta)=0 \end{equation}

(12)

From Equation (12), we get the equation:

\begin{equation} \frac{\partial W_0}{\partial \tau _{00}}=\frac{\partial W_0}{\partial \tau _{01}}= \cdots =\frac{\partial W_0}{\partial \tau _{0m_0}} \end{equation}

(13)

From Equation (13), we can obtain the relations between the fault-free execution time of segments \(\tau _{00},\tau _{01},\dots ,\tau _{0m_0}\):

\begin{equation} \begin{aligned}\tau _{01}&=\tau _{02}=\dots =\tau _{0m_0}=\tau _{0*}\\ \tau _{00}&=\tau _{0*} + \tau _d \end{aligned} \end{equation}

(14)

where \(\tau _d=\frac{1}{\lambda _0}ln(\frac{1+\lambda _0r}{1+\lambda _0s})\). Hence, \(W_0\) becomes

\begin{equation} \begin{aligned}W_0&=a_0u_{00}v_{0*}^m+b_0u_{0*} \sum _{i=0}^{m_0-1}v_{0*}^i=\left(a_0u_{00}+b_0q_0^{-1}\right)v_{0*}^m-b_0q_0^{-1} \end{aligned} \end{equation}

(15)

where

\begin{equation*} \begin{aligned}\tau _{0*} &= \frac{I_0-\tau _d}{m_0+1}+t_c\\ u_{0*}&=e^{\lambda _0 \tau _{0*}}-1\\ v_{0*}&=q_0 e^{\lambda _0 \tau _{0*}}+p_0 \end{aligned} \end{equation*}

We get the optimal number of checkpoints in the first task \(m_0*\) by solving \(\frac{\partial W_0}{\partial m_0}=0\), and choose the best value of two nearest integers as the optimal solution. According to the optimal \(m_0*\) and Equation (14), we can determine where to checkpoint in Task 0.

5.2 Optimization for Other Tasks

For tasks after \(T_0\), the task rolls back to a compulsory or optional checkpoint with overhead \(r\), if a fault is detected. There is no restart overhead because there is a compulsory checkpoint at the beginning of the task \(T_i\). Therefore, the total execution time for \(S_{ij}\) is

\begin{equation} w_{i(j+1)}= {\left\lbrace \begin{array}{ll}h_{i0} & j=0\\ w_{ij}+h_{ij} & 1\le j \le m_i \end{array}\right.} \end{equation}

(16)

where

\begin{equation} h_{ij}= {\left\lbrace \begin{array}{ll}\tau _{ij} & P=1-F_{ij}(\tau _{ij})\\ d_{ij}+r+h_{ij} & P=F_{ij}(\tau _{ij})p_i\\ d_{ij}+r+w_{i(j+1)} & P=F_{ij}(\tau _{ij})q_i \end{array}\right.} \end{equation}

(17)

From Equations (1), (2), (16), and (17), we can derive the expectation of \(w_{i(j+1)}\):

\begin{equation} \begin{split}W_{i(j+1)} &= \frac{1-p_iF_{ij}(\tau _{ij})}{1-F_{ij}(\tau _{ij})}W_{ij}+\tau _{ij}+ \frac{F_{ij}(\tau _{ij})}{1-F_{ij}(\tau _{ij})}(D_{ij}+r)\\ &=(q_ie^{\lambda \tau _{ij}}+p_i)W_{ij}+(e^{\lambda \tau _{ij}}-1)\left(\frac{1}{\lambda _i}+r\right)=v_{ij}W_{ij}+u_{ij}c_i \end{split} \end{equation}

(18)

We add Equation (18) recursively, and we can derive the expectation of the total execution time of the task \(T_{i}\):

\begin{equation} \begin{split}W_i&=W_{i(m_i+1)}\\ &=c_iu_{i0}\prod _{j=1}^{m_i}v_{ij}+c_iu_{i1}\prod _{j=2}^{m_i}v_{ij}+c_iu_{i2}\prod _{j=3}^{m_i}v_{ij}+ \cdots +c_iu_{i(m_i-1)}v_{im_i}+c_iu_{im_i} \end{split} \end{equation}

(19)

The optimization problem is expressed as:

\begin{equation} \begin{split}\underset{m_i,\tau _{ij}}{\arg \min } & \quad W_i\\ \mathrm{ s.t. } & \quad \sum _{j=0}^{m_i}\tau _{ij}=I_i+(m_i+1)t_c \end{split} \end{equation}

(20)

The Lagrange function is

\begin{equation} \begin{split}\mathcal {L}(\tau _{ij},\theta)&=W_i(\tau _{ij})-\theta g(\tau _{ij})\text{, where }g(\tau _{ij})= I_i+(m_i+1)t_c - \sum _{j=0}^{m_i}\tau _{ij} \end{split} \end{equation}

(21)

The optimal solution satisfies

\begin{equation} \nabla \mathcal {L}(\tau _{ij},\theta)=0 \end{equation}

(22)

From Equation (22), we can get the following equation:

\begin{equation} \frac{\partial W_i}{\partial \tau _{i0}}=\frac{\partial W_i}{\partial \tau _{i1}}= \cdots =\frac{\partial W_i}{\partial \tau _{im_i}} \end{equation}

(23)

From Equation (23), we can get the relations between the fault-free execution time of Segments \(\tau _{i0},\tau _{i1},\dots ,\tau _{im_i}\):

\begin{equation} \tau _{i0}=\tau _{i1}=\dots =\tau _{im_i}=\tau _{i*} \end{equation}

(24)

Hence, \(W_i\) becomes

\begin{equation} \begin{aligned}W_i&=c_iu_{i*} \sum _{j=0}^{m_i}v_{i*}^j=-c_iq_i^{-1}\left(1-v_{i*}^{m_i+1}\right) \end{aligned} \end{equation}

(25)

where

\begin{equation*} \begin{aligned}\tau _{i*} &= \frac{I_i}{m_i+1}+t_c\\ u_{i*}&=e^{\lambda _i \tau _{i*}}-1\\ v_{i*}&=q_i e^{\lambda _i \tau _{i*}}+p_i \end{aligned} \end{equation*}

By solving \(\frac{\partial W_i}{\partial m_i}=0\), and choosing the best value of two nearest integers, we get the optimal \(m_{i*}\). Then, we can checkpoint at equidistance in Task \(i\) according to Equation (24).

Remark 5.1.

Optional checkpoint placement in the critical path, which is computed by solving the above optimization problem, achieves the shortest total execution time.

The optimization objectives for both the first and other tasks are the total execution time including overheads. Thus, the number of optional checkpoints and their intervals that are computed by solving the optimization problem lead to the shortest total execution time.

6 Evaluation

In this section, we evaluate the effectiveness of our proposed optional checkpointing strategy through extensive simulations and a case study. For the simulations, we randomly generate a system with dependent processes and evaluate our approach based on four aspects: prevention of the domino effect, optimization of optional checkpoint intervals, optimization of checkpoint numbers, and performance under different scales. In the case study, we demonstrate how our approach works in a real system.

6.1 Simulation

6.1.1 Simulation Setting.

The generated processes with dependencies are shown in Figure 8(a). According to Section 3, we partition these processes into a DAG of tasks, shown in Figure 8(b). The fault-free execution times of each task are marked beside the vertices. According to Section 4, We extracted the critical path from the DAG and marked it in orange. The critical path consists of four tasks, each with time lengths of 400, 300, 200, and 200. The overall deadline for completing all tasks is 3300, which is equivalent to three times the fault-free computation time of the tasks on the critical path.

Fig. 8.

Considering the simplicity of setting up the experiment and the directness of illustrating the advantage of our model, the parameters mentioned in the Section 2.3.3 are as follows. Some parameters are based on real-world experiences, such as the checkpointing overhead for placement and recovery, while others can be set arbitrarily and do not affect the fairness among different strategies. We choose the same fault rate for each task, i.e., \(\lambda _0=\lambda _1=\lambda _2=\lambda _3=0.01\), which means one fault is expected to occur every 100 units of time. The checkpoint placement overhead \(t_c\) is 4. When a fault arrives, the system rollback to an optional checkpoint with a probability of \(p=0.8\), and to a compulsory checkpoint (the initial state for \(J_1\)) with a probability of \(q=0.2\). The recovery overhead from a checkpoint is \(r=12\), and the recovery overhead from the initial state is \(s=20\).

To simulate the time interval between two faults, we use the equation in [27] for the exponential distribution:

\begin{equation*} nextInterval = \frac{-lnU}{\lambda } \end{equation*}

where \(U\) is a random value between 0 and 1.

According to Section 5, we can obtain the optimal number of checkpoints in each task of the critical path, which are 13, 9, 6, 6 checkpoints. According to Equations (14) and (24), we can also get corresponding intervals between every two checkpoints.

6.1.2 Simulation Result.

We perform four simulations to evaluate our strategy of setting checkpoints. The first simulation aims to determine whether our model can prevent the domino effect and thus reduce the execution time. The second and the third simulation aims to prove our model optimizes the interval of checkpoints and the number of checkpoints, respectively. The fourth simulation shows that our model performs well in a wide range of scales.

Simulation 1: Domino Effect Prevention. The processes with dependencies in Figure 9(a) suffer from the domino effect if we set checkpoints randomly, for example, the blue checkpoints. Instead, setting checkpoints based on our strategy prevents the system from rolling back to the initial state whenever faults happen. Thus, the system’s execution time will be shortened. We simulate the critical path 100,000 times with four strategies: (a) no checkpoints, place no checkpoints in the system; (b) only compulsory checkpoints, place no optional checkpoints; (c) only optional checkpoints, place no compulsory checkpoints; and (d) optimal checkpoints, place both compulsory and optional checkpoints (the proposed strategy). Among them, (a) and (c) are affected by the domino effect.

Fig. 9.

The results shown in Table 2 indicate that the domino effect leads to a large execution time. There are two observations: (i) the average execution time of strategy (a) is about 750 times longer than that of strategy (b), (ii) the average execution time of (b) is about 4 times longer than that of strategy (d). The reason behind the noteworthy difference is from the compulsory checkpoints, which make the system free from the domino effect. For (a), the system rollback to the initial state when a fault occurs, but for (b), the system only rollback to the nearest compulsory checkpoints. Thus, a large amount of useful work can be saved. Although the system can rollback to an optional checkpoint when a fault occurs for strategy (c), but there is also a possibility \(q\) that the optional checkpoint is not valid. Under this condition, the system has to rollback to the initial state, which leads to a larger execution time in strategy (c). The domino effect is also avoided in strategy (d). This analysis highlights the importance of compulsory checkpoints that prevent the domino effect, reduce the execution time, and increase the finishing process percentage on time.

Table 2.

Strategy	Avg Exec	Min Exec	Max Exec	%Deadline
NC	7581500.85	8378.91	45725624.63	0.00
CO	10067.38	1116.00	70697.98	6.22
OO	10340.65	1287.56	111719.27	20.67
OP	2616.95	1264.34	10702.18	81.82

Table 2. The Result of Simulation 1 - Domino Effect Prevention

Avg Exec: Average Execution Time, Min Exec: Minimum Execution Time, Max Exec: Maximum Execution Time, %Deadline: the Percentage of Simulations that Meet the Deadline. Strategies: NC: (a) No Checkpoints, CO: (b) Only compulsory Checkpoints, OO: (c) Only Optional Checkpoints, OP: (d) Optimal Checkpoints (the Proposed Strategy).

Simulation 2: Performance Regarding Checkpoint Interval. The second simulation compares our checkpoint placement strategy with four other strategies on the critical path with respect to checkpoint intervals. We consider five types of different checkpoint placement strategies, the same in the number of checkpoints but different in the checkpoint interval. They are: (a) optimal placement strategy obtained from Section 5; (b) two-state strategy [36]: a strong prior work that has two stages of setting checkpoints, and the first stage delays the checkpoints as much as possible avoiding checkpointing overheads. (c) uniformI (I stands for intervals): place checkpoints based on uniform distribution; (d) Gauss distribution placement strategy: place checkpoints based on Gauss distribution with \(I/2\) as the mean and \(I/4\) as the standard deviation; (e) narrowing placement strategy: gradually narrow the interval between two checkpoints; and (f) widening placement strategy: gradually widen the interval between two checkpoints. The placement strategy (d) is based on the algorithm: the \(i+1\)-th checkpoint in a task is placed at the first third of the interval between the \(i\)-th checkpoint and the end. The placement strategy (e) is the reverse process of strategy (d). We simulate the critical path process 100,000 times and list the result in Table 3.

Table 3.

Strategy	Avg Exec	Min Exec	Max Exec	%Deadline
Optimal	2616.12	1252.00	11995.20	81.88
TwoState	2761.80	1398.50	8682.60	80.96
UniformI	2744.79	\(1236.00\)	11732.31	77.80
Gauss	2732.77	1254.44	10993.74	78.19
Narrowing	2946.51	1250.99	14325.78	70.97
Widening	2941.82	1265.67	13142.09	71.02

Table 3. The Result of Simulation 2 - Performance Regarding Different Checkpoint Intervals

Strategies: (a) Optimal, (b) TwoState, (c)UniformI, (d) Gauss, (e) Narrowing, (f) Widening.

The result shows that our model optimizes the interval between checkpoints. We notice that our optimal strategy (a) has the shortest average execution time and the highest percentage of finishing processes on time. Strategy (b), (c), and (d) have shorter average execution times than strategy (d) and (e), but still longer than strategy (a). The prior work (b) yields a competitive rate of meeting deadlines with the proposed strategy but it behaves worse than the proposed strategy and baseline strategies (c) and (d) in terms of average and minimum execution time. This is because of its concentrated distribution of execution time. This strategy reduces the maximum execution time and increases the percentage of meeting deadlines, however, it also increases the minimum execution time and thus increases the average execution time. Strategy (c) places the checkpoints uniformly on each task, making it worse but close to our model’s result. The performance of strategy (d) depends on the value of the mean and standard deviation, and in this case, it has a better performance than strategy (c). Note, the maximum execution time of strategy (d) being less than other strategies is due to randomness, i.e., fewer faults happen during some runs in strategy (d). Our model cannot guarantee to perform the best every time, but it promises a better average result when running time accumulates.

Simulation 3: Performance Regarding Checkpoint Number. The third simulation compares our checkpoint placement strategy with three other strategies on the critical path with respect to checkpoint numbers. We consider four types of checkpoint placement strategies in this simulation: (a) optimal placement strategy obtained from Section 5; (b) MelhemInt: The algorithm of determining the number of checkpoints that is used in many prior work [4, 30]; (c) uniformM (M stands for the number of checkpoints \(m\)), placing the same number of checkpoints in each task, and the total number of checkpoints is close to that in (a); (d) light-weight placement strategy, place fewer checkpoints than (a), but the number of checkpoints in each task is proportional to the computation time of each task; and (e) heavy-weight placement strategy, place more checkpoints than (a), but the number of checkpoints in each task is proportional to the computation time of each task. All strategies share the same pattern of determining intervals, i.e., our model. We simulate the critical path process 100,000 times, and the result is listed in Table 4.

Table 4.

Strategy	CP No.	Avg Exec	Min Exec	Max Exec	%DDL
Optimal	13,9,6,6	2617.39	1267.73	11791.90	81.90
MelhemInt	\(4, 3, 3, 3\)	3636.14	1167.65	35886.96	51.79
UniformM	9,9,9,9	2653.03	1293.53	11901.07	80.67
Light-wt	10,7,5,5	2628.57	1236.94	10821.43	81.47
Heavy-wt	16,11,7,7	2637.40	1314.42	11609.88	81.27

Table 4. The Result of Simulation 3 - Performance Regarding Different Checkpoint Numbers

CP No.: Number of Checkpoints in The Critical Path Tasks. %DDL: The Percentage of Simulations That Meet the Deadline. Strategies: (a) Optimal, (b) MelhemInt, (c) UniformM, (d) Light-weight, (e) Heavy-weight.

The result shows that our model optimizes the number of checkpoints. The other three strategies slightly change the number of checkpoints for each task, and none of them performs better than our model. Our strategy reduces the average execution time and increases the percentage of processes completed on time. The prior work (b) and the lightweight placement baseline place inadequate checkpoints, wasting useful work and leading to longer execution time. On the other hand, the heavy-weight placement strategy places too many checkpoints, and their overheads contribute more execution time. Only our proposed strategy meets the trade-off between useful work waste and checkpointing overhead. Note that the light-weight placement strategy’s minimum execution time is smaller than our model because it places fewer checkpoints. The scale, i.e., the size of the DAG and the length of the critical path, is small in this simulation, which leads to the slight improvement from other strategies to the proposed model. Improvement will be increased in simulation 4.

Simulation 4: Performance Regarding Scalability. The fourth simulation shows the scalability of our checkpoint placement strategy. First, we gradually add the number of processes and their lengths. The execution time for each task is chosen randomly from 50 to 650 units of time. Second, we randomly generate dependencies between tasks: for each task, there is 0.4 chance that no message is sent out, 0.5 chance that 1 message is sent to another process, and 0.1 chance that 2 messages are sent to other processes. By selecting and adjusting the number and length of processes, the scale of the DAG can be controlled to an expected range. Then according to Section 3, we partition these processes into a DAG of tasks. Finally, according to Section 4, we extract the critical path of the DAG. The set of parameters, i.e., \(\lambda , t_c, p, q, r, s\) is the same as the above value. And the deadline for finishing all tasks is also three times the fault-free computation time of tasks on the critical path. The scale and critical path details are shown in Tables 5 and 6, respectively.

Table 5.

Proc No.	Avg Proc Len	Msg No.	Critical Path Len
3	40	91	48
4	80	206	93
5	120	444	142
6	160	680	191
7	200	978	238
8	240	1319	292

Table 5. The Scales of Simulation 4 - Performance Regarding Scalability

Proc No.: Number of Processes, Avg Proc Len: Average Process length, Msg No.: Number of Messages, Critical Path Len: Length of Critical Path.

Table 6.

Path Len	Opt CP No.	FF Exec	Task Avg	Task S.D.
48	522	16945	\(353.02\)	\(166.84\)
93	1002	32656	\(351.14\)	\(173.85\)
142	1541	50097	\(352.79\)	\(174.42\)
191	2095	68033	\(356.19\)	\(171.24\)
238	2610	84779	\(356.21\)	\(174.76\)
292	3183	103359	\(353.97\)	\(175.49\)

Table 6. The Detail of Critical Path of Simulation 4 - Performance Regarding Scalability

Path Len: Number of Tasks in the Critical Path. Opt CP No.: The Optimal Number of Checkpoints in the Critical Path, FF Exec: Fault-free Execution Time, Task Avg: Average Execution Time of All the Tasks, Task S.D.: Standard Deviation of All the Tasks.

The optimal checkpoint numbers are calculated by the proposed model. We simulate the critical path process 100,000 times and list the result in Table 7. We also simulate the two best baselines in the previous simulation for better comparison: the TwoState strategy in simulation 2 and the light-weight strategy in simulation 3. Besides, we simulate the strategy of using compulsory checkpoints only.

Table 7.

P Len	Strat	Avg Exec	Min Exec	Max Exec	%DDL
48	Opt	\(46658.36\)	\(29043.16\)	\(79035.80\)	\(79.52\)
	TwoState	\(54044.17\)	\(37780.91\)	\(79985.81\)	\(48.11\)
	L-wt	\(47159.98\)	\(29690.36\)	\(78796.84\)	\(76.60\)
	CO	\(549115.45\)	\(183697.60\)	\(1433248.68\)	\(0.00\)
93	Opt	\(90962.30\)	\(63480.37\)	\(131047.60\)	\(82.37\)
	TwoState	\(107625.32\)	\(82879.86\)	\(147974.87\)	\(26.12\)
	L-wt	\(92036.61\)	\(67042.33\)	\(132859.30\)	\(78.44\)
	CO	\(1174630.43\)	\(525642.00\)	\(2287054.97\)	\(0.00\)
142	Opt	\(142221.44\)	\(107544.19\)	\(189782.72\)	\(83.71\)
	TwoState	\(162806.04\)	\(129464.32\)	\(208093.57\)	\(14.80\)
	L-wt	\(143888.79\)	\(106922.95\)	\(191786.89\)	\(79.07\)
	CO	\(1893677.80\)	\(1048011.40\)	\(3309548.29\)	\(0.00\)
191	Opt	\(190392.98\)	\(148406.07\)	\(247362.28\)	\(88.54\)
	TwoState	\(231139.34\)	\(189596.35\)	\(285603.39\)	\(2.45\)
	L-wt	\(192664.35\)	\(148323.16\)	\(247667.30\)	\(84.14\)
	CO	\(2628444.25\)	\(1516961.52\)	\(4276293.98\)	\(0.00\)
238	Opt	\(238168.00\)	\(192514.41\)	\(309228.85\)	\(89.70\)
	TwoState	\(285246.53\)	\(237750.67\)	\(342616.35\)	\(13.18\)
	L-wt	\(240934.17\)	\(192965.68\)	\(304839.08\)	\(85.08\)
	CO	\(3223960.78\)	\(2017579.28\)	\(5132395.45\)	\(0.00\)
292	Opt	\(289887.27\)	\(240952.28\)	\(358688.84\)	\(92.30\)
	TwoState	\(324411.12\)	\(274018.52\)	\(387484.72\)	\(13.77\)
	L-wt	\(293287.77\)	\(239438.80\)	\(356610.61\)	\(88.15\)
	CO	\(3872775.91\)	\(2507589.88\)	\(5993822.13\)	\(0.00\)

Table 7. The Result of Simulation 4 - Performance Regarding Scalability

P Len: Length of Critical Path, Strategies: Opt: The Proposed Strategy, TwoState: Prior Work proposed in [36], L-wt: Light-weight Placement Strategy, CO: Only Compulsory Checkpoints.

The result shows that our model stays strong in different aspects of scale and proves again that it performs better than other strategies. We notice that as the critical path becomes longer, the average execution time of all four strategies increases. The strategy to place only compulsory checkpoints cost the system over 10 times longer than the other three strategies to complete the tasks. Moreover, the percentage of meeting the deadline remains 0 on all scales. This unacceptable result is due to repeated work without proper checkpointing. The TwoState strategy that had a competitive performance as our approach in simulation 2 has unacceptable performance on execution time and deadline meeting rate at all scales. As the scale grows, its performance degrades significantly because its motivation to delay the first checkpoint leads to a long rollback for the first fault. Also, in contrast to the more concentrated distribution of execution times, the TwoState strategy has an overall longer execution time in average, minimum, and maximum, and the difference increases as the scale grows. The lightweight placing strategy has a competitive result, but still fails to surpass our model in terms of both average execution time and percentage of meeting deadline. The reason is that given the relatively low fault rate, the overhead of setting checkpoints makes up the gap between performances. Another noteworthy observation shown in the result is that the uniform distribution strategy’s percentage of meeting the deadline goes low as the scale becomes large, while our model and lightweight strategy have an opposite trend. This is because (i) our model performs better as the scale grows and random data become stable, (ii) the light-weight strategy’s performance is relative to our model as it has a fixed ratio of fewer checkpoints, and (iii) the absolute more execution time of uniform strategy becomes large as the scale expands so the percentage of meeting the deadline drops.

6.2 Case Study

In this section, we apply and test our model on an environmental monitoring system that monitors, records, and analyses the campus environment, including atmospheric composition, tap water ingredients, environmental noise, and 12 more aspects of data. The program has three processes: (a) data processing process: iterate a database, filter, and retrieve the target records; (b) logic processing process: analyze and sort the records retrieved by process (a); and (c) message sending process: send the sorted records to an external program and waiting for responses. Since there are trillions of records, all three processes should be partitioned into several tasks according to different record ID ranges to reduce the cost of faults. The inputs of the latter tasks depend on the results of the previous tasks. We choose a pair of boundaries of this program and plot the system in a DAG, Figure 10(a). The number besides tasks is their estimated execution time: every task of the process (a) needs 2 seconds to run; every task of the process (b) needs 1 second to execute; every task of the process (c) consumes 3 seconds. The critical path is colored orange. We run the program 100 times and plot the results in Figure 10(b).

Fig. 10.

We use CRIU [10], a library for process state management, to set and restore checkpoints. We build a separate C++ program to generate faults, save, and restore from checkpoints. The number of checkpoints and the interval between checkpoints is obtained from our proposed strategy, according to Section 5. The expected interval between every two faults is consistent with [27]. The fault rate \(\lambda =0.001\). Other parameters, i.e., \(t_c, p, q, r, s\) are the same as the simulation settings, and the deadline is also three times the fault-free critical path execution time.

The result in Figure 10(b) shows that if we do not set any checkpoints on the program, the average execution time (i.e., 52.37s) is about four times longer than the expected 13.32s execution time if no faults occur. However, if we set checkpoints based on the model described before, we can decrease the average execution time to 16.83s because the checkpoints prevent the program from falling back to the initial state and repeatedly doing the same tasks. Thus, our model of setting checkpoints can reduce the average execution time in real-world programs if faults happen.

7 Discussion

Compulsory and optional checkpoints do not impact the critical path. On the one hand, inserting compulsory checkpoints happens before extracting the critical path, which means we have considered the impact of compulsory checkpoints. On the other hand, the proposed strategy determines how to place optional checkpoints to achieve the minimum expected execution time on the critical path. However, the optional checkpoints are inserted coordinately in all processes; so they globally increase the execution time and equally affect all paths.

The proposed approach does not assume a deterministic number of faults. This work considers a probabilistic fault model that we cannot foresee the number of faults in advance. Considering the probabilistic fault model is more general because it encourages the proposed checkpointing strategy to be robust in a random environment. While, in contrast, addressing deterministic fault models (i.e., k-fault tolerance scenario) only guarantees performance in a limited number of faults. The k-fault model is not suitable in complex systems especially when the fault rate is high because a k-fault tolerant system drains out tolerance very soon and needs special treatment in such a high fault rate environment. The proposed strategy minimizes the total expected execution time, thus, leading to a higher probability of meeting deadlines than other strategies. All other strategies result in longer execution times and lower rates of meeting deadlines. The experimental results also show that the proposed strategy promises the shortest average execution time. In addition, we consider an overall deadline for all tasks instead of individual deadlines for different tasks.

The proposed strategy addresses transient faults. The proposed strategy addresses the transient fault under a certain distribution, and the permanent fault is out of the scope of this paper. To address permanent faults, the system must be designed with redundancy; thus, when permanent faults occur, it can migrate tasks from faulty processes to intact ones and establish new dependencies with new messages. The proposed approach can then be applied to ensure fault tolerance and minimize overall execution time. This migration of tasks can be done manually or automatically, depending on the system’s configuration and the nature of the fault. Once the migration is complete, the proposed approach can be used to partition dependent processes into a DAG graph, identify the critical path, and optimize the number and intervals of checkpoints to minimize the impact of faults and ensure timely recovery.

8 Conclusion

The main contribution of the paper is the consideration of both logical consistency and timing correctness during checkpoint placement in real-time systems. We first partition processes with complex dependencies into a DAG, during which we place some compulsory checkpoints to guarantee logical consistency and avoid much useful work waste. Then we extract the longest critical path to analyze timing correctness. Finally, we build a model to illustrate how to minimize each task’s execution time in the critical path to achieve minimum total execution time. Four simulations and a case study show the necessity to consider both logical and timing correctness, and our strategy performs the best among prior works and baselines.

References

[1]

Chuadhry Mujeeb Ahmed and Jianying Zhou. 2020. Challenges and opportunities in cyberphysical systems security: A physics-based perspective. IEEE Security & Privacy 18, 6 (2020), 14–22.

Abstract

1 Introduction

2 Preliminaries and Design Overview

2.1 Problem Statement

2.2 Overview of the Checkpointing Strategy

2.3 Models and Preliminaries

2.3.1 System Model.

2.3.2 Fault Model.

2.3.3 Notations in the Critical Path.

3 Process Partition with Logical Consistency

4 Critical Path Extraction

5 Checkpoint Placement for Timing Correctness

5.1 Optimization for the First Task

5.2 Optimization for Other Tasks

6 Evaluation

6.1 Simulation

6.1.1 Simulation Setting.

6.1.2 Simulation Result.

6.2 Case Study

7 Discussion

8 Conclusion

References

Cited By

Index Terms

Recommendations

On Real-Time Quasi-Durable Checkpointing

Analysis of checkpointing for schedulability of real-time systems

The Interplay of Power Management and Fault Recovery in Real-Time Systems

Comments

Information

Published In

Publisher

Journal Family

Publication History

Permissions

Check for updates

Author Tags

Qualifiers

Funding Sources

Contributors

Other Metrics

Bibliometrics

Article Metrics

Other Metrics

Citations

Cited By

View options

PDF

eReader

Login options

Full Access

Figures

Other

Share

Share this Publication link

Share on social media

Affiliations