Add support for automated benchmarking

[clbr]

This allows easy integration into benchmarking scripts; previously you'd need to kill it with a signal and then try to find the line.

The endless benchmarking mode is still supported, but now you can optionally specify the amount of rounds, and the total result is averaged over all these rounds.

[clbr]

Ping.

[pooler]

Sorry for the late reply. I started looking into this but then I got distracted by other urgent matters.

But let's get to the point. I have doubts about this being the most proper way to implement automated benchmarking, for various reasons.

• Averaging over all rounds is probably not what we want when benchmarking, given that on many systems the first round can be significantly slower than subsequent ones (think about CPUs waking up from idle state, or adjusting their clock frequency).
• I'm not even sure letting it run for more than one round makes sense, given that one can simply adjust the scan time to make rounds last longer, and that we are only interested in the final result.
• The current hash rate reporting system is very basic, and cannot provide a reliable total hash rate when running more than one mining thread. Basing automated benchmarking on such a system can lead to wildly wrong results.

Given the last point above, I'd rather postpone the implementation of this feature until the current reporting system is replaced with something more reliable.

[clbr]

On Mon, 27 Jan 2014 02:52:08 -0800
pooler [email protected] wrote:

• The current hash rate reporting system is very basic, and cannot provide a reliable total hash rate when running more than one mining thread. Basing automated benchmarking on such a system can lead to wildly wrong results.

Given the last point above, I'd rather postpone the implementation of this feature until the current reporting system is replaced with something more reliable.

How so? I run with 6 cores (= 6 threads), and it gives reliable results
repeatedly.

[pooler]

In my experience, the results are only acceptable under certain conditions. For instance, Intel CPUs that support hyper-threading can give particularly unreliable results.
The root cause of this problem is that miner threads are (by design) not synchronized, so in general the thread hash rates do not refer to the same time span.

[clbr]

On Mon, 27 Jan 2014 03:51:10 -0800
pooler [email protected] wrote:

In my experience, the results are only acceptable under certain conditions. For instance, Intel CPUs that support multithreading can give particularly unreliable results.
The root cause of this problem is that miner threads are (by design) not synchronized, so in general the thread hash rates do not refer to the same time span.

Wouldn't the averaging help that? The average of, say, 10 rounds would
absorb any volatility both in the first round and that of variable
round timing.

[pooler]

Wouldn't the averaging help that? The average of, say, 10 rounds would absorb any volatility both in the first round and that of variable round timing.

To some extent, but as I said I don't think that's the most proper way to do it. I would rather have just one round and make sure that the thread hash rates refer more or less to the same time span, and above all, that none is missing.