Topic: Wolf's XMR/BCN/DSH CPUMiner - 2x speed compared to LucasJones' - NEW 06/20/2014 - page 18. (Read 547105 times)
August 02, 2014, 03:16:06 PM
You have 48 cores? (2-Core-CPUs?)
June 20, 2014, 07:33:27 AM
Wolf0, I've ran folding at home using alinux VM before (virtual box) and it ran like native Linux on the CPU side of things.
you could make a prebuilt mining is image for windows users to mine with. Might get you some extra tips too
what do you think?
you could make a prebuilt mining is image for windows users to mine with. Might get you some extra tips too
what do you think?
I think you missed the part in the OP where I said it can't be virtualized. Gotta be native.
August 02, 2014, 02:54:41 PM
One thing I found rather interesting:
root@cami001:/# minerd --help
..
-t, --threads=N number of miner threads (default: number of processors)
..
root@cami001:/# grep processor /proc/cpuinfo | wc -l
24
root@cami001:/# /usr/local/bin/minerd -o stratum+tcp://x.x.x.x:x -p x -u xx
[2014-08-02 15:49:42] Using JSON-RPC 2.0
[2014-08-02 15:49:42] 31 miner threads started, using 'cryptonight' algorithm.
[2014-08-02 15:49:42] Starting Stratum on stratum+tcp://x.x.x.x:x
Out of interests sake, how/where is 31 processors being returned? If I set the thread count manually (-t 24), 24 threads are used and the H/S is extremely consistent.
root@cami001:/# minerd --help
..
-t, --threads=N number of miner threads (default: number of processors)
..
root@cami001:/# grep processor /proc/cpuinfo | wc -l
24
root@cami001:/# /usr/local/bin/minerd -o stratum+tcp://x.x.x.x:x -p x -u xx
[2014-08-02 15:49:42] Using JSON-RPC 2.0
[2014-08-02 15:49:42] 31 miner threads started, using 'cryptonight' algorithm.
[2014-08-02 15:49:42] Starting Stratum on stratum+tcp://x.x.x.x:x
Out of interests sake, how/where is 31 processors being returned? If I set the thread count manually (-t 24), 24 threads are used and the H/S is extremely consistent.
August 02, 2014, 02:45:18 PM
Each optimization I tested worked on my CPU - I don't have all CPUs, so I can't test. That much of a reduction is odd, though... are you sure the test wasn't affected by other factors?
It's quite a difference. I have 8 of those monster servers that are freshly installed (+updated) with Ubuntu 14.04.
They are all identical and unused (no running services, crons etc..) but the results are rather inconsistent across each so perhaps something else could be influencing things.
I'll dig a bit deeper and see if anything comes of it.
June 20, 2014, 12:03:07 AM
wolf, another quick question, I was trying to run the miner, while still doing some gpu mining , but when I do so, the % of good hash on the gpu miner starts to take a hit. I even tried just using 1 thread out of the 4 but it still degrades the gpu miner performance, any tips?
Hm... try lowering the priority of the CPU miner and/or raising the priority of the GPU miner in Task Manager. Whatever you do, do NOT use the "Realtime" setting - it always locked my systems up.
Figured it out, I had to set the affinity of processor to not steal from each other
Interesting how that works - I disabled setting affinity (it was only ever done when the number of threads is a multiple of the number of CPU cores) because it lowered hashrate a lot on servers, especially AWS.
August 02, 2014, 01:29:43 PM
Btw.. Just thought i'd mention this:
Latest CPUMiner compiled from git: (24 x Intel(R) Xeon(R) CPU X5650 @ 2.67GHz)
Over a 20 minute duration:
[2014-08-02 20:25:25] accepted: 191/234 (81.62%), 230.74 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 192/235 (81.70%), 230.63 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 193/236 (81.78%), 230.61 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:31] accepted: 194/237 (81.86%), 230.16 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:40] accepted: 195/238 (81.93%), 231.01 H/s at diff 980 (yay!!!)
Then i removed all of the "optimizations" from the Makefile:
From:
am__append_3 = -Ofast -flto -fuse-linker-plugin -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-if-convert-stores -fmerg
e-all-constants -fbranch-target-load-optimize2 -fsched2-use-superblocks -maes
to :
am__append_3 = -maes
The result?
[2014-08-02 20:26:44] accepted: 189/231 (81.82%), 289.83 H/s at diff 1384 (yay!!!)
[2014-08-02 20:26:45] accepted: 190/232 (81.90%), 290.09 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:03] accepted: 191/233 (81.97%), 291.41 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:07] accepted: 192/234 (82.05%), 290.47 H/s at diff 1384 (yay!!!)
There are numerous posts/warnings on-line about over-aggressive compile-time "optimizations".
Just thought I'd post my results/findings which concur.
Regards,
Cami
Latest CPUMiner compiled from git: (24 x Intel(R) Xeon(R) CPU X5650 @ 2.67GHz)
Over a 20 minute duration:
[2014-08-02 20:25:25] accepted: 191/234 (81.62%), 230.74 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 192/235 (81.70%), 230.63 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 193/236 (81.78%), 230.61 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:31] accepted: 194/237 (81.86%), 230.16 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:40] accepted: 195/238 (81.93%), 231.01 H/s at diff 980 (yay!!!)
Then i removed all of the "optimizations" from the Makefile:
From:
am__append_3 = -Ofast -flto -fuse-linker-plugin -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-if-convert-stores -fmerg
e-all-constants -fbranch-target-load-optimize2 -fsched2-use-superblocks -maes
to :
am__append_3 = -maes
The result?
[2014-08-02 20:26:44] accepted: 189/231 (81.82%), 289.83 H/s at diff 1384 (yay!!!)
[2014-08-02 20:26:45] accepted: 190/232 (81.90%), 290.09 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:03] accepted: 191/233 (81.97%), 291.41 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:07] accepted: 192/234 (82.05%), 290.47 H/s at diff 1384 (yay!!!)
There are numerous posts/warnings on-line about over-aggressive compile-time "optimizations".
Just thought I'd post my results/findings which concur.
Regards,
Cami
August 02, 2014, 12:54:11 PM
Hey..
Firstly, thank you for the awesome CPUMiner. It works like a charm.
Is merged mining possible with your / Wof's CPUMiner?
http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work
http://monetaverde.org/
Merged mining will allow you to mine MCN (MonetaVerde) in addition to to the major coin (XMR etc) without a reduction in hashrate.
I see its been asked before, but i was unable to find a conclusive response.
Regards,
Cami
Firstly, thank you for the awesome CPUMiner. It works like a charm.
Is merged mining possible with your / Wof's CPUMiner?
http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work
http://monetaverde.org/
Merged mining will allow you to mine MCN (MonetaVerde) in addition to to the major coin (XMR etc) without a reduction in hashrate.
I see its been asked before, but i was unable to find a conclusive response.
Regards,
Cami
June 19, 2014, 10:54:07 PM
wolf, another quick question, I was trying to run the miner, while still doing some gpu mining , but when I do so, the % of good hash on the gpu miner starts to take a hit. I even tried just using 1 thread out of the 4 but it still degrades the gpu miner performance, any tips?
Hm... try lowering the priority of the CPU miner and/or raising the priority of the GPU miner in Task Manager. Whatever you do, do NOT use the "Realtime" setting - it always locked my systems up.
July 31, 2014, 04:43:32 PM
July 31, 2014, 06:06:04 AM
I get this error when i try to compile it:
How to solve that?
System is Debian wheezy 64bit.
Code:
root@prox8:~/cpuminer-multi# ./autogen.sh
configure.ac:133: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
How to solve that?
System is Debian wheezy 64bit.
Compile latest autoconf from source.
June 19, 2014, 09:48:30 PM
wolf, looked for a help readme but could not find one..thanks for the info.
No problem... maybe I should include a readme or something.
readme would be helpful for the first time users, also the ones who are new to mining.
Yeah. Also would be helpful for users just new to this miner - that way they could look at the readme and know how to setup hugepages on linux, rather than having to come to this thread.
July 31, 2014, 06:03:24 AM
I'm not sure this will work, but did you tried:
Code:
./autogen.sh -m4_pattern_allow
July 31, 2014, 04:43:24 AM
I get this error when i try to compile it:
How to solve that?
System is Debian wheezy 64bit.
Code:
root@prox8:~/cpuminer-multi# ./autogen.sh
configure.ac:133: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
How to solve that?
System is Debian wheezy 64bit.
June 19, 2014, 09:43:20 PM
wolf, looked for a help readme but could not find one..thanks for the info.
No problem... maybe I should include a readme or something.
July 25, 2014, 08:28:46 AM
minerd-wolf-07-09-14 hits me hard with a decrease in performance. ~120 h/s
using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s
CPU is a 12 core Xeon E5-2430 V2 Is this expected?
using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s
CPU is a 12 core Xeon E5-2430 V2 Is this expected?
I think that minerd-wolf-07-09-14 is only for non-AES-NI cpus. That would explain the drop in hashrate for you and why when I tried it at first I saw a major drop in speed.
Thanks, guess I had a hard time reading lol. It clearly stated that it was for NON AES-NI. Not sure what I was thinking. THanks again.
July 24, 2014, 10:42:50 AM
Similar results here. I ran some tests with a dual E5520 server.
cpu-multi / LucasJones (these are the same thing, right?) v2.3.3 gets max 148 H/s and is pretty much always over 140.
Wolf's newly provided non-AES version gets 118 H/s max, with a range of 100 - 118.
Looks like any advantages of Wolf's miner come from the AES-NI code.
cpu-multi / LucasJones (these are the same thing, right?) v2.3.3 gets max 148 H/s and is pretty much always over 140.
Wolf's newly provided non-AES version gets 118 H/s max, with a range of 100 - 118.
Looks like any advantages of Wolf's miner come from the AES-NI code.
I've now complied and run Wolf's latest version on this same non-AES-NI machine under Linux and although there's a very slight improvement over windows it's still way slower than LucasJones' is under Windows.
So I can only assume my previous statement was correct and that any gains Wolf's version gives are down to the AES-NI parts of his code and you need a machine with AES-NI capable cpus to take full advantage of it.
June 19, 2014, 09:35:47 PM
When writing the batch file to start the miner, how do you specify the number of core, like if I wanted to only use 2.
Thx
-t 2Thx
Read the --help next time.
July 24, 2014, 07:39:46 AM
Whereabouts do I need to put the "--disable-aes-ni" when compiling?
./autogen.sh
CFLAGS='-march=native' ./configure --disable-aes-ni
make -j
possibly "make clean" before "make"
July 24, 2014, 07:31:09 AM
Win64 binaries exist but require AES-NI.
If I compile from source should I be able to run it on a processor without AES-NI then? I compiled it successfully in an Virtualbox Ubuntu 13.04 virtual machine (on a Win 7 host without AES-NI), but get:Code:
[2014-05-31 09:46:38] Using JSON-RPC 2.0
[2014-05-31 09:46:38] 2 miner threads started, using 'cryptonight' algorithm.
Illegal instruction (core dumped)
upon starting up the miner.
Configure with --disable-aes-ni
Whereabouts do I need to put the "--disable-aes-ni" when compiling?
July 23, 2014, 06:29:40 PM
minerd-wolf-07-09-14 hits me hard with a decrease in performance. ~120 h/s
using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s
CPU is a 12 core Xeon E5-2430 V2 Is this expected?
using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s
CPU is a 12 core Xeon E5-2430 V2 Is this expected?
I think that minerd-wolf-07-09-14 is only for non-AES-NI cpus. That would explain the drop in hashrate for you and why when I tried it at first I saw a major drop in speed.
Jump to: