Comments
This commit is contained in:
parent
64a582cb25
commit
f8465c25d6
|
@ -2,7 +2,7 @@
|
|||
\documentclass[]{llncs}
|
||||
|
||||
\usepackage{todonotes}
|
||||
\newcommand{\eb}[1]{\todo[inline]{(EB): #1}}
|
||||
\newcommand{\eb}[1]{\todo[inline, color=green]{EB: #1}}
|
||||
\newcommand{\jk}[1]{\todo[inline]{JK: #1}}
|
||||
|
||||
\usepackage{silence}
|
||||
|
@ -11,6 +11,13 @@
|
|||
\WarningFilter{caption}{Unsupported}
|
||||
\WarningFilter{caption}{Unknown document}
|
||||
|
||||
\usepackage{changes}
|
||||
\definechangesauthor[name=Betke, color=blue]{eb}
|
||||
\newcommand{\ebrep}[2]{\replaced[id=eb]{#1}{#2}}
|
||||
\newcommand{\ebadd}[1]{\added[id=eb]{#1}}
|
||||
\newcommand{\ebdel}[1]{\deleted[id=eb]{#1}}
|
||||
\newcommand{\ebcom}[1]{\comment[id=eb]{#1}}
|
||||
|
||||
\let\spvec\vec
|
||||
\let\vec\accentvec
|
||||
\usepackage{amsmath}
|
||||
|
@ -27,7 +34,6 @@
|
|||
\usepackage[listings,skins,breakable,raster,most]{tcolorbox}
|
||||
\usepackage{caption}
|
||||
|
||||
|
||||
\lstset{
|
||||
numberbychapter=false,
|
||||
belowskip=-10pt,
|
||||
|
@ -66,6 +72,7 @@
|
|||
\title{Using Machine Learning to Identify Similar Jobs Based on their IO Behavior}
|
||||
\author{Julian Kunkel\inst{2} \and Eugen Betke\inst{1}}
|
||||
|
||||
|
||||
\institute{
|
||||
University of Reading--%
|
||||
\email{j.m.kunkel@reading.ac.uk}%
|
||||
|
@ -75,6 +82,9 @@ DKRZ --
|
|||
}
|
||||
\begin{document}
|
||||
\maketitle
|
||||
\eb{Der Titel ist nicht zugtreffend. Hier ist kein Clustering im Spiel, also auch keine Machine Learning. Es wird ja nichts gelernt. Es ist eher so:
|
||||
``A Workflow for Identification of Similar Job by Means of Timeseries-based I/O Similarity Functions''
|
||||
}
|
||||
|
||||
\begin{abstract}
|
||||
|
||||
|
@ -308,12 +318,19 @@ Practically, the support team would start with Rank\,1 (most similar job, presum
|
|||
|
||||
When analyzing the overall population of jobs executed on a system, we expect that some workloads are executed several times (with different inputs but with the same configuration) or are executed with slightly different configurations (e.g., node counts, timesteps).
|
||||
Thus, potentially our similarity analysis of the job population may just identify the re-execution of the same workload.
|
||||
\ebadd{%
|
||||
In the most cases, the support staff would identify the re-execution of jobs simply by job names.
|
||||
The job names are often user defined generic strings and can contain confidential data.
|
||||
It is quite difficult to anonymize them and keep the meaning unchanged.
|
||||
Therefore, they are not available for this analysis.
|
||||
}%
|
||||
|
||||
To understand if the analysis is inclusive and identifies different applications, we use two approaches with our Top\,100 jobs:
|
||||
We explore the distribution of users (and groups), runtime, and node count across jobs.
|
||||
The algorithms should include different users, node counts, and across runtime.
|
||||
To confirm hypotheses presented, we analyzed the job metadata comparing job names which validates our quantitative results discussed in the following.
|
||||
|
||||
|
||||
\paragraph{User distribution.}
|
||||
To understand how the Top\,100 are distributed across users, the data is grouped by userid and counted.
|
||||
\Cref{fig:userids} shows the stacked user information, where the lowest stack is the user with the most jobs and the top most user in the stack has the smallest number of jobs.
|
||||
|
@ -333,8 +350,9 @@ As post-processing jobs use typically one node and the number of postprocessing
|
|||
The boxplots have different shapes which is an indication, that the different algorithms identify a different set of jobs -- we will analyze this later further.
|
||||
|
||||
\paragraph{Runtime distribution.}
|
||||
The runtime of the Top\,100 jobs is shown using boxplots in \Cref{fig:runtime-job}.
|
||||
The \added{job} runtime of the Top\,100 jobs is shown using boxplots in \Cref{fig:runtime-job}.
|
||||
While all algorithms can compute the similarity between jobs of different length, the bin algorithms and hex\_native penalize jobs of different length leading to a narrow profile.
|
||||
\eb{``Narrow profiles'' sieht man irgendwie nicht in den Bildern. (Oder ich hab's nicht verstanden. Verstande habe ich, dass ``Narrow profile`` eine Jobmenge ist mit einer ahnlichen Laufzeit.)}
|
||||
For Job-M and Job-L, hex\_phases is able to identify much shorter or longer jobs.
|
||||
For Job-L, the job itself isn't included in the chosen Top\,100 (see \Cref{fig:hist-job-L}, 393 jobs have a similarity of 100\%) which is the reason why the job runtime isn't shown in the figure itself.
|
||||
|
||||
|
@ -380,6 +398,7 @@ For Job-L, the job itself isn't included in the chosen Top\,100 (see \Cref{fig:h
|
|||
\caption{Distribution of node counts (for Job-S nodes=1 in all cases)}
|
||||
\label{fig:nodes-job}
|
||||
\end{figure}
|
||||
\eb{In \Cref{fig:nodes-job} koennte man noch evtl. die Anzahl der Knoten der untersuchten Jobs einblenden.}
|
||||
|
||||
\begin{figure}
|
||||
\begin{subfigure}{0.31\textwidth}
|
||||
|
@ -401,6 +420,7 @@ For Job-L, the job itself isn't included in the chosen Top\,100 (see \Cref{fig:h
|
|||
\caption{Distribution of runtime for all 100 top ranked jobs}
|
||||
\label{fig:runtime-job}
|
||||
\end{figure}
|
||||
\eb{In \Cref{fig:runtime-job} koennte man evtl. noch die Laufzeit der untersuchten Jobs einblenden.}
|
||||
|
||||
\subsubsection{Algorithmic differences}
|
||||
To verify that the different algorithms behave differently, the intersection for the Top\,100 is computed for all combination of algorithms and visualized in \Cref{fig:heatmap-job}.
|
||||
|
@ -409,6 +429,8 @@ While there is some reordering, both algorithms lead to a comparable order.
|
|||
The hex\_lev and hex\_native algorithms are also exhibiting some overlap particularly for Job-S and Job-L.
|
||||
For Job\-M, however, they lead to a different ranking and Top\,100.
|
||||
From the analysis, we conclude that one representative from binary quantization is sufficient while the other algorithms identify mostly disjoint behavioral aspects and, therefore, should be considered together.
|
||||
\eb{Ist das eine generelle Aussage: ``one representative from binary quantization is sufficient``? Wenn ja, dann ist sie sehr wage. Koennte Zufall sein.}
|
||||
|
||||
|
||||
|
||||
\begin{figure}
|
||||
|
@ -432,6 +454,7 @@ From the analysis, we conclude that one representative from binary quantization
|
|||
\caption{Intersection of the 100 top ranked jobs for different algorithms}
|
||||
\label{fig:heatmap-job}
|
||||
\end{figure}
|
||||
\eb{In \Cref{fig:heatmap-job} muss die Farbpalette gefixt werden. Auf blau sieht man gar nichts.}
|
||||
|
||||
\section{Assessing Timelines for Similar Jobs}
|
||||
|
||||
|
@ -514,6 +537,7 @@ Bin aggzeros works quite well here too. The jobs are a bit more diverse.
|
|||
\subsection{Job-M}
|
||||
|
||||
Bin aggzero liefert Mist zurück.
|
||||
\eb{Wegen Bug?}
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue