diff options
| author | Dennis Brentjes <d.brentjes@gmail.com> | 2017-05-29 21:18:28 +0200 |
|---|---|---|
| committer | Dennis Brentjes <d.brentjes@gmail.com> | 2017-05-29 21:18:28 +0200 |
| commit | 33483109b741824e163210acfda07dfa96876cc9 (patch) | |
| tree | 331c9123e776535664175ea35ec1034c43227a13 /content/results.tex | |
| parent | dc7a8acf380ed8b3567bf9f8b51f3b15d61b602f (diff) | |
| download | thesis-33483109b741824e163210acfda07dfa96876cc9.tar.gz thesis-33483109b741824e163210acfda07dfa96876cc9.tar.bz2 thesis-33483109b741824e163210acfda07dfa96876cc9.zip | |
Some more twaeks to the LaTeX.
Diffstat (limited to 'content/results.tex')
| -rw-r--r-- | content/results.tex | 10 |
1 files changed, 6 insertions, 4 deletions
diff --git a/content/results.tex b/content/results.tex index 821886a..36c14b7 100644 --- a/content/results.tex +++ b/content/results.tex @@ -2,7 +2,7 @@ \label{sec:results} So the raw results presented in appendix \ref{app-tables} were obtained by running 3 nodes and 500 clients on the same computer. The clients and nodes operated in the way you would normally see a \cmix setup. All connections, either from node to node or client to node, are TCP connections encrypted using TLS. -Latency is off course negligible because all the participants are running on the same computer but the goal is not to measure network latency. Rather we want to know if there is a benefit in using elliptic curve as apposed to multiplicative group ElGamal. +Network latency is off course negligible because all the participants are running on the same computer but the goal is not to measure network latency. Rather we want to know if there is a benefit in using elliptic curve as apposed to multiplicative group ElGamal. The reason behind running 3 nodes is simple. There are subtle distinctions between what nodes do, depending on the position in the network. The first node needs to aggregate messages and initiate the mix when enough messages have been received. The last node needs to do additional calculations to prevent the tagging attack mentioned in section \ref{sec:tagging}. Additionally the last node needs to decrypt the final message en send it to its destination. So the minimal test case should contain 3 nodes. 1 first, 1 middle and 1 last node. I don't expect to see much difference between these nodes with the exception of the ``RealPost'' step as the last node needs to decrypt the ciphertext, and prepare plaintext buffers to send out to the clients. @@ -14,9 +14,11 @@ So for gathering results I created a program called statsd, it is included in th Gathering the results over TCP with a separate daemon enables people to run this same benchmark over separate servers. Enabling some nice test vectors as you can control network congestion and packet loss. -The following results were gathered with the pc specs as listed in appendix \ref{app-specs}. +\subsection{summary of the results} -\begin{table} +The following results were gathered with the pc specs as listed in appendix \ref{app-specs}. The optimization specific flags that were used are listed in appendix \ref{app-ccopts}. + +\begin{table}[!ht] \begin{tiny} \begin{tabularx}{\columnwidth}{|X|X|X|X|X|X|X|} \hline @@ -30,7 +32,7 @@ Node3 & 3.680 (0.026) & 2.819 (0.018) & 1.169 (0.028) & 0.302 (0.004) & 0.212 (0 \caption{Node time average over 50 runs with standard deviation in seconds using ed25519 and running 500 clients.} \end{table} -\begin{table} +\begin{table}[!ht] \begin{tiny} \begin{tabularx}{\columnwidth}{|X|X|X|X|X|X|X|} \hline |
