diff options
Diffstat (limited to 'content/background.tex')
| -rw-r--r-- | content/background.tex | 31 |
1 files changed, 23 insertions, 8 deletions
diff --git a/content/background.tex b/content/background.tex index 8adcae5..4884995 100644 --- a/content/background.tex +++ b/content/background.tex @@ -2,7 +2,6 @@ \section{Overview}\label{s:background_overview} - \section{Datacenters}\label{ss:datacenters} \subsection{Computing Infrastructure}\label{sss:failures} @@ -36,7 +35,6 @@ Since a digital twin is not a standalone simulator, a change to how we both pred \input{sources/simulator_comparison.tex} \section{Digital Twinning}\label{ss:digital-twinning} - % To fix: remove the \gls commands for ExaDigiT. % This is getting silly. \subsection{What is Digital Twinning?}\label{sss:what_is_digital_twinning} @@ -65,13 +63,10 @@ As a result, digital twins have become more relevant today than 10 years ago~\ci \subsection{Digital Twins across Domains}\label{sss:digital_twins_across_domains} \subsection{Digital Twins for Datacenters}\label{sss:digital_twins_for_datacenters} -The foundation to any digital twin is good monitoring and sensing capabilities in the physical entity. -Datacenters, meet this requirement easily because they already connect hundreds of monitoring sensors. -With hundreds of gigabytes of useful information coming from distributed \gls{iot} sensors inside the warehouse, we can gain insight into failure patterns, energy usage, heat dissipation \etc -Moreover, CPU profiling, VM uptime, workload type enable datacenter managers to leverage \gls{oda} to gain meaningful insights into datacenter operation. -But currently one of the key challenges is to somehow connect the physical and virtual spaces with a bi-directional connection, that aims to use the monitoring insights and data analysis results to make autonomous decisions. -\gls{dcdt}'s emerged to address this problem. +In this section, we survey the work related to datacenter digital twinning. +We summarize our results in Table \ref{tab:dt_features_comparison} to compare and contrast the features of existing datacenter digital twins. +We select only the digital twins that adhere closest to the \gls{nasem} definition~\cite{DBLP:usdoe/report/AP26894}. \input{sources/dt_features_comparison.tex} @@ -115,6 +110,17 @@ DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24} is an adaptive digital twin with vi % Documentation: https://learn.microsoft.com/en-us/azure/digital-twins/ % Moreover, NVIDIA is doing too as well https://www.nvidia.com/en-sg/omniverse/ +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}. +%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. +% Nonetheless, I dub that they are primarily data analysis services. + +\gls{oda} can be performed in-band (real-time) and out-of-band (from historical data). +Likewise, Zhao \etal shows that crucial to the digital twin system are ``always-on'' analytics (akin to in-band \gls{oda}) and ``on-demand`` analytics (akin to out-of-band \gls{oda}). %Include something about data-preprocessing in the pipeline. %See the article by Fei Tao @@ -126,6 +132,15 @@ DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24} is an adaptive digital twin with vi \label{fig:system_model} \end{figure} +The design of DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24} incorporates in its architecture a ``virtual-to-virtual`` digital thread between different digital twins. +Zhao \etal include this element in their architecture too~\cite{DBLP:conf/AppliedEnergy/Zhao20}. +Moreover, a crucial parallel between the work of Zhao \etal and ExaDigiT is the concept of multiple models within a single digital twin. +Brewer \etal argue ExaDigiT is compromised of 5 ``smaller'' twins too. + +%In Zhang \etal the digital twin can communicate with different other digital twins, as in the work of Taheri \etal. +%To do this, the working program has an API, with a specific API endpoint to communicate with other Digital Twins. +%In your work, consider adding such an endpoint, albeit explain in future work that you envision \emph{implementing} this endpoint in the future. + |