From 0d9a56b8704ab4e8466d7e23823f61ec63d32eba Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Tue, 16 May 2017 14:17:02 +0200 Subject: comment out experiments again --- doc/paper/taler.tex | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 5166efea8..58573a7b0 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -1450,23 +1450,23 @@ FDH operations we used~\cite{rfc5869} with SHA-512 as XTR and SHA-256 for PRF as suggested in~\cite{rfc5869}. 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}) +%(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}) +%(Figure~\ref{fig:out}) and 160 kbit/sec to the exchange. -(Figure~\ref{fig:in}). +%(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 +%(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 -- cgit v1.2.3