I'm using precompiled windows binaries with a Ryzen 7 1700, trying to mine Verium. My bat file starts with cpuminer-aes-avx2 -a scrypt:1048576 -o stratum+tcp://eu2.poolinat0r.com:7103 However, it only uses SSE 2 as far as I can see.  What am I doing wrong? Where can I download precompiled binaries optimized for ryzen? Thanks. because the algo supports only sse2 Oh, I see. Is this the correct algo, then? I'm asking because my old Xeon E5645 with v3.4.6. gives me almost double H/s per core than my Ryzen 1700, so I guess something is wrong. Yes, thats the correct algo from what i remember. And the speed might depend on instruction implementation in the processor, hyperthreading, core speed and cache size. I don't know how much the specific algo benefit from each of those, but it might be logical On some algos i get higher hash rate on core i7-6700@3.4GHz probably due to HT and larger cache, while some are faster on core i5-7600@4.5Ghz due to higher clock The Windows binaries are pretty bad on AMD, not so great on Intel either. You'll need Linux and compile your own to get the best performance on any platform. As far as scrypt algo goes, I haven't paid much attention to it due to the existance of scrypt ASICs. However the verium version uses a different N factor that can't be mined with the scrypt ASIC. The implementation in cpuminer-opt was taken from Pooler and I haven't (intentionally) changed it. You could try his version to see if it gives better performance. I think cpuminer-multi also uses the same version. Their Windows binaries might be better. |
|
|
|
Hey guys so Im trying to run the miner but with every cpuminer sse aes sse42 etc etc. It crashes after a few seconds says cpuminer is not responding and closes my .bat file like it froze does anyone know what I can do to fix this?
Also I'm trying to mine using an old acer desktop with windows 10 and AMD cempron 145 processor 2.80 ghz if that info helps?
Thank you
Legacy version 3.5.9.1 May provide better performance on some algos with older CPUs that
don't have AES NI. Most users should not use it.
Your cpu doesn't support AES, so try the legacy version Thanks for pitching in helping new users. Your close this time but not quite correct. The legacy version doesn't help with incompatible CPUs, it just provides a little better performance on compatible non-AES CPUs. The real problem is described in the errrata section in the OP but was not included in the README.txt included with the Windows binary package. It will be added in the next release. Here it is: AMD CPUs older than Piledriver, including Athlon x2 and Phenom II x4, are not
supported by cpuminer-opt due to an incompatible implementation of SSE2 on
these CPUs. Some algos may crash the miner with an invalid instruction.
Users are recommended to use an unoptimized miner such as cpuminer-multi.
Also it's a Sempron which, like Intel's Celeron, has fewer features than the high end CPUs of the same vintage. The bottom line is the CPU is not compatible with cpuminer-opt. |
|
|
|
A pull request has been received to change the dockerfile. There are 2 changes, one to address an issue with line continuation, but also a change that claims to reduce the image size. Since I know very little about docker I defer to the community for review of the change. If there are any concerns with the change, please raise them. If there are no objections the changes will be included in the next release. https://github.com/JayDDee/cpuminer-opt/pull/41LGTM Then it's good enough for me. It will be included in the next release but might be merged in git before then as there are no immediate plans for a new release. |
|
|
|
I just tried compiling but got the error In file included from algo/echo/aes_ni/hash.c:21:0:
algo/echo/aes_ni/vperm.h:53:7: note: called from here
x = _mm_shuffle_epi8(*((__m128i*)table + 0), x);\
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
algo/echo/aes_ni/hash.c:385:4: note: in expansion of macro 'TRANSFORM'
TRANSFORM(_state[i][j], _k_opt, t1, t2);
^~~~~~~~~
In file included from algo/echo/aes_ni/vperm.h:20:0,
from algo/echo/aes_ni/hash.c:21:
/usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/include/tmmintrin.h:136:1: error: inlining failed in call to always_inline '_mm_shuffle_epi8': target specific option mismatch
_mm_shuffle_epi8 (__m128i __X, __m128i __Y)
^~~~~~~~~~~~~~~~
In file included from algo/echo/aes_ni/hash.c:21:0:
algo/echo/aes_ni/vperm.h:52:5: note: called from here
t1 = _mm_shuffle_epi8(*((__m128i*)table + 1), t1);\
algo/echo/aes_ni/hash.c:385:4: note: in expansion of macro 'TRANSFORM'
TRANSFORM(_state[i][j], _k_opt, t1, t2);
^~~~~~~~~
source='algo/hodl/aes.c' object='algo/hodl/cpuminer-aes.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -Iyes/include -Iyes/include -fno-strict-aliasing -I. -Iyes/include -Iyes/include -Wno-pointer-sign -Wno-pointer-to-int-cast -g -O2 -Iyes/include -Iyes/include -c -o algo/hodl/cpuminer-aes.o `test -f 'algo/hodl/aes.c' || echo './'`algo/hodl/aes.c
make[2]: *** [Makefile:2491: algo/echo/aes_ni/cpuminer-hash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/cpuminer-opt'
make[1]: *** [Makefile:3506: all-recursive] Error 1
make[1]: Leaving directory '/cpuminer-opt'
make: *** [Makefile:665: all] Error 2
This could be CPU related, especially if it's an AMD, and even worse an old AMD. I have found that many strange compile errors with SIMD intrinsics are due to architecture issues where the intrinsic isn't recognized as such and gets "implicitly declared" at compile time assuming type int instead of __m128i. After that any reference to the intrinsic causes the compiler to spit out strange error messages. You can confirm this is you find previous implicit declaration warnings related to SIMD intrinsic functions. |
|
|
|
Hello guys. I am a domestic miner and I live in Brazil - Rio de Janeiro. My English is not very good. Congratulations Mr. Joblo for the excellent work with the multi-algorithm mining. I am a GNU / Linux Debian user. cpuminer-opt works perfectly on Debian and I'm very satisfied. I recently bought a PC with the AMD Ryzen 7 1700 processor. I intend to do some testing on Windows 10. I would like an orientation. There are 5 executable files in the Windows binary package. To perform the XMR mining and not underutilize the performance of my AMD Ryzen should I test each of the executables and check the performance or would one of you recommend me a specific executable? I thank you all.
You answered your own question, use the fastest one that doesn't crash. In the case of Ryzen it should be AES-AVX2. However, none of the builds can take advantage of SHA acceleration on supported algos, you need to compile on Linux to get that. |
|
|
|
A pull request has been received to change the dockerfile. There are 2 changes, one to address an issue with line continuation, but also a change that claims to reduce the image size. Since I know very little about docker I defer to the community for review of the change. If there are any concerns with the change, please raise them. If there are no objections the changes will be included in the next release. https://github.com/JayDDee/cpuminer-opt/pull/41 |
|
|
|
Guys im having a tough time getting this to run with my Nvidia Tesla 2090, can anyone help please. downloaded the Cuda 8 version off git and this is error I am getting.....
[2017-11-07 20:02:04] Starting on stratum+tcp://yiimp.eu:3737
[2017-11-07 20:02:04] NVML GPU monitoring enabled.
[2017-11-07 20:02:04] 1 miner thread started, using 'x17' algorithm.
[2017-11-07 20:02:20] Stratum difficulty set to 0.016
[2017-11-07 20:02:20] x17 block 1630213, diff 1136.048
[2017-11-07 20:02:20] GPU #0: Intensity set to 20, 1048576 cuda threads
[2017-11-07 20:02:20] GPU #0: aes_cpu_init invalid device symbol
[2017-11-07 20:02:21] GPU #0: aes_cpu_init invalid device symbol
Cuda error in func 'x13_hamsi512_cpu_init' at line 685 : invalid device symbol.
I also changed the MakeFile.am to match the correct compatibility which should be nvcc_ARCH = -gencode=arch=compute_20,code="sm_20,compute_20"
thanks for any help
This model is no longer listed in the nVidia CUDA compute list - https://developer.nvidia.com/cuda-gpus/It's listed on the legacy page as compute 2.0. https://developer.nvidia.com/cuda-legacy-gpusSince it's not the compute version perhaps it's the drivers or the cuda version. As a legacy product it's probably no longer supported in the latest drivers and cuda. You need to go back in time with all the SW. |
|
|
|
replace march=native by march=core2 in configure.sh then use ./build.sh
That seems to be the most generic I've found. |
|
|
|
Should I put into Makefile.am as well? That will just makes it worse. What you want is a generic build but, straight from gcc... There is no -march=generic option because -march indicates the instruction set the compiler can use,
and there is no generic instruction set applicable to all processors.There is just too much that is different between AMD and Intel processors. Edit: If you're only compiling for that one PC you can specify -march for that CPU. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.htmlEdit2: It might also be useful to mention what CPUs are inolved. If the AMD newer than Piledriver -march-core2 should work. I have had no success with Piledriver and older. |
|
|
|
It wasn't a botnet and it wasn't 2000 miners, it was 1000 ( they were mine). The pool just disconnects them so often that it gets the count wrong. I also crashed the pool frequently with only 1000 machines, which is pretty bad. If the author wants to make his source public, I'll host an additional pool myself to take load away (I host other pools)
You should use a proxy and pool admin should limit the number of workers with the same address. |
|
|
|
One thing I have found is that neoscrypt fails to initialize in the version i have compiled (both avx2 and sha)
Benchmark is broken for neoscrypt but pool mining works. Benchmark is broken for a few algos and I don't really care to try to fix them. all the algos in the table i posted benchmark fine with your version, but in this case, it actually breaks completely, even with real pools p.s. can you enable the api to report the hashrate before the 1st accepted share? I can't do much if it's only your cross compile that's failing. The hash rate is only meaningful when a share is submitted. Reporting the per-thread hash rate on every scan would increase the traffic. |
|
|
|
One thing I have found is that neoscrypt fails to initialize in the version i have compiled (both avx2 and sha)
Benchmark is broken for neoscrypt but pool mining works. Benchmark is broken for a few algos and I don't really care to try to fix them. |
|
|
|
Good to read you got it working. You should check that the compiled SW features match your CPU architecture for best
performance. It should already, because it was compiled in the real machine, or it should not? edit: in you opening post there are some minor typos here? (CLAGS is CFLAGS? obvious for an advanced user but deadly for a novice if it's the case, I'm the second type) Users with openssl 1.0.1 (Ubuntu 14.04) may get better perforance by adding "-DUSE_SPH_SHA" to CLAGS.Thanks for pointing out the typo, fixed. I don't expect too many newbies to be using old distros. You could consider the error a competency test, if you can't find the error you shouldn't be trying to customize the compile. You passed.  The Virtualbox emulated CPU may not have the same architecture as the host and may be missing some newer features, particularly with older versions of Virtualbox. On the other hand the old CPUs are not likely to have them either. It's just something else to watch for. |
|
|
|
Can I use cpuminer-opt for LAN mining?
How should it be configured
thank you for your help!
I don't understand the question. If you mean solo mining connecting to the wallet instead of a pool, then yes it should work. But be sure to include htttp:// in the URL because it will default to stratum otherwise. |
|
|
|
Yescryptr16 is fixed in cpuminer-opt-3.7.2, follow the link in my sig.
Nice!  Thanks for testing and reporting your results. |
|
|
|
Yescryptr16 is fixed in cpuminer-opt-3.7.2, follow the link in my sig.
Nope, link is still to old miner Links have been corrected to point to 3.7.2. |
|
|
|
yescryptR16 algorithm support is not perfect
There will be an error
[2017-11-01 23:32:09] CPU #7: 448 H, 39.64 H/s
[2017-11-01 23:32:09] CPU #19: 430 H, 38.08 H/s
[2017-11-01 23:32:09] CPU #16: 491 H, 43.42 H/s
[2017-11-01 23:32:09] CPU #0: 490 H, 43.32 H/s
[2017-11-01 23:32:10] Stratum connection failed: Failed to connect to pool.bilbotel.fr port 6234: Connection refused
[2017-11-01 23:32:10] ...retry after 10 seconds
[2017-11-01 23:32:21] Stratum difficulty set to 1
That is a pool issue, likely overload as discussed in the yenten thread. |
|
|
|
Thanks for fix, you still have old link though so we cant actually download this fixed miner
Links have been updated. Pleas delete the bad links from your post. |
|
|
|
矿池为啥连不上，一直出错
你使用什么软件挖矿？ 是不是cpuminer-opt-3.7.1-windows 我怎么老连不上，即使连上了，也是拒绝，无效块。 CPU: Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz CPU features: SSE2 AES AVX SW built on Oct 31 2017 with GCC 4.8.3 SW features: SSE2 AES AVX Algo features: SSE2 SHA Start mining with SSE2 [2017-11-01 19:40:13] Starting Stratum on stratum+tcp://pool.bilbotel.fr:6234 [2017-11-01 19:40:13] 20 miner threads started, using 'yescryptr16' algorithm. [2017-11-01 19:40:15] Stratum difficulty set to 1 [2017-11-01 19:40:15] yescryptr16 block 2638, diff 0.014 [2017-11-01 19:40:26] CPU #11: 1387 H, 131.51 H/s [2017-11-01 19:40:26] Rejected 1/1 (100.0%), 1387 H, 131.51 H/s[2017-11-01 19:40:26] reject reason: Invalid share [2017-11-01 19:40:34] CPU #10: 2388 H, 131.64 H/s [2017-11-01 19:40:34] Rejected 2/2 (100.0%), 3775 H, 263.15 H/s[2017-11-01 19:40:34] reject reason: Invalid share use original yenten_miner dont use another miner softwalre cos dont work for now.. Yescryptr16 is fixed in cpuminer-opt-3.7.2, follow the link in my sig. |
|
|
|
Will lyra2z330 gain benefit from thoese ssl/sha optimizations, too? Another update, sorry for the spam.
Managed to install devtoolset-6 (GCC 6.3.1), it was quite straightforward:
... cut ... You're trying to compile for a CPU archietcture simulated by Virtualbox. Even if the compile was successful it wouldn't work properly on real hardware. I do not support attempts to cross compile on Linux. You're on your own. FYI, with the help of a sysadmin, I got it to work (well, he did, most of it, and I ignore the details), so this miner is now running on Centos 6.9 and real hardware. Good to read you got it working. You should check that the compiled SW features match your CPU architecture for best performance. |
|
|
|
|
Show Posts
