update data

3 files changed, 37 insertions, 19 deletions

diff --git a/acknowledgements.tex b/acknowledgements.tex
index c8bf59e..d7ffacc 100644
--- a/acknowledgements.tex
+++ b/acknowledgements.tex
@@ -44,6 +44,9 @@ work on my thesis, and Jean-Louis Lanet for agreeing to co-advise my thesis.
 Special thanks goes to Thomas Given-Wilson, Fabrizio Biondi, Laurent Morin and
 Nisrine Jafri for their support and company.
 
+I also thank the Bern University of Applied Sciences for providing the hardware that
+was using during experiments.
+
 Thanks to Marcello Stanisci for his work as an engineer on the GNU Taler project.
 
 Chapter \ref{chapter:consensus} is based on work published in the EURASIP
diff --git a/taler/implementation.tex b/taler/implementation.tex
index bbc1eb8..04659df 100644
--- a/taler/implementation.tex
+++ b/taler/implementation.tex
@@ -988,7 +988,7 @@ processing Taler payments and provides a simple HTTP API.  The merchant backend
 handles cryptographic operations (signature verification, signing), secret
 management and communication with the exchange.
 
-The backend API\footnote{See Appendix~\ref{chap:taler-api-reference} for the full documentation}
+The backend API\footnote{See \url{https://docs.taler.net/api/} for the full documentation}
 is divided into two types of HTTP endpoints:
 \begin{enumerate}
   \item Functionality that is accessed internally by the merchant.  These APIs typically
@@ -1905,7 +1905,7 @@ correspond to the actual CPU time required for the respective operations, as
 the benchmark with one client runs significantly fewer processes/threads than
 the number of available CPUs on our machine.
 
-The benchmark completed in $17.14$ minutes. We obtained the total CPU usage of
+The benchmark completed in $20.76$ minutes. We obtained the total CPU usage of
 the benchmark testbed and exchange.  The refresh operations are rather slow in comparison
 to spends and deposits, as the benchmark with a refresh probability of $0\%$ only took $8.84$
 minutes to complete.
@@ -1985,7 +1985,7 @@ practice, information for multiple reserves would be tracked for each active
 cutomers.
 
 The TCP/IP network traffic between the exchange, clients and the mock bank was
-$\SI{85.2}{\mebi\byte}$, measured by the Linux kernel's statistics for
+$\SI{57.95}{\mebi\byte}$, measured by the Linux kernel's statistics for
 transmitted/received bytes on the relevant network interface.  As expected, the
 traffic is larger than the size of the database, since some data (such as
 signatures) is only verified/generated and not stored in the database.
@@ -2029,7 +2029,7 @@ traffic that can saturate a single exchange running on \texttt{firefly}, we
 estimate the throughput that would be possible if the machine only ran the
 exchange.  The highest rate of spends was $780$ per second.  Thus, the
 theoretically achievable transaction rate on our single test machine (and a
-dedicated machine for the database) would be $780 * 3 / 10 = 234$ transactions
+dedicated machine for the database) would be $780 \cdot 3 / 10 = 234$ transactions
 per second under the relatively pessimistic assumptions we made about what
 consitutes a transaction.
 
@@ -2037,7 +2037,7 @@ If a GNU Taler deployment was used to pay for items of fixed price (e.g., online
 news articles), the overhead of multiple coins and refresh operations (which
 accounts for $\approx 50\%$ of spent time as measured earlier) and multiple
 coins per payment would vanish, giving an estimated maximum transaction rate of
-$780 * 2 = 1560$ transactions per second.
+$780 \cdot 2 = 1560$ transactions per second.
 
 \begin{figure}
   \includegraphics[width=\textwidth]{plots/speed.pdf}
@@ -2069,7 +2069,7 @@ additional delay of $\approx \SI{200}{\milli\second}$ when the artificial
 delay is introduced.  Without TCP Fast Open, we would observe an extra round
 trip for the SYN and SYN/ACK packages without any payload.  The
 \texttt{/refresh/reveal} operation takes an extra roundtrip due to the
-relatively large size of the response, which contains the signatures for
+relatively large size of the response (as show in Table~\ref{table:api-size}), which contains the signatures for
 multiple coins.
 
 Figure~\ref{fig:latencies} shows the latency for the exchange's HTTP endpoints
@@ -2087,21 +2087,41 @@ be linear, due to timeouts raised by clients.
   \toprule
     Endpoint &
     {\specialcell[c]{Base latency\\(\si{\milli\second})}} &
-    {\specialcell[c]{Latency with\\\SI{100}{\milli\second} delay\\(\si{\milli\second})}} &
-    {\specialcell[c]{Request size\\(\si{\kilo\byte})}} &
-    {\specialcell{Response size\\(\si{\kilo\byte})}} \\
+    {\specialcell[c]{Latency with\\\SI{100}{\milli\second} delay\\(\si{\milli\second})}} \\
   \midrule
-    \texttt{/keys}                &  1.14   &    201.25   & 0.14  & 1.67  \\ 
-    \texttt{/reserve/withdraw}    &  22.68  &    222.46   & 0.71   & 0.73 \\ 
-    \texttt{/deposit}             &  22.36  &   223.22    & 1.40   & 0.34  \\
-    \texttt{/refresh/melt}        &  20.71  &    223.9    & 1.06   & 0.35 \\ 
-    \texttt{/refresh/reveal}      &  63.64  &   466.30    & 1.67   & 2.11 \\
+    \texttt{/keys}                &  1.14   &    201.25   \\ 
+    \texttt{/reserve/withdraw}    &  22.68  &    222.46   \\ 
+    \texttt{/deposit}             &  22.36  &   223.22    \\
+    \texttt{/refresh/melt}        &  20.71  &    223.9    \\ 
+    \texttt{/refresh/reveal}      &  63.64  &   466.30    \\
   \bottomrule
   \end{tabular}
   \caption{Effects of \SI{100}{\milli\second} symmetric network delay on total latency.}
   \label{table:latency}
 \end{table}
 
+\begin{table}
+  \centering
+  \begin{tabular}{lSSSS}
+  \toprule
+    Endpoint &
+    {\specialcell[c]{Request size 2048-bit RSA\\(\si{\kilo\byte})}} &
+    {\specialcell{Response size 2048-bit RSA\\(\si{\kilo\byte})}} \\
+    {\specialcell[c]{Request size 1024-bit RSA\\(\si{\kilo\byte})}} &
+    {\specialcell{Response size 1024-bit RSA\\(\si{\kilo\byte})}} \\
+  \midrule
+    \texttt{/keys}                 & 0.14  & 3.75 & 0.14 & 3.43  \\ 
+    \texttt{/reserve/withdraw}     & 0.73   & 0.71 & 0.60 & 0.49 \\ 
+    \texttt{/deposit}              & 1.40   & 0.34 & 1.14 & 0.24  \\
+    \texttt{/refresh/melt}         & 1.06   & 0.35 & 0.85 & 0.35  \\ 
+    \texttt{/refresh/reveal}       & 1.67   & 2.11 & 1.16 & 1.23 \\
+  \bottomrule
+  \end{tabular}
+  \caption[Request and response sizes for the exchange's API.]{Request and response sizes for the exchange's API.
+  In addition to the sizes for 2048-bit RSA keys (used throughout the benchmark), the sizes for 1024-bit RSA keys are also provided.}
+  \label{table:api-size}
+\end{table}
+
 \begin{figure}
   \includegraphics[width=\textwidth]{plots/latencies.pdf}
   \caption[Effect of artificial network delay on exchange's latency.]{Effect of artificial network delay on exchange's latency.}
diff --git a/thesis.tex b/thesis.tex
index af124cc..b0d7c51 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -177,9 +177,4 @@ of the wallet reference implementation (\url{https://git.taler.net/wallet-webex.
 
 \lstinputlisting[basicstyle=\footnotesize]{coinsim.ts}
 
-\chapter{Taler HTTP API Reference}\label{chap:taler-api-reference}
-Available at \url{https://docs.taler.net/api/}.  The API reference
-will be included in the final print version of the manuscript.
-
-
 \end{document}