search

JayDDee / cpuminer-opt

Optimized multi algo CPU miner
Other
775 stars 545 forks source link

Hashrate drop #191

Closed HotDrive69 closed 5 years ago

HotDrive69 commented 5 years ago

After a while, hashrate drop on some of the CPU threads, if not all. Is there a "keep alive" option? I notice that when I login back to the pc, the hashrate picks up a bit.

JayDDee commented 5 years ago

Please provide more details: minerversion, OS, CPU, algo, any error or warning messages, etc. Also monitor CPU usage, there may be other processes running taking time away from the miner.

HotDrive69 commented 5 years ago

There you go:

JayDDee commented 5 years ago

Are you running with the default all threads?

You have multi socket Xeons with Windows, that complicates things. Windows has many features for partitioning that require careful tuning. Things like CPU groups, NUMA etc just confuse the miner.

Add -D to the command line and post the output at startup. This will confirm all CPUs are being used properly.

With yescrypt you may find better performance using half the threads. This avoids hyperthreading and sometimes has better cache performance. This is not related to the problem you are reporting.

Edit: I looked up the specs for your CPUs and cache may be the issue. Your Xeons have 24 MB cache each for 16 threads. That's 1.5 MB per thread. You may find reducing the number of threads increases overall perfomrmance. Try to keep the thread count to round nnumbers like 32 and 48 for a 64 core system. Don't use affinity unless you really need to. Intel usually distributes the threads well with default affinity, don't mes with it unles you have idenfied poorly distributed threads.

Edit2; High priority probably doesn't help. If nothing else is running the miner will get all the avaiable CPU time. Setting high priotrity on a CPU hungry process may interfere with system operation. Also not related to your problem, just some advice.

HotDrive69 commented 5 years ago

Yes, I'm running with the default all threads. Here is the output of machine with more threads:

     **********  cpuminer-opt 3.9.4  ***********
 A CPU miner with multi algo support and optimized for CPUs
 with AES_NI and AVX2 and SHA extensions.
 BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: Intel(R) Xeon(R) CPU X7560 @ 2.27GHz. SW built on Jun 18 2019 with GCC 7.3.0. CPU features: SSE2 SSE4.2. SW features: SSE2. Algo features: SSE2 SHA. Start mining with SSE2.

[2019-06-26 16:38:36] Starting Stratum on stratum+tcp://blockmasters.co:6233/#xn sub [2019-06-26 16:38:36] 4 miner threads started, using 'yescrypt' algorithm. [2019-06-26 16:38:36] Binding thread 0 to cpu 0. [2019-06-26 16:38:36] Binding thread 3 to cpu 3. [2019-06-26 16:38:36] Binding thread 1 to cpu 1. [2019-06-26 16:38:36] Binding thread 2 to cpu 2.

I've disabled the high priority setup to see what happens. Can't really change any other os the specs because its a remote server. It gives low hashrate but it's free... :)

JayDDee commented 5 years ago

You can check that all CPU sockets get assigned miner threads. You can try reducing the threads by half, for example from the default 64 threads to 32. Note the performance and thread distribution. If distribution is not optimal try --cpu-affinity with differetn bit patterns to see how if affects performance. Typically --cpu-affinity 0x5555555555555555 works best when affinity is necessary but with a complex multi-socket system it may not. You may have to experiment.

You can also fine tune the thread count by bisecting. Try 64 then 32 then 48, 56 or 40, until you focus on the optimum.

Find the best configuration and run with it. Unless you think the miner could do something better I don't see a need to keep this issue open.

HotDrive69 commented 5 years ago

Well, funny thing. With priority set to normal and leaving the Task Manager open (to see the "CPU Usage History"), the hashrate doesn't drop... Thanks anyway for your help and support!