From 060e3a8002150d5795d489ccec999601d9109a42 Mon Sep 17 00:00:00 2001
From: mjkwiatkowski <mati.rewa@gmail.com>
Date: Tue, 7 Jul 2026 16:44:19 +0200
Subject: feat: finished section 2.1.2

---
 content/background.tex | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

(limited to 'content/background.tex')

diff --git a/content/background.tex b/content/background.tex
index 2f9cb2a..6be66ea 100644
--- a/content/background.tex
+++ b/content/background.tex
@@ -19,15 +19,23 @@ The scientific community has developed several datacenter simulators (see \Cref{
 In our work, we decided to use \code{OpenDC}, because we find it important for a simulator to model hardware failures well.
 \emph{Failure models} are a carefully calibrated, advanced feature of \code{OpenDC}.
 
-\subsection{Hardware Failures}\label{sss:failures}
-
-%What is below here is true, but nonetheless the argumentation should be slightly changed. And a citation is needed.
-However, there has been little effort made to integrate analytics that enable consistent and reliable prediction of datacenter behaviour into a holistic digital twin of a datacenter.
-Nor has the fidelity of failure modeling inside a datacenter simulation increased.
-The failure model is still a linear model.
-Since a datacenter simulator is quite different from a digital twin, we cannot use the same computation methods (not as they are right now, at least) -- we must adapt them.
-The prediciton models are the same ones for the digital twin as the ones used for the datacenter simulator.
-Since a digital twin is not a standalone simulator, a change to how we both predict and model failures is necessary.
+\subsection{Compute Failures}\label{sss:failures}
+A failure is defined as ``an event that makes a system fail to operate according to its specifications``~\cite{DBLP:journals/jpdc/JavadiKIE13}.
+Hardware and software failures in datacenters result in service downtime, missed \gls{sla} and user inconvenience~\cite{DBLP:conf/acsos/TalluriOVTI21, DBLP:journals/jpdc/JavadiKIE13}.
+A good example of a software failure is a hypervisor crash.
+Each \gls{vm} within the crashed hypervisor is killed as a result.
+An example of a hardware failure is a host crash, where a single server stops working (\eg as a result of a disk fault, or faulty power supply cable).
+
+\code{OpenDC} uses the notion of a \emph{failure model} to simulate failures, alongside \emph{failure traces}.
+A failure model consists of two statistical distributions:
+\begin{enumerate*}[label=(\arabic*)]
+	\item to model service unavailability
+	\item to model service availability.
+\end{enumerate*}
+A failure trace is defined by an interval, duration, and intensity of several failures, which are later looped throughout the simulated workload (source \url{opendc.org}).
+In summary \code{OpenDC} enables experimentation with failures that enables insights that are not provided by other state-of-the-art software.
+However, the fidelity of failure modeling inside a datacenter simulation is still insufficient to predict in failures in real-time, as they happen in a physical datacenter.
+Since a datacenter simulator is quite different from a digital twin, we cannot use the same computation methods from simulation to predict real-time failures.
 
 \section{Digital Twinning}\label{ss:digital-twinning}
 % To fix: remove the \gls commands for ExaDigiT.
@@ -154,7 +162,7 @@ Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves su
 \subsection{System Model for Datacenter Digital Twinning}
 \label{ss:system_model_for_dcdts}
 
-\begin{figure}[t]
+\begin{figure}[tb]
 	\centering
 	\includegraphics[width=\linewidth]{images/system_model.pdf}
 	\caption{A generic system model for data center digital twin deployments.
@@ -165,8 +173,8 @@ Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves su
 
 To summarize, many \gls{dcdt}'s model the cooling systems inside the warehouse, because in a typical datacenter cooling accounts for more than 40\% of total electricity usage~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
 Since the cooling subsystem is mainly airflow-based, \gls{dt} designers often opt for a \gls{cfd} approach to model the facility.
-The reason why a digital twin might be needed for a cooling subsystem is primarily because of inefficient operational strategy.
-The cooling system parameters are often set constant, regardless of outdoor temperature \etc~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
+%The reason why a digital twin might be needed for a cooling subsystem is primarily because of inefficient operational strategy.
+%The cooling system parameters are often set constant, regardless of outdoor temperature \etc~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
 %Zhang \etal argues that their system is akin to an IoT sensor, essentially.
 % This is an important consideration -- DT is not simply a sensor, it must have predictive capabilities and be able to simulate the future.
 % Zhang argues that ``digital twin services'' are enabled by simulation monitoring \etc.
-- 
cgit v1.2.3

