What would be good metrics to measure impact on miners when tweaking hardware/system?

Question

Let's start with wolf's miner and Linux kernel 3.x at least.

What would be some good metrics to measure (+/-) impact for tweaking kernel (kernel cmdline like nohz_full/tickless/ intel.cstate), pinning process and sysctl like vm.stat_interval?

Strongly reducing the OS jitter on hashing thread can save some context switching overhead and rescheduling load, and give more CPU time per second to hashing process.

Do you consider hashrate to be a good metric with a static diff of course? Or do you think reducing OS jitter will not improve hashrate, but the number of submitted shares per time slot might increase?

For example, pinning thread to dedicated core seems to reduce the hashrate. But is the impact positive or negative?

Answer 1

The hash rate is of course the main metric to consider, since it determines how fast the miner can go through nonces in order to find a hash that meets the difficulty. Whether the difficulty is static or not is not really important, since it only determines when a found hash will be submitted to the pool. This does add some overhead if you're submitting too often, of course, but I think it is minimal.

Another thing to consider is energy expenditure. If you run on a laptop, a tool like powertop can help you see power usage. If you're on a machine without a battery that can report such things, I'm not sure there's a good tool for this, though.

A less interesting metric might be network latency between the miner and the pool. However, this is likely to have only minimal impact.

If you want to go lower level, the tool perf can show you what a process is busy doing, so you know what parts of the code is the current bottleneck.

/proc/$PID/ has a number of interesting things you could check: /proc/$PID/status gives you number of context switches. Other files may have other interesting statistics on a running program.

Last, Wolf's miner has a --benchmark option. It may or may not be in working order in your version, but IIRC the changes needed to revive it were minimal (it was a long time ago, I don't remember what they were off the top of my head).