Post
Topic
Board Mining (Altcoins)
Re: [ANN]: cpuminer-opt v3.4.7, now on GIT
by
shakeandbake
on 13/10/2016, 12:52:14 UTC
I have dual L5640 Wesmere processors (dual 6 core = 24 thread) and I get horrible performance no matter which exe I use... or even running via Linux, 100 h/s is about all I get. Is there a bug or something I'm missing?

Try it with 6 threads per cpu, that should better fit the L3 cache and make sure the miner recongnizes AES.
Otherwise I need a lot more info.

Are there any debug logs or anything like that I can retrieve? any parameters I can add, when launching, to get additional debug info ?

You mean like a console session? Why haven't you posted that yet? There's a lot of good info displayed when the miner starts up,
it should be obvious to post that as a minimum when asking a question.

OK got some info - also, the result is no different in v3.4.7

edit: Also a note about config... these results were compiled with march=westmere -O3 ; trying other variations doesn't do much +/- a few percentage points (march=native, -O2,1,fast etc..)

6-thread

      **********  cpuminer-opt 3.4.8-dev  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz
CPU features: SSE2 AES
SW built on Oct 13 2016 with GCC 5.4.0
SW features: SSE2 AES
Algo features: SSE2 AES
Start mining with SSE2 AES

[2016-10-13 03:06:50] Starting Stratum on stratum+tcp://xmr.pool.minergate.com:45560
[2016-10-13 03:06:50] 6 miner threads started, using 'cryptonight' algorithm.
[2016-10-13 03:06:50] Stratum difficulty set to 4252
[2016-10-13 03:06:53] CPU #4: 66 H, 31.26 H/s
[2016-10-13 03:06:53] CPU #5: 66 H, 31.22 H/s
[2016-10-13 03:06:53] CPU #2: 66 H, 30.11 H/s
[2016-10-13 03:06:53] CPU #0: 66 H, 30.00 H/s
[2016-10-13 03:06:53] CPU #3: 66 H, 29.95 H/s
[2016-10-13 03:06:53] CPU #1: 66 H, 28.31 H/s
[2016-10-13 03:07:25] CPU #5: 1058 H, 32.97 H/s
[2016-10-13 03:07:25] CPU #1: 1004 H, 31.48 H/s
[2016-10-13 03:07:25] CPU #2: 1016 H, 31.72 H/s
[2016-10-13 03:07:25] CPU #0: 1014 H, 31.66 H/s
[2016-10-13 03:07:25] CPU #3: 1012 H, 31.60 H/s
[2016-10-13 03:07:25] CPU #4: 1060 H, 33.00 H/s
[2016-10-13 03:07:44] CPU #5: 645 H, 33.04 H/s
[2016-10-13 03:07:45] Accepted 1/1 (100%), 5751 H, 192.50 H/s, 51C

8 thread:

   **********  cpuminer-opt 3.4.8-dev  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz
CPU features: SSE2 AES
SW built on Oct 13 2016 with GCC 5.4.0
SW features: SSE2 AES
Algo features: SSE2 AES
Start mining with SSE2 AES

[2016-10-13 03:08:29] Starting Stratum on stratum+tcp://xmr.pool.minergate.com:45560
[2016-10-13 03:08:29] 8 miner threads started, using 'cryptonight' algorithm.
[2016-10-13 03:08:30] Stratum difficulty set to 4252
[2016-10-13 03:08:33] CPU #6: 40 H, 15.84 H/s
[2016-10-13 03:08:33] Accepted 1/1 (100%), 40 H, 15.84 H/s, 52C
[2016-10-13 03:08:34] CPU #4: 66 H, 18.90 H/s
[2016-10-13 03:08:34] CPU #5: 66 H, 17.43 H/s
[2016-10-13 03:08:34] CPU #3: 66 H, 16.84 H/s
[2016-10-13 03:08:34] CPU #2: 66 H, 16.24 H/s
[2016-10-13 03:08:34] CPU #7: 66 H, 15.81 H/s
[2016-10-13 03:08:35] CPU #0: 66 H, 15.52 H/s
[2016-10-13 03:08:35] CPU #1: 66 H, 14.82 H/s
[2016-10-13 03:08:54] CPU #7: 312 H, 16.13 H/s
[2016-10-13 03:08:54] Accepted 2/2 (100%), 748 H, 131.71 H/s, 52C




Just a note about this - I was reading about this issue a number of days ago and someone mentioned that AES may not actually be enabled even though it says that it is? I just can't imagine that dual 6-core L5640 processors would perform like this without something being wrong. I tried doling things out via numactl and that didn't have any impact to speak of.