diff options
| author | Florian Dold <florian.dold@gmail.com> | 2018-11-13 01:03:11 +0100 |
|---|---|---|
| committer | Florian Dold <florian.dold@gmail.com> | 2018-11-13 01:03:11 +0100 |
| commit | 4704e08210188168e664687362178918b923ffc7 (patch) | |
| tree | 31176c2e95d387dfe58f214bc7e0f3c2cb911e08 /taler | |
| parent | 5f7e8e7a545684218bce2836dff19541e2bb2b36 (diff) | |
| download | dold-thesis-phd-4704e08210188168e664687362178918b923ffc7.tar.gz dold-thesis-phd-4704e08210188168e664687362178918b923ffc7.tar.bz2 dold-thesis-phd-4704e08210188168e664687362178918b923ffc7.zip | |
typos/extrapolation
Diffstat (limited to 'taler')
| -rw-r--r-- | taler/implementation.tex | 16 |
1 files changed, 13 insertions, 3 deletions
diff --git a/taler/implementation.tex b/taler/implementation.tex index 6e3822c..fb308dc 100644 --- a/taler/implementation.tex +++ b/taler/implementation.tex @@ -1994,8 +1994,9 @@ clients saturates the number of available CPU cores (96). There is no significant decrease in throughput even when the system is under rather high load, as clients whose requests cannot be handled in parallel are either waiting in the exchange's listen backlog or waiting in a retry timeout -(randomized, truncated, exponential back-off) after being refused when the -listen backlog backlog is full. +(with randomized, truncated, exponential back-off) after being refused when the +exchange's listen backlog is full. + Figure~\ref{fig:benchmark-cpu} shows the CPU time (sum of user and system time) of both the exchange and the whole benchmark testbed (including the exchange) @@ -2007,9 +2008,18 @@ as part of the benchmark). With a growing number of parallel transactions, the database runs into an increasing number of failed commits due to read/write conflicts, leading to retries of the corresponding transactions. +To estimate the time taken up by cryptographic operations in the exchange, we +first measured a baseline with a single client, where the wall-clock time for +cryptographic operations is very close to the actual CPU time, as virtually no +context switching occurs. We then extrapolated these timings to experiment +runs with parallelism by counting the number of times each operation is +executed and multiplying with the baseline. As seen in the dot-and-dash line +in Figure~\ref{fig:benchmark-cpu}, by our extrapolation slightly more than half +of the time is spent in cryptographic routines. + We furthermore observe in Figure~\ref{fig:benchmark-cpu} that under full load, less than $1/3$ of the CPU time is spent by the exchange. A majority of the -CPU time in the benchmark is spent in cryptographic operations done by clients. +CPU time in the benchmark is used by the simulation of clients. As we did not have a machine available that is powerful enough to generate 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 |