Adding figure descriptions; instance timing data

Schrick-Noah_AG-CG-CR.tex

@@ -132,6 +132,34 @@ Previous works with RAGE have been designed around maximizing performance to lim
 The restarting process for attack and compliance graph generation requires only a limited set of information. In order for a proper generation restart, the generator first needs to pull the unexplored queue (``frontier") database table into memory. After the frontier is loaded, the generator tool needs to know at which integer to begin tagging new states. This is accomplished by checking the ID of the latest state in the frontier. Since the instance has already been explored, it does not need to be retrieved from disk. In addition, the frontier is a queue of unexplored nodes. Since these nodes have yet to be explored, no edge information is available, and as a result, no edge information is required. At this point, the generator tool is able to pop the first node from the queue and resume the generation process.
 
 \section{Results}
+Results were collected to measure the checkpointing time as a function of the instance size in bytes, as well as the frontier size in bytes. The restart results were collected to measure the time taken to restart as a function of the frontier size in bytes. In order to mitigate the non-deterministic effects of networking as much as possible, the checkpointing and restarting processes were called by a compute node that was also running the PostgreSQL instance. 
+
+Figure \ref{fig:inst-time} displays the time taken to checkpoint as the instance size grows. The size of the instance was measured in bytes, to allow for abstracting the number of items in the instance and the size of each item. This figure demonstrates that as the instance grows, the time taken to checkpoint remains 
+
+\begin{figure}[htp]
+    \centering
+    \includegraphics[width=\linewidth]{"./images/instance_time.png"}
+        \caption{Time Taken to Checkpoint as the Size of the Instance Grows}
+        \label{fig:inst-time}
+\end{figure}
+
+Figure \ref{fig:front-chk-time} displays the time taken to checkpoint as the frontier size grows. Similar to the instance size, the frontier was also measured in bytes for consistency. This figure illustrates that as the frontier grows, the checkpoint time also remains
+
+\begin{figure}[htp]
+    \centering
+    \includegraphics[width=\linewidth]{"./images/frontier_checkpoint_time.png"}
+        \caption{Time Taken to Checkpoint as the Size of the Frontier Grows}
+        \label{fig:inst-time}
+\end{figure}
+
+Figure \ref{fig:front-rest-time} displays the time taken to restart as the frontier size grows. The frontier was again measured in bytes. This figure, like the previous two, illustrates that the restart time remains X as the size of the frontier grows.
+
+\begin{figure}[htp]
+    \centering
+    \includegraphics[width=\linewidth]{"./images/frontier_restart_time.png"}
+        \caption{Time Taken to Restart as the Size of the Frontier Grows}
+        \label{fig:inst-time}
+\end{figure}
 
 \section{Conclusions and Future Work}
 This work presents an application-level approach at C/R. This approach was built into RAGE itself, and has no dependencies on C/R libraries. In addition, it does not need support from the operating system, allowing for fault-tolerance on HPC clusters that may not support C/R. The results highlight the minimal time requirement to both checkpoint and restart the generation process. Since only the necessary information is stored and retrieved, there are no lengthy function calls or snapshots that are required. The C/R implemented also serves as a form of memory relief. Due to the size of large-scale attack and compliance graphs, there is increased difficulty in storing all information in memory. This approach allows users to abstract away the memory constraint difficulties while maximizing performance.