noah/MSThesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Use Cases

Browse Source
This commit is contained in:
Noah L. Schrick 2022-03-21 12:04:11 -05:00
parent a9c295655c
commit 01f2bbe83a
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Chapter5.tex
View File

@ -127,7 +127,7 @@ To ensure that the intended message is received by each node, the MPI message en
\caption{MPI Tags for the MPI Tasking Approach}
\end{table}
\TUsubsection{Performance Expectations} \label{Task-perf-expec}
\TUsubsection{Performance Expectations and Use Cases} \label{Task-perf-expec}
Due to the amount of communication between nodes to distribute the necessary data through all stages of the tasking pipeline, this approach is not expected to outperform the serial approach in all cases. This tasking approach was specifically designed to reduce the computation time when the generation of each individual state increases in time. This approach does not offer any guarantees of processing through the frontier at an increased rate; it's main objective is to distribute the workload of individual state generation. As discussed in Section \ref{sec:Intro}, the amount of entries in the National Vulnerability database and any custom vulnerability testing to ensure adequate examination of all assets in the network sums to large number of exploits in the exploit list. Likewise for compliance graphs and compliance examinations, Section \ref{sec:CG-diff} discussed that the number of compliance checks for SOX, HIPAA, GDPR, PCI DSS, and/or any other regulatory compliance also sums to a large number of exploits in the exploit list. Since the generation of each state is largely dependent on the number of exploits present in the exploit list, this approach is best-suited for when the exploit list grows in size.
\TUsubsection{Results}
@ -186,8 +186,8 @@ The root node is also responsible for merging the subgraphs. The root node will
\TUsubsubsection{Database Node}
A node dedicated to database operations is also present in this approach. The work performed for the subgraphing approach is identical to the work performed by Tasks 4 and 5 in the tasking approach, which is discussed in Section \ref{sec:T4T5}.
\TUsubsection{Performance Expectations}
This approach is intended to reduce runtime when the frontier grows at a rate faster than can be explored. However, since this approach is designed for distributed systems, there is no guarantee that speedup can be achieved when duplicate work is performed. Not only is there wasted time by the worker nodes when duplicate work occurs, but duplicate work also contributes to a longer runtime due to increased communication between nodes to adequately explore the graph, and also leads to increased numbers of merging calls by the root node. The ideal scenario for the subgraphing approach is when the graph is sparse, and the graph more aligns with a tree structure where each node only has one parent. When the graph is sparse, there is a lower likelihood of duplicate work occurring, since worker nodes have a lower probability of exploring a graph node that connects to a different graph node that has been (or will be) explored by another worker node. If each graph node were only able to have one parent, there is a lower likelihood that worker nodes would explore the same graph cluster.
\TUsubsection{Performance Expectations and Use Cases}
This approach is intended to reduce runtime when the frontier grows at a rate faster than it can be explored. However, since this approach is designed for distributed systems, there is no guarantee that speedup can be achieved when duplicate work is performed. Not only is there wasted time by the worker nodes when duplicate work occurs, but duplicate work also contributes to a longer runtime due to increased communication between nodes to adequately explore the graph, and also leads to increased numbers of merging calls by the root node. The ideal scenario for the subgraphing approach is when the graph is sparse, and the graph more aligns with a tree structure where each node only has one parent. When the graph is sparse, there is a lower likelihood of duplicate work occurring, since worker nodes have a lower probability of exploring a graph node that connects to a different graph node that has been (or will be) explored by another worker node. If each graph node were only able to have one parent, there is a lower likelihood that worker nodes would explore the same graph cluster.
\TUsubsection{Results}