results and conclusion
authorTudorCazangiu <tudor.cazangiu@gmail.com>
Wed, 6 Jun 2012 03:06:10 +0000 (06:06 +0300)
committerTudorCazangiu <tudor.cazangiu@gmail.com>
Wed, 6 Jun 2012 03:06:10 +0000 (06:06 +0300)
doc/img/comparison.png [new file with mode: 0755]
doc/src/conclusions.tex
doc/src/results.tex

diff --git a/doc/img/comparison.png b/doc/img/comparison.png
new file mode 100755 (executable)
index 0000000..e620487
Binary files /dev/null and b/doc/img/comparison.png differ
index d53f2d4..bc5e6d1 100644 (file)
@@ -1,3 +1,6 @@
 \section{Conclusions and Further Work}
 \label{sec:conclusions}
-Our conclusions based on the results gathered at Section \ref{sec:results}.
+
+In this paper we presented an kernel alternative for building peer to peer systems. We done this because when files are transferred in peer to peer system important time is lost when context switch is done because of system calls. With our basic implementation, we demonstrate the viability of file transfer implemented in kernel, mainly because the performances were acceptable when a small number of peers are transferring the same file, compared to \texttt{sendfile}, and good for a large number of peers who transfer the same file. 
+
+To make the protocol viable for real peer-to-peer systems important improvements are needed. First a mechanism for sending just some parts of a file will be needed. Also support for the TCP protocol must be implemented in order to make transfers safe and reliable. 
index fa18e4f..a08b4fc 100644 (file)
@@ -1,43 +1,62 @@
 \section{Results}
 \label{sec:results}
-The results of the tests performed.
+
+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}.
 
 \begin{table}
        \begin{center}
-       \begin{tabular}{| c | c | c | c | c |}
+       \begin{tabular}{| c | c | c | c | c | c |}
                \hline
-               Sent(MB) & Time(s) & Two peers & Tree peers & Six peers \\
+               Sent(MB) & \multicolumn{5}{|c|} {Time}  \\
+               \cline{2-6}
+               & one peer & two peers & tree peers & six peers & eight peers\\
                \hline
-               32 & 4 & 10 & 18 & 49 \\
+               32 & 4 & 10 & 18 & 49 & 61 \\
                \hline
-               64 & 10 & 20 & 35 & 80 \\
+               64 & 10 & 20 & 35 & 80 & 115 \\
                \hline
-               128 & 20 & 42 & 58 & 226 \\
+               128 & 20 & 42 & 58 & 226 & 347\\
                \hline
-               256 & 41 & 75 & 129 & 385 \\
+               256 & 41 & 75 & 129 & 385 & 534 \\
                \hline
        \end{tabular}
        \end{center}
        \caption{Sendfile Results}
-       \label{sendfile_results}
+       \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.
+
+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.
+
 \begin{table}
        \begin{center}
-       \begin{tabular}{| c | c | c | c | c |}
+       \begin{tabular}{| c | c | c | c | c | c |}
                \hline
-               Sent(MB) & Time(s) & Two peers & Tree peers & Six peers \\
+               Sent(MB) & \multicolumn{5}{|c|} {Time}  \\
+               \cline{2-6}
+               & one peer & two peers & tree peers & six peers & eight peers\\
                \hline
-               32 & 13 & 29 & 35 & 45 \\
+               32 & 13 & 29 & 35 & 45 & 53 \\
                \hline
-               64 & 34 & 53 & 67 & 103 \\
+               64 & 34 & 53 & 67 & 103 &  125 \\
                \hline
-               128 & 66 & 118 & 142 & 167 \\
+               128 & 66 & 118 & 142 & 167 &  197 \\
                \hline
-               256 & 121 & 223 & 277 & 378 \\
+               256 & 121 & 223 & 277 & 378 & 446 \\
                \hline
        \end{tabular}
        \end{center}
        \caption{P2PKP Results}
-       \label{p2pkp_results}
+       \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.
+
+\begin{figure}[h!]
+        \centering
+        \includegraphics[scale=0.6]{img/comparison.png}
+        \caption{Comparison}
+        \label{fig:comp}
+\end{figure}
+