0.0.2 configure update

8 files changed, 82 insertions, 2 deletions

diff --git a/configure.ac b/configure.ac
index 494877381..d91072c2a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,7 +17,7 @@
 #
 #
 AC_PREREQ([2.69])
-AC_INIT([taler-exchange], [0.0.1], [taler-bug@gnunet.org])
+AC_INIT([taler-exchange], [0.0.2], [taler-bug@gnunet.org])
 AC_CONFIG_SRCDIR([src/util/util.c])
 AC_CONFIG_HEADERS([taler_config.h])
 # support for non-recursive builds
diff --git a/doc/paper/bw_in.png b/doc/paper/bw_in.png
new file mode 100644
index 000000000..14d718a04
--- /dev/null
+++ b/doc/paper/bw_in.png
diff --git a/doc/paper/bw_out.png b/doc/paper/bw_out.png
new file mode 100644
index 000000000..bcc857c71
--- /dev/null
+++ b/doc/paper/bw_out.png
diff --git a/doc/paper/cpu_balance.png b/doc/paper/cpu_balance.png
new file mode 100644
index 000000000..bb25c1ab3
--- /dev/null
+++ b/doc/paper/cpu_balance.png
diff --git a/doc/paper/cpu_usage.png b/doc/paper/cpu_usage.png
new file mode 100644
index 000000000..0726a1cd1
--- /dev/null
+++ b/doc/paper/cpu_usage.png
diff --git a/doc/paper/db_read.png b/doc/paper/db_read.png
new file mode 100644
index 000000000..e67bcfbf1
--- /dev/null
+++ b/doc/paper/db_read.png
diff --git a/doc/paper/db_write.png b/doc/paper/db_write.png
new file mode 100644
index 000000000..063c6fbab
--- /dev/null
+++ b/doc/paper/db_write.png
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index d93cbf9cc..9e10b3937 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -32,6 +32,9 @@
 \usetikzlibrary{shapes,arrows}
 \usetikzlibrary{positioning}
 \usetikzlibrary{calc}
+\usepackage{caption}
+\usepackage{subcaption}
+\usepackage{subfig}
 
 % Relate to:
 % http://fc14.ifca.ai/papers/fc14_submission_124.pdf
@@ -661,7 +664,7 @@ merchant trusts the exchange that issued the coin.
 Merchants are identified by their public key $M_p = m_s G$ which the
 customer's wallet learns through the merchant's webpage, which itself
 must be authenticated with X.509c.
-% FIXME: Is this correct? 
+% FIXME: Is this correct?
 
 We now describe the protocol between the customer, merchant, and exchange
 for a transaction in which the customer spends a coin $C := (c_s, C_p)$
@@ -928,6 +931,83 @@ can then use the refresh protocol to anonymously melt the refunded
 coin and create a fresh coin that is unlinkable to the refunded
 transaction.
 
+\section{Experimental results}
+
+\begin{figure}[b!]
+  \begin{subfigure}{0.45\columnwidth}
+    \includegraphics[width=\columnwidth]{bw_in.png}
+    \caption{Incoming traffic at the exchange, in bytes per 5 minutes.}
+    \label{fig:in}
+  \end{subfigure}\hfill
+  \begin{subfigure}{0.45\columnwidth}
+    \includegraphics[width=\columnwidth]{bw_out.png}
+    \caption{Outgoing traffic from the exchange, in bytes per 5 minutes.}
+    \label{fig:out}
+  \end{subfigure}
+  \begin{subfigure}{0.45\columnwidth}
+    \includegraphics[width=\columnwidth]{db_read.png}
+    \caption{DB read operations per second.}
+    \label{fig:read}
+  \end{subfigure}
+  \begin{subfigure}{0.45\columnwidth}
+    \includegraphics[width=\columnwidth]{db_write.png}
+    \caption{DB write operations per second.}
+    \label{fig:write}
+   \end{subfigure}
+  \begin{subfigure}{0.45\columnwidth}
+    \includegraphics[width=\columnwidth]{cpu_balance.png}
+    \caption{CPU credit balance. Hitting a balance of 0 shows the CPU is
+       the limiting factor.}
+    \label{fig:cpu}
+  \end{subfigure}\hfill
+  \begin{subfigure}{0.45\columnwidth}
+    \includegraphics[width=\columnwidth]{cpu_usage.png}
+    \caption{CPU utilization. The t2.micro instance is allowed to use 10\% of
+       one CPU.}
+    \label{fig:usage}
+  \end{subfigure}
+  \caption{Selected EC2 performance monitors for the experiment in the EC2
+           (after several hours, once the system was ``warm'').}
+  \label{fig:ec2}
+\end{figure}
+
+We ran the Taler exchange v0.0.2 on an Amazon EC2 t2.micro instance
+(10\% of a Xeon E5-2676 at 2.4 GHz) based on Ubuntu 14.04.4 LTS, using
+a db.t2.micro instance with Postgres 9.5 for the database.  Using 16
+concurrent clients performing withdraw, deposit and refresh operations
+we then pushed the t2.micro instance to the resource limit
+(Figure~\ref{fig:cpu}) from a network with $\approx$ 160 ms latency to
+the EC2 instance.  At that point, the instance managed about 8 HTTP
+requests per second, which roughly corresponds to one full business
+transaction (as a full business transaction is expected to involve
+withdrawing and depositing several coins).  The network traffic was
+modest at approximately 50 kbit/sec from the exchange
+(Figure~\ref{fig:out}) and 160 kbit/sec to the exchange
+(Figure~\ref{fig:in}).  At network latencies above 10 ms, the delay
+for executing a transaction is dominated by the network latency, as
+local processing virtually always takes less than 10 ms.
+
+Database transactions are dominated by writes (Figure~\ref{fig:read}
+vs.  Figure~\ref{fig:write}), as Taler mostly needs to log
+transactions and occasionally needs to read to guard against
+double-spending.  Given a database capacity of 2 TB---which should
+suffice for more than one year of full transaction logs---the
+described setup has a hosting cost within EC2 of approximately USD 252
+per month, or roughly 0.0001 USD per full business transaction.  This
+compares favorably to the $\approx$ USD 10 per business transaction
+for Bitcoin and the \EUR{0.35} plus 1.9\% charged by Paypal for
+domestic transfers within Germany.
+
+In the Amazon EC2 billing, the cost for the database (using SSD
+storage) dominates the cost with more than USD 243 per month.  We note
+that these numbers are approximate, as the frontend and backend in our
+configuration uses systems from the AWS Free Usage Tier and is not
+perfectly balanced in between frontend and backend.  Nevertheless,
+these experimental results show that computing-related business costs
+will only marginally contribute to the operational costs of the Taler
+payment system.
+
+
 
 \section{Discussion}