Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch.
Then tried to run it, but it core dumps :
Checking CPU capatibility...
AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...
[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12: 5354 Illegal instruction (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC
Of course it doesn't work. You compiled for a cpu which isn't compatible with yours. The compiler used some instructions which your cpu doesn't understand. I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong. I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels are poluted with higher level code, among many other things. I'll see if cygwin can come to my rescue. |
|
|
|
Hi Joblo, Thank you for this initiative. I downloaded the 3.0.1 version. It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04). Here is the build log (from ./build.sh) from the core 2 duo if interested. https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0Hi bobben, Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI. as a result cpuminer-opt on older CPUs is untested. I hope we can work together to get this working. I will download and look at your compile but I'm busy right now preparing another release. Stay tuned. I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue. the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks the CPU architectire in order to select code to run for the correct CPU architecture. I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it compiles. If successful try to run it and note the startup messages regarding the CPU capabilities. I hope this works. Edit: Only 64 bit CPU are supported. I changed march as you suggested. I got a bit further, but still errors. I commented out the content of the functions in algo/sse2/groestl/grso-asm.c as it was throwing errors. Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing: #include <stdio.h>
void quarkhash_aes() { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() { fprintf(stderr,"Nor this\n"); }
I then got the program linked, but it core dumps when I start it: Checking CPU capatibility... Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz AES_NI: No. SSE2: No, start mining without optimizations... [2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733 [2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm. /home/arve/miner_cpu_qubit: line 11: 3379 Illegal instruction (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion.. Here is the info from gdb after I recompiled with -g Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'. Program terminated with signal SIGILL, Illegal instruction. #0 0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8, out=0x7f69bae93a88) at strconv.c:69 69 value = strtod(strbuffer->value, &end); (gdb) Thanks a lot for the data. It's clear the support for older cpus just isn't there yet. That's what happens when one can't ddo his own testing I need to change that. I have a core2quad but it runs windows, I guess I'll have to get widows workinh sooner than later.. In the meantime, since youseem comfortable in the code I have a request to gather more data with some instrumented code. In file cpu-miner.c, function miner_thread there is a big switch statement casing on each algo. You will notice how I select the proper kernel. Simly comment out a few lines to force either the sse2 version or x64 version to run regardless of the detected CPU technology. If you could do this for several algos it would help identify any code contamination. The sausage factory in action. It ain't pretty and better done behind closed doors. Edit: try forcing all three kernels to run to see at what level your core2 fails. thanks I deleted all the source files, after suspecting make clean doesnt clean out all the object files. Then I did a fresh untar of version 3.0.2. This time, it compiled and linked cleanly. But still core dump when running. I tried changing the miner_thread to force a particular cpu architecture, as you suggested: bool cpu_aesni = has_aes_ni(); bool cpu_sse2 = has_sse2(); cpu_aesni = false; cpu_sse2 = false; then cpu_aesni = false; cpu_sse2 = true; then cpu_aesni = true; cpu_sse2 = true; but none worked. I then tried to recompile with the -g switch, but I got new errors.... ./algo/sse2/groestl/grso-asm.c: In function ‘grsoP1024ASM’: ./algo/sse2/groestl/grso-asm.c:6:3: error: ‘asm’ operand has impossible constraints asm ( ^ Too many problems with the miner on this CPU.. It might take some effort to fix this. You may want to put this lower on your priority list. Thanks for the testing. This is the kind of testing I should be doing behind closed doors. I'm going to fire up cygwin to see if I get get a testing environment on al oder CPU of my own. For now consider SSE2 ans x86_64 unsupported, will update OP. |
|
|
|
A compile issue has been discovered whenusing older CPUs that don't support AES_NI,
specifically a core2.
I am reconsidering support for older HW in light of the fact there seems to be little
demand for it.
The cpuminer-opt package includes AES_NI code that can't run on the native CPU. The
configure command includes the compile option "-march=native" tells the compiler not to
compile code that can't run on the native CPU. As a result the compiler throws an error and
the compile fails.
The code has runtime checks to isolate the AES_NI code from incompatible CPUs, the issue
is compiling.
I have suggested a workaround to change the compile option to specify an architecture that
does support AES_NI. To do this change "-march=native" to "-march=corei7-avs" or someting
similar.
At his time I have no feedback on the success of this workaround.
Should the workaround fail I will be forced with a decision.
I can try to find a compiler directive to selectively exclude specific code based on architecture.
I that is unsussesful I will have a couple of options.
I could drop support altogether for non AES_NI CPUs. The is still the TPruvot fork that is compatible
with all x86_64 CPU. But that leaves out the in-betweeners that have sse2 but not AES_NI.
I'm almost finished with the sse2 optimizations so I could build a special final release for sse2.
but only if there is interest. And I don't mean posting and saying do it. I mean substantial interest
like posting results showing you are trying to use cpuminer-opt. on an old CPU.
Please note that x86_64 is the absolute minimum HW arctitecture supported.
How 'bout it?
Edit: I have some small hashrate increases in a couple of algos but not enough for another release yet.
This problem is bigger than I anticipated. Along with the compile issues it appears the advanced code isn't properly identified and isolated. In order to gather more information I will provide two special packages targeted for x86_64 and SSE2 each. That will allow users to directly control which kernel is run. Hopefuly later today. |
|
|
|
Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch.
Then tried to run it, but it core dumps :
Checking CPU capatibility...
AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...
[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12: 5354 Illegal instruction (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC
It looks like I have a lot of work to do. And getting windows to work has become a higher priority so I can do my own testing on a core2. I'll finish up v3.0.3 then get to work on windows. |
|
|
|
Hi Joblo, Thank you for this initiative. I downloaded the 3.0.1 version. It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04). Here is the build log (from ./build.sh) from the core 2 duo if interested. https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0Hi bobben, Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI. as a result cpuminer-opt on older CPUs is untested. I hope we can work together to get this working. I will download and look at your compile but I'm busy right now preparing another release. Stay tuned. I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue. the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks the CPU architectire in order to select code to run for the correct CPU architecture. I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it compiles. If successful try to run it and note the startup messages regarding the CPU capabilities. I hope this works. Edit: Only 64 bit CPU are supported. I changed march as you suggested. I got a bit further, but still errors. I commented out the content of the functions in algo/sse2/groestl/grso-asm.c as it was throwing errors. Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing: #include <stdio.h>
void quarkhash_aes() { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() { fprintf(stderr,"Nor this\n"); }
I then got the program linked, but it core dumps when I start it: Checking CPU capatibility... Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz AES_NI: No. SSE2: No, start mining without optimizations... [2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733 [2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm. /home/arve/miner_cpu_qubit: line 11: 3379 Illegal instruction (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion.. Here is the info from gdb after I recompiled with -g Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'. Program terminated with signal SIGILL, Illegal instruction. #0 0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8, out=0x7f69bae93a88) at strconv.c:69 69 value = strtod(strbuffer->value, &end); (gdb) Thanks a lot for the data. It's clear the support for older cpus just isn't there yet. That's what happens when one can't ddo his own testing I need to change that. I have a core2quad but it runs windows, I guess I'll have to get widows workinh sooner than later.. In the meantime, since youseem comfortable in the code I have a request to gather more data with some instrumented code. In file cpu-miner.c, function miner_thread there is a big switch statement casing on each algo. You will notice how I select the proper kernel. Simly comment out a few lines to force either the sse2 version or x64 version to run regardless of the detected CPU technology. If you could do this for several algos it would help identify any code contamination. The sausage factory in action. It ain't pretty and better done behind closed doors. Edit: try forcing all three kernels to run to see at what level your core2 fails. thanks |
|
|
|
Tried compiling on a non-aesni cpu (core2), but it tries to use aesni on cryptonight:
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
_mm_aeskeygenassist_si128 (__m128i __X, const int __C)
^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
^
I posted about this back half a page or so. Try using -march=corei7-avx. It seems counter intuitive but we need to fool the compiler to compile the AESNI code. Once compile the run time checks will avoid falling into it. If you know of the appropriate compiler directive to check CPU architecture, please advise. I would simply: configure --disable-aesni wolf0 did it on his cryptonight cpuminer. If you're confirming it works for you, I'll document in the build instructions for next release. Know how to do it on VS? |
|
|
|
Tried compiling on a non-aesni cpu (core2), but it tries to use aesni on cryptonight:
In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
_mm_aeskeygenassist_si128 (__m128i __X, const int __C)
^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
^
I posted about this back half a page or so. Try using -march=corei7-avx. It seems counter intuitive but we need to fool the compiler to compile the AESNI code. Once compile the run time checks will avoid falling into it. If you know of the appropriate compiler directive to check CPU architecture, please advise. Edit: That's Wolf0's cryptonight he contributed. You should take a look at the code. He's done some things I haven't a clue what they are. He's been talking to Intel. At some point I'll dive in but I have others things on the go right now. In what's becoming a regular thing, I bring you a real time progress update. Found small improvement in lyra2 which translated into an almost immeasurable improvent in lyra2v2. Higher hash rates coming for sse2. aesni is mostly done for now. Code cleanup a tree restructuring planned. Am I avoiding windows support? Maybe but I'm making a lot of changes to the makefile sources and I don't want to have to make them in two places everytime. I'll do windows all at once. |
|
|
|
v3.0.2 seems to be running very well, only 19 rejects out of over 10k summits. 6700GH 4 cores used x11 coin. VM=Ubuntu 15.10 x86_64 Thanks for your hard work you put into this.  Thanks. I've made a breakthrough with a nagging problem. Sorry it's not windows (yet), but will give relatively big hash rate increase in quark & x* in a day or two. Edit: Due to the low hash rate of cpu miners in general the share submits aren't very frequent. This causes the pool reported hash rate to fluctuate from about 50% below what the miner reports to sometimes 200%. I would consider that normal. If the submit rate was higher the graph would be smoother and should be around the hash rate reported by the miner. In theory you don't lose anything because fewer shares means they are bigger. However, there is a possibility of hash being wasted if a block goes stale while you are working on it and that is more likely with a low hash rate. I have this issue to investigate on my to do list |
|
|
|
v3.0.2 seems to be running very well, only 19 rejects out of over 10k summits. 6700GH 4 cores used x11 coin. VM=Ubuntu 15.10 x86_64 Thanks for your hard work you put into this. Thanks. I've made a breakthrough with a nagging problem. Sorry it's not windows (yet), but will give relatively big hash rate increase in quark & x* in a day or two. Edit: Due to the low hash rate of cpu miners in general the share submits aren't very frequent. This causes the pool reported hash rate to fluctuate from about 50% below what the miner reports to sometimes 200%. I would consider that normal. If the submit rate was higher the graph would be smoother and should be around the hash rate reported by the miner. In theory you don't lose anything because fewer shares means they are bigger. However, there is a possibility of hash being wasted if a block goes stale while you are working on it. I have this issue to investigate on my to do list |
|
|
|
Hi All,
I've got an issue with my linux boxes. I've compiled the latest code just fine, but for some reason ccminer won't connect to some pools. specifically right now it won't connect to zpool. I keep getting "stratum_recv_line failed". With the same config, I can connect to coinotron or nicehash, but not to zpool. Weird thing is the compiled releases by sp_ on windows work just fine. So the private miner works fine as well. Anybody have some insight as to what could be going on?
Thanks,
dp
Looks like a pool problem. Are you connected to zpool simultaneously with both miners and only one fails? |
|
|
|
|
A compile issue has been discovered whenusing older CPUs that don't support AES_NI,
specifically a core2.
I am reconsidering support for older HW in light of the fact there seems to be little
demand for it.
The cpuminer-opt package includes AES_NI code that can't run on the native CPU. The
configure command includes the compile option "-march=native" tells the compiler not to
compile code that can't run on the native CPU. As a result the compiler throws an error and
the compile fails.
The code has runtime checks to isolate the AES_NI code from incompatible CPUs, the issue
is compiling.
I have suggested a workaround to change the compile option to specify an architecture that
does support AES_NI. To do this change "-march=native" to "-march=corei7-avs" or someting
similar.
At his time I have no feedback on the success of this workaround.
Should the workaround fail I will be forced with a decision.
I can try to find a compiler directive to selectively exclude specific code based on architecture.
I that is unsussesful I will have a couple of options.
I could drop support altogether for non AES_NI CPUs. The is still the TPruvot fork that is compatible
with all x86_64 CPU. But that leaves out the in-betweeners that have sse2 but not AES_NI.
I'm almost finished with the sse2 optimizations so I could build a special final release for sse2.
but only if there is interest. And I don't mean posting and saying do it. I mean substantial interest
like posting results showing you are trying to use cpuminer-opt. on an old CPU.
Please note that x86_64 is the absolute minimum HW arctitecture supported.
How 'bout it?
Edit: I have some small hashrate increases in a couple of algos but not enough for another release yet.
|
|
|
|
That certainly represents an unwelcome change in attitude. Why do you even bother with us pitifull freeloaders? |
|
|
|
(0.5btc from a bigfarm seems like a pretty bad deal for you...,
My private quark is still 20% faster then release 3 (sp-mod private) So you have three levels, a private one for yourself, another slower private one you sell and the, even slower, open source version. That's not a good way to do business. |
|
|
|
Hi Joblo, Thank you for this initiative. I downloaded the 3.0.1 version. It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04). Here is the build log (from ./build.sh) from the core 2 duo if interested. https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0Hi bobben, Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI. as a result cpuminer-opt on older CPUs is untested. I hope we can work together to get this working. I will download and look at your compile but I'm busy right now preparing another release. Stay tuned. I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue. the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks the CPU architectire in order to select code to run for the correct CPU architecture. I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it compiles. If successful try to run it and note the startup messages regarding the CPU capabilities. I hope this works. Edit: Only 64 bit CPU are supported. |
|
|
|
X11 Something I noticed Stratum difficulty set to 0.01 works gets shares at nicehash. Anything above 0.01 say 0.02, 0.04 I never get found shares. So perhaps a forced Stratum difficulty set to 0.01 in the command line would be best for some worker hardware. Just so it gets to finding shares quicker. This was on the same laptop in my previous posts in VM. It just goes on & on until the server finally lowers the Stratum difficulty to 0.01 wasting a lot of time & power. If the server Stratum connection timeout it starts you back at 0.04 and more time is wasted until it drops back to 0.01.
I have been told, but I can't confirm, is that you don't lose shares when the difficulty is high since the share submission is based on hash rate, so multuiply by time to get the share size. Longer time bigger share. However, the number of stale blocks may go up if the miner does not submit shares on a regular basis. CPU miners (the people not the program) should all be aware not to expect the same rate of submissions as with GPUs. When things settle down I plan on studying hash efficiency, ie how much hash is wasted. |
|
|
|
Hi Joblo, Thank you for this initiative. I downloaded the 3.0.1 version. It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04). Here is the build log (from ./build.sh) from the core 2 duo if interested. https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0Hi bobben, Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI. as a result cpuminer-opt on older CPUs is untested. I hope we can work together to get this working. I will download and look at your compile but I'm busy right now preparing another release. Stay tuned. |
|
|
|
Thanks for your efforts.
But testzcrypto version is not the fastest publicly available Argon2 miner.
Do you mean OPES? Found it, will follow up. Looks like a fork of testzcrypto. This one: https://github.com/Encel-US/cpuminer-multiIt includes teztcrypto optisation plus some scrypt-Jane. I gave encel a spin. It performs about the same level as my optimizations, we probably made the same changes Scrypt-jane is not there as a mineable algo, but part of argon2's chain. |
|
|
|
As much as I respect SP as a coder, I'd never pay for a miner that's release conditions and price are not clearly disclosed in advance.
And honestly, asking for 0.1 BTC for a few percentages every single day knowing damn well that it doesn't worth it for anyone who doesn't have a massive farm is getting pretty desperate and quite old here.
But one day there will be no more open source optimalizations, and then you will be forced to buy the private miner, or stop mining with a profit. Or build my own. Actually SP I don't want to fight with you. I'd rather work with you, If you're angry I haven't donated to your cause I can live with that. It's not like I don't contribute in other ways. I even help answer questions posed at you. I hope you reconsider your decision to go purely business-like. Like I said, for me it's a hobby, not a business. |
|
|
|
Let's do a profit calculation.. The nano can do 20MHASH of x11 0.020GHASH * 0.15 (Nicehash payment for 1 GHASH) = 0,003 BTC /DAY 500$ = 1,32BTC 1.32/0.003 = 440 It will take the Nano 440 days TO ROI with FREE POWER. And in these 440 days we have pascal and the 14NM chips comming.. Have to agree with that. I'm waiting for pascal. |
|
|
|
|
Show Posts
