JakeHillion/dissertation-4-dissertation
1
0
Fork 0
Code Issues Pull Requests Releases 1 Wiki Activity

handover commit

Browse Source
This commit is contained in:
Jake Hillion 2020-11-16 22:48:33 +00:00
parent 552c563982
commit 703a8cebdd
2 changed files with 11 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Evaluation/evaluation.tex
View File

@ -11,15 +11,15 @@
\graphicspath{{Evaluation/Figs/Vector/}{Evaluation/Figs/}}
\fi
This chapter will discuss the methods used to evaluate my project and the results gained. The results will be discussed in the context of the success criteria, laid out in the Project Proposal.
This chapter will discuss the methods used to evaluate my project and the results gained. The results will be discussed in the context of the success criteria laid out in the Project Proposal.
This evaluation shows that a network using my method of combining Internet connections can see vastly superior network performance to one without. It will show the benefits to throughput, redundancy, and adaptability.
This evaluation shows that a network using my method of combining Internet connections can see vastly superior network performance to one without. It will show the benefits to throughput, availability, and adaptability.
\section{Evaluation Methodology}
I performed my experiments on a local Proxmox\footnote{\url{https://proxmox.com}} server. To encourage frequent and thorough testing, a harness was built in Python, allowing tests to be added with very small difficulty and repeated with any code changes.
I performed my experiments on a local Proxmox\footnote{\url{https://proxmox.com}} server. To encourage frequent and thorough testing, a harness was built in Python, allowing tests to be added easily and repeated with any code changes.
Proxmox was chosen due to its RESTful API, for integration with Python. It provides the required tools to limit connection speeds and disable connections. The server that ran these tests holds only a single other virtual machine which handles routing. This limits the effects of external factors on the tests.
Proxmox was chosen due to its RESTful API, for integration with Python. It provides the required tools to limit connection speeds and disable connections. The server that ran these tests holds only a single other virtual machine which handles routing. This limits the effect of external factors on the tests.
The tests are performed on a Dell R710 Server with the following specifications:
@ -34,6 +34,7 @@ The tests are performed on a Dell R710 Server with the following specifications:
The majority of data presented in this section will be in the form of line graphs. These are generated in a consistent format, using a script found in appendix \ref{appendix:graph_generation}.
\begin{figure}
\centering
\begin{subfigure}{.3\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/IS0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
\caption{No error bars}
@ -92,7 +93,7 @@ To generate these results, a fresh set of VMs (Virtual Machines) are created and
\label{fig:standard-network-structure}
\end{figure}
The network structure of all standard tests is shown in figure \ref{fig:standard-network-structure}. Any deviations from this structure will be mentioned. The Local Portal has as many interfaces as referenced in any test, plus one to connect to the client. All Virtual Machines also have an additional interface for management, but it is not relevant to the tests.
The network structure of all standard tests is shown in figure \ref{fig:standard-network-structure}. Any deviations from this structure will be mentioned. The Local Portal has as many interfaces as referenced in any test, plus one to connect to the client. All Virtual Machines also have an additional interface for management, but this has no effect on the tests.
@ -107,6 +108,7 @@ TODO.
The performance gains measured are visible in both directions (inbound and outbound to the client). The graphs shown in this evaluation section are inbound unless stated otherwise, with the outbound graphs being available in Appendix \ref{appendix:outbound-graphs}.
\begin{figure}
\centering
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/IEyS0-R0-2R1-2T10S1-R0-1R1-2T10S2-R0-1R1-1T10}
\caption{The inbound graph}
@ -152,7 +154,7 @@ This goal was to ensure the Client could use its network interface as if it real
\subsection{Security}
TODO.
Not implemented yet.
\subsection{More Bandwidth over Two Equal Connections}
@ -176,6 +178,7 @@ This is demonstrated by showing that $1x1MB + 1x2MB$ connections can exceed the
\subsection{More Bandwidth over Four Equal Connections}
\begin{figure}
\centering
\begin{subfigure}{.49\textwidth}
\includegraphics[width=0.9\linewidth]{graphs/IEyS0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
\caption{1MB connections}
@ -228,11 +231,11 @@ ip rule add to 1.1.1.3 table 10 priority 10
\label{fig:policy-based-routing-script-remote-portal}
\end{figure}
The single interface Remote Portal is achieved using a similar set of commands to the IP Spoofing. The majority of the work is again done by policy based routing, with some kernel parameters needing to be set too. A sample script is shown in figure \ref{fig:policy-based-routing-script-remote-portal}.
The single interface Remote Portal is achieved using a similar set of commands to IP Spoofing. The majority of the work is again done by policy based routing, with some kernel parameters needing to be set too. A sample script is shown in figure \ref{fig:policy-based-routing-script-remote-portal}.
\subsection{Connection Metric Values}
TODO.
Not implemented yet.

BIN
thesis.pdf
View File

Binary file not shown.