algo/hodl/hodl-gate.c:132:7: error: ‘algo_gate_t’ has no member named ‘set_data_size’
gate->set_data_size = (void*)&hodl_set_data_size;
^
make[2]: *** [algo/hodl/cpuminer-hodl-gate.o] Fehler 1
make[2]: Verzeichnis »/home/kim/cpuminer-opt-3.1.17« wird verlassen
make[1]: *** [all-recursive] Fehler 1
make[1]: Verzeichnis »/home/kim/cpuminer-opt-3.1.17« wird verlassen
make: *** [all] Fehler 2
kim@spiel-2:~/cpuminer-opt-3.1.17$
That's a coding error. I just recompiled successfuly from the tarball I uploaded so don't know why you got that error. This line happens when you're compiling for core2. You probably removed set_data_size everywhere but on that line. I had to remove it in my fork. This is getting really weird. I reproduced the compile error with core2. It doesn't make any sense because set_data_size is not conditional on the arch. I need to really dig into this. Edit: I take that back, I found some weird code I need to sort out. Edit2: set_data_size is a coding error on my part. When hodl was introduced set_data_size became targetted. In 3.1.16 I eliminated the need for set_data_size but missed one reference in targetted code and failed to test that target. At this point with so many versions flying around I'm hesitant to rush out another one. Hmage seems to have posted a version with the set_data_size fix so I'll wait to see if that solves both problems before I build another release. |
|
|
|
algo/hodl/hodl-gate.c:132:7: error: ‘algo_gate_t’ has no member named ‘set_data_size’
gate->set_data_size = (void*)&hodl_set_data_size;
^
make[2]: *** [algo/hodl/cpuminer-hodl-gate.o] Fehler 1
make[2]: Verzeichnis »/home/kim/cpuminer-opt-3.1.17« wird verlassen
make[1]: *** [all-recursive] Fehler 1
make[1]: Verzeichnis »/home/kim/cpuminer-opt-3.1.17« wird verlassen
make: *** [all] Fehler 2
kim@spiel-2:~/cpuminer-opt-3.1.17$
That's a coding error. I just recompiled successfuly from the tarball I uploaded so don't know why you got that error. |
|
|
|
I tried:
... :~/cpuminer-opt-3.1.17$ ./configure CFLAGS="-O3 -march=btver1" --with-curl --with-crypto && make
"configure" o.k., "make" completly failed
Console? |
|
|
|
Is there a mac os version?
Can I compile this on mac os, if yes, how?
Sorry, Linux only. |
|
|
|
here my output, ubuntu 14.04, will try your next version
.... :~$ gcc -march=native -Q --help=target | fgrep march
-march= amdfam10
Thanks. Did you use build.sh or enter the commands individually? Could you also try "-march=btver1", it worked for another user with, IIRC, a similar CPU. I think maybe amdfam10 isn't being seen as SSE2 capable. If that is the case it is outside the scope of the application and appears to be a compiler issue. The change to disable the SSE2 build check in v3.1.17 will become permanent and a workaround will be documented for AMD CPUs recommending "-march=btver1". |
|
|
|
|
A number of users have reported problems with AMD CPUS that don't have AES_NI but do
have SSE2.
Problems include compile failures and error exits on startup due to a perceived lack of support
for SSE2.
Solving this problem would go quicker with better info from the users when reporting problems.
This applies to any problem, not just the current AMD issues. As a result here are some tips for
problem reporting.
Give some info about your environment, CPU, OS, etc.
In addition to a description of the problem show the problem. Post the console session where the problem occurred
showing the command entered and the output produced.
Is it a new problem, ie did it work before?
Have you deviated from the recommended or previously used procedure or is there any change in the environment?
Have you tried to solve or workaround the problem yourself? How?
Provide info specific to the problem. In this case run the folllowing command and post the output:
gcc -march=native -Q --help=target | fgrep march
|
|
|
|
Tried it out to delete the sourcecode line, then "SW built for SSE2..........NO." change to "YES", but the miner stops working immediately; tried also several -march versions
More info please. What exactly did you change? I didn't suggest changing no to yes. What does stopped working mean? Did it compile?, did it crash? did it exit cleanly? |
|
|
|
What this message is supposed to mean is although the CPU supports SSE2 it wasn't compiled in.
This should only occur is if you specify an arch that doesn't support SSE2. Which arch did you use?
Same as always: ./autogen.sh && ./configure CFLAGS="-O3 -march=btver1" --with-curl --with-crypto && make I am 100% sure that btver1 includes SSE2 It looks like AMD is going to be a challenge. As AMD users I'll leave it up to you guys to figure out the workarounds
for -march for various CPUs. I can then add notes to the README
The same commandline worked for AMD since cpuminer-opt-3.1.9 and now does'nt on cpuminer-opt-3.1.16. Last version it worked was cpuminer-opt-3.1.15, so something is changed between them. Also the compile output messages is really small, even in Intel CPU in cpuminer-opt-3.1.16. I suspect the SSE2 SW check isn't working. Did you try to override it? If it works with the override I'll remove the check permanently. Edit: The override should work because the compile succeeded. If the compiler was truly compiling a non-SSE2 arch it would have failed on the SSE2 instructions. It would seem the __SSE2__ compiler macro is unreliable. I may remove the check completely or make it non-fatal. |
|
|
|
May I propose a different approach for much faster mining? Currently, most, if not all of CPU-mineable coins, are cripple-mined.The reason is simple: Under-utilizing of the SIMD nature of SSE & AVX sets. SSE and AVX commands are used in SISD fashion (single instruction single data, instead of Multiple data / SIMD), meaning they are not processing 2 batches of information but one. Right now hashing goes on like that: The main mining routine sends one output to each hash, where it will be subject to a process of SERIAL transmutations / permutation and in the end the hash will output that data back to the miner (some times to send it to the next hash). This serial process doesn't allow for much Single Instruction Multiple Data utilization. What should be done instead is that the miner program should issue 2-4 hash candidates to the hashing routines. The hashing routines should be able to get 2-4 inputs (instead of 1) and return back 2-4 outputs. In this way the process would be paralleled and SIMD utilization (packed processing of similar instructions) would result in much faster processing. Now this might require a lot of recoding, or, one could adjust the code in C for use with a special compiler which runs multiple instances of serial data crunching in order to process them in "packs" with SIMD or "packed" instructions - and then let the compiler do all the packing. Performance benefits of such an approach here: http://ispc.github.io/perf.htmlThat's a fascinating idea but I don't think it will get the visibility here that it deserves. Pooler and TPruvot are the two main guys for CPU mining although TPruvot is focussed more on other projects at the moment. Both have active threads in this forum. I suggest you present your idea to them in case they, or their folllowers, may want to take on the challenge. It's beyond my skill level. It's ok, don't worry. Some people reading this thread will know what to do with it. I'm not in altcoin mining really as I don't have the hardware and I'm not in the mood of renting. Obviously there's a lot of money here for optimized miners that are doing multiple hashrates than the ordinary ones. But this idea also extends to scaling of bitcoin and altcoins for things like cryptographic verification etc. They are using serial functionality when it could be done in packs of 2 or 4 (or 8 in something like ...AVX3-4-5 - or AVX512 which already exists). Going after the algos would be daunting as each code segment would have to be analyzed individually. Modifying the scanning engine to process two, or more, nonces in parallel might give bigger gains at lower effort. How does ccminer do it in cuda? |
|
|
|
********** cpuminer-opt 3.1.16 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI extension.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
Forked from TPruvot's cpuminer-multi with credits
to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
Wolf0 and Jeff Garzik.
Checking CPU capatibility...
AMD Phenom(tm) II X4 940 Processor
CPU arch supports AES_NI...NO.
CPU arch supports SSE2.....YES.
SW built for SSE2..........NO.
Incompatible SW build, rebuild with "-march=native" Why? What this message is supposed to mean is although the CPU supports SSE2 it wasn't compiled in. This should only occur is if you specify an arch that doesn't support SSE2. Which arch did you use? You can override the error by commenting out the exit statement below and recpompiling. Note cpuminer may crash with the override if the message was correct. cpu-miner.c function check_cpu_capability line#2700 // make sure CPU has at least SSE2
printf(" CPU arch supports SSE2.....");
if ( cpu_has_sse2 )
{
printf("%s\n", grn_yes );
printf(" SW built for SSE2..........");
if ( sw_has_sse2 && !sw_has_aes )
{
printf("%s\n", grn_yes );
printf_mine_without_aes();
}
else
{
printf("%s\n", ylw_no );
printf_bad_build();
exit(1); <-------- delete or comment this line
It looks like AMD is going to be a challenge. As AMD users I'll leave it up to you guys to figure out the workarounds for -march for various CPUs. I can then add notes to the README |
|
|
|
May I propose a different approach for much faster mining? Currently, most, if not all of CPU-mineable coins, are cripple-mined.The reason is simple: Under-utilizing of the SIMD nature of SSE & AVX sets. SSE and AVX commands are used in SISD fashion (single instruction single data, instead of Multiple data / SIMD), meaning they are not processing 2 batches of information but one. Right now hashing goes on like that: The main mining routine sends one output to each hash, where it will be subject to a process of SERIAL transmutations / permutation and in the end the hash will output that data back to the miner (some times to send it to the next hash). This serial process doesn't allow for much Single Instruction Multiple Data utilization. What should be done instead is that the miner program should issue 2-4 hash candidates to the hashing routines. The hashing routines should be able to get 2-4 inputs (instead of 1) and return back 2-4 outputs. In this way the process would be paralleled and SIMD utilization (packed processing of similar instructions) would result in much faster processing. Now this might require a lot of recoding, or, one could adjust the code in C for use with a special compiler which runs multiple instances of serial data crunching in order to process them in "packs" with SIMD or "packed" instructions - and then let the compiler do all the packing. Performance benefits of such an approach here: http://ispc.github.io/perf.htmlThat's a fascinating idea but I don't think it will get the visibility here that it deserves. Pooler and TPruvot are the two main guys for CPU mining although TPruvot is focussed more on other projects at the moment. Both have active threads in this forum. I suggest you present your idea to them in case they, or their folllowers, may want to take on the challenge. It's beyond my skill level. |
|
|
|
Hello,
Has anyone noticed a payout problem these past few days? I haven't gotten any payout for DASH.
The pool does not mine DASH. I'm not sure about that. When a payout coin is in short supply it shows up red in the pool display. DASH is often in short supply because it it not mined very much. There were payout delays in BTC yesterday as well so it might be related. Always choose your payout coin carefully, BTC makes the most sense. If you want a payout in a specific altcoin you're better off mining that coin directly without auto exchange. |
|
|
|
Can you run this command on your AMD processors and show me the output? gcc -march=native -Q --help=target | fgrep march
Here you are: root@beast:~$ gcc -march=native -Q --help=target | fgrep march
-march= amdfam10 Then your build should have worked out of the box, with -march=native. amdfam10 doesn't have AES support and gcc won't define __AES__ macro. Can you try building it with -march=native again? This curious. I presume that shows which arch is used by native.
On my skylake I get core2-avx core-avx2 and on my haswell sandy bridge I get corei7-avx.
configure fails with -march=skylake on my skylake.
Yes, this shows which arch gcc use for -march=native. In your case skylake is too new for gcc, your gcc 4.8.4 doesn't know about it, it should choose the closest match with most features enabled. There's no 'core2-avx' in GCC 4.8.4 manual, maybe you meant 'core-avx2'? core-avx2 defines __AES__ automatically. https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/i386-and-x86-64-Options.htmlHmage, you're a good teacher and you know your stuff, I'm learning a lot. Core-avx2 correction noted. |
|
|
|
Hello everyone,
Well, I certainly missed the boat :'D just learned about bitcoin mining... let's say I was busy learning about other non-profitable stuff, lol!
I have free electricity, and have some few grands to spare on some online-based trade... I love the idea of cryptocurrencies and mining, and being a security and networking specialist I'm already thinking of turning my home-lab into a mining farm x'D
Anyway, now to the questions:
* Would it be a good idea to start mining in some altcoins?
* if yes, can you share an advice for a beginner (which HWs to buy? which SWs and wallets to use?... I already have few computers at home, would they be of any good if I installed good GPUs in them? I even have few HP Gen5 and 6 servers with dual Xeon CUPs).
Thank you all!
Cheers
Val
Start with what you have. Some coins favour CPU mining, others GPU and some ASIC, search around the forum for them. See my sig for CPU mining software. If you're a gamer you can mine with your GPUs or you can buy some. Again search around the forum to get an idea about what GPUs and software to use. If you like the taste you can invest more. |
|
|
|
Can you run this command on your AMD processors and show me the output? gcc -march=native -Q --help=target | fgrep march
Here you are: root@beast:~$ gcc -march=native -Q --help=target | fgrep march
-march= amdfam10 This curious. I presume that shows which arch is used by native. On my skylake I get core2-avx and on my haswell sandy bridge I get corei7-avx. configure fails with -march=skylake on my skylake. Yeah! This got me curious and do some tests too.  Intel Core i7-4790K CPU @ 4.40GHz root@storm:~$ gcc -march=native -Q --help=target | fgrep march
-march= core-avx2 AMD Sempron 145 root@wolverine:~$ gcc -march=native -Q --help=target | fgrep march
-march= amdfam10 Correction, my sandy bridge shows corei7-avx. |
|
|
|
windows support?
No time soon. |
|
|
|
Can you run this command on your AMD processors and show me the output? gcc -march=native -Q --help=target | fgrep march
Here you are: root@beast:~$ gcc -march=native -Q --help=target | fgrep march
-march= amdfam10 This curious. I presume that shows which arch is used by native. On my skylake I get core2-avx and on my haswell I get corei7-avx. configure fails with -march=skylake on my skylake. |
|
|
|
Please try with ./configure CFLAGS="-O3 -march=btver1" --with-curl --with-crypto Build successful on both AMD CPU's without -DNO_AES_NI So, what was the setup that was giving the errors? If it works with and without NO_AES_NI? What was the version of gcc? I don't understand your question. If you mean my request above to test it was just to confirm it works on real non-aes HW, which I don't have. If you are referring to the compile problems in 3.1.14 it was because of a misunderstanding on the maning of __AES__. If you're referring to you problems with -march=native I have no idea. gcc v4.8.4 Did any of these answer your question? |
|
|
|
|
Show Posts
