\section{Results}
\label{sec:results}
-We want to view if our implementation is viable in terms of performances. To do this we compare our results with the results of \texttt{sendfile} system call. The \texttt{sendfile} command (\textbf{ssize\_t sendfile(int} \textit{out\_fd,} \textbf{int} \textit{in\_fd,} \textbf{off\_t *}\textit{offset,} \textbf{size\_t} \textit{count}\textbf{);}) is used to send \texttt{count} bytes from \texttt{in\_fd} to \texttt{out\_fd}.
+Our goal is to stress our implementation in order to determine if it is
+viable in terms of performance. In order to achieve this, we have compared our
+results with the \texttt{sendfile} system call. As already stated in Section
+\ref{sec:intro}, this function uses a zero-copy mechanism to avoid passing
+information from kernel space and back.
\begin{table}
\begin{center}
\label{sendfile-results}
\end{table}
-In the first test we sent files of 32, 64, 128 and 256 MB from one node to a different number of peers. We varied the number of peers from 1 to 8. The results can be seen in Table \ref{sendfile-results}. We can see that the time needed to send files of different size grows almost linearly, with a factor smaller than 1. This is expected because for each peer we execute a different sendfile system call.
+Section \ref{sec:testing} largely details the test scenarios we have
+performed. Particularly, this is the test where we varied the number of peers
+from 1 to 8. The results gathered are displayed in Table \ref{sendfile-results}.
+We can easily observe that the time needed to send files of different size grows
+almost linearly, with a factor lower than 1. This was expected because for each
+peer, we execute at least one more \texttt{sendfile} system call.
-In the second test, we used our peer-to-peer kernel protocol also on files with size growing from 32MB to 256MB. The number of peers used in test was varied from 1 to 8. The results presented in Table \ref{p2pkp-results}, show an almost linear growth of the time needed to send the files from the sender to peers but with a smaller factor than in the case of \texttt{sendfile}. For small number of peers, one two or three, the results were better in the tests made with sendfile, but for a greater number of peers the results are better when using the p2pkp.
+For the second test, we used our peer-to-peer kernel protocol for sending
+files on with sizes growing from 32MB up to 256MB. The number of peers used in
+this test was varied from 1 to 8. The results presented in Table,
+\ref{p2pkp-results}, show an almost linear growth of the time needed to send the
+files from sender to peers, but with a smaller factor than the one achieved in
+case of the \texttt{sendfile} system call. For small number of peers, one, two
+or three, \texttt{senfile} has a higher performance rate, but for a greater
+number of peers our implementation has better results.
\begin{table}
\begin{center}
\label{p2pkp-results}
\end{table}
-We also made a graphic shown in Figure \ref{fig:comp} to view more clearly the differences between sendfile and peer-to-peer kernel protocol. As we can see, with the increase of the number of peers p2pkp become more and more good, and finally overcame the performances of sendfile.
+We have also compiled a graphic, shown in Figure \ref{fig:comp}, that better
+exposes the differences between \texttt{sendfile} and the P2PKP kernel module.
+As we can see, while the number of peers increase, our implementation
+overcomes the performance of \texttt{sendfile}.
\begin{figure}[h!]
\centering
\includegraphics[scale=0.6]{img/comparison.png}
- \caption{Comparison}
+ \caption{\texttt{sendfile} vs P2PKP}
\label{fig:comp}
\end{figure}
projects / p2p-kernel-protocol.git / blobdiff