cpuminer-opt-3.7.2 is released. Fixed yescryptr16. Changed default sha256 and sha512 to openssl. This should be used when compiling with openssl 1.0.2 or higher (Ubuntu 16.04). This should increase the hashrate for m7m, xevan, skein, myr-gr & others when openssl 1.0.2 is installed. This is due to AVX and AVX2 optimizations added to openssl 1.0.2. Users with openssl 1.0.1 (Ubuntu 14.04) may get better performance by adding "-DUSE_SPH_SHA" to CFLAGS. When using sph_sha or openssl-1.0.1 the miner will still display AVX and AVX2 mining even though neither sph_sha nor openssl-1.0.1 have those optimizations. Windows binaries are compiled with -DUSE_SPH_SHA and won't get the speedup. git: https://github.com/JayDDee/cpuminer-opttarball: https://drive.google.com/file/d/0B0lVSGQYLJIZamNFVnZGT1FFT1k/view?usp=sharingWindows binaries: https://drive.google.com/file/d/0B0lVSGQYLJIZMXl6SWtmUE4yTm8/view?usp=sharingThanks to all who helped testing SHA, particularly 4ward who discovered performance on Intel CPUs had improved in openssl 1.0.2. Edit: Links updated for 3.7.2 |
|
|
|
Win 10 Pro 64 bit
OpenSSL 1.1.0f 25 May 2017
cpuminer-opt-3.7.1-myNativ --algo=m7m --benchmark -q
********** cpuminer-opt 3.7.1 ***********
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: AMD Ryzen 7 1800X Eight-Core Processor
CPU features: SSE2 AES AVX AVX2 SHA
SW built on Nov 1 2017 with GCC 6.3.0
SW features: SSE2 AES AVX AVX2 SHA
Algo features: SSE2 AES AVX SHA
Start mining with SSE2 AES AVX SHA
[2017-11-01 12:22:52] 16 miner threads started, using 'm7m' algorithm.
[2017-11-01 12:22:59] Total: 262.14 kH, 38.54 kH/s
[2017-11-01 12:23:04] Total: 1840.97 kH, 293.92 kH/s
[2017-11-01 12:23:09] Total: 1469.23 kH, 291.32 kH/s
[2017-11-01 12:23:14] Total: 1454.33 kH, 289.60 kH/s
[2017-11-01 12:23:19] Total: 1423.37 kH, 289.73 kH/s
[2017-11-01 12:23:24] Total: 1421.89 kH, 287.81 kH/s
[2017-11-01 12:23:29] Total: 1365.32 kH, 287.75 kH/s
[2017-11-01 12:23:34] Total: 1366.31 kH, 289.06 kH/s
[2017-11-01 12:23:39] Total: 1440.71 kH, 287.66 kH/s
Win 10 Pro 64 bit
OpenSSL 1.0.2k
cpuminer-opt-3.7.1-myNativ --algo=m7m --benchmark -q
********** cpuminer-opt 3.7.1 ***********
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: AMD Ryzen 7 1800X Eight-Core Processor
CPU features: SSE2 AES AVX AVX2 SHA
SW built on Nov 1 2017 with GCC 6.3.0
SW features: SSE2 AES AVX AVX2 SHA
Algo features: SSE2 AES AVX SHA
Start mining with SSE2 AES AVX SHA
[2017-11-01 12:21:35] 16 miner threads started, using 'm7m' algorithm.
[2017-11-01 12:21:44] Total: 655.36 kH, 71.29 kH/s
[2017-11-01 12:21:49] Total: 1096.32 kH, 205.92 kH/s
[2017-11-01 12:21:54] Total: 874.22 kH, 210.36 kH/s
[2017-11-01 12:21:59] Total: 769.22 kH, 211.97 kH/s
[2017-11-01 12:22:04] Total: 967.19 kH, 221.77 kH/s
[2017-11-01 12:22:09] Total: 1051.55 kH, 224.90 kH/s
[2017-11-01 12:22:14] Total: 1124.52 kH, 225.51 kH/s
[2017-11-01 12:22:19] Total: 1013.80 kH, 225.62 kH/s
[2017-11-01 12:22:24] Total: 1128.10 kH, 225.34 kH/s
[2017-11-01 12:22:29] Total: 1111.20 kH, 224.71 kH/s
Excellent. This shows the improvement due to SHA only and confirms that SHA is not available in openssl 1.0.2k. |
|
|
|
some results from benchmarking: some algos that show big improvement with openssl 1.1 sha compared to original avx2 build: lbry (19%) m7m (13%) myr-gr (20%) skein (15%) some algos cross-compiled with avx2 with newer openssl/gcc on ubuntu 17.04 groestl (13%) hodl (18%) whirlpoolx (18%) many others show 5+% improvement table with all algos i have benchmarked available here (benched on Core i5 7600k@4500 with -t 2 to prevent other processes interfering): https://docs.google.com/spreadsheets/d/19vC17i1QZCvxlWbmxQIP4VF9FSzPuwOYtk5jJSrH48I/edit?usp=sharingThanks for the testing. I was able to confirm that openssl 1.0.2 adds AVX and AVX2 to sha256 & sha512. This explains the improvement on Intel CPUs. Openssl 1.1 adds SHA support to sha256 further improving Ryzen performance. I can't confirm that SHA is available in any 1.0.2 releases of openssl. The previously reported Ryzen improvements on Ubuntu 16.04 were likely due to the AVX and AVX2 optimizations in openssl 1.0.2. The next release of cpuminer-opt will use openssl by default (not just for SHA). I will add a workaround for users with openssl 1.0.1 to use sph_sha256 and sph_sha512 which performs a little better than openssl 1.0.1. More details will be in the release announcement. In other news I have a fix for yescryptr16, new release should be available in a few hours. |
|
|
|
where can download the compiled version of cpuminer-opt v3.7.1 for Windows?
Yescryptr16 is broken in cpuminer-opt-3.7.1. Watch my thread for fix. In the meantime you can use yenten-minerd. |
|
|
|
Yescryptr16 seems to be producing rejects. Since the pool is finding blocks I assume the problem is in the miners. I will need to investigate. |
|
|
|
funny thing... after cross compiling sha version, it actually gives me about +10% on m7m with a skylake cpu...
Please clarify. Windows? What did you compare with, precompiled binaries? yes, on windows. cross-compile with avx2 or skylake show roughly the same speed as your avx2 version, but with znver1, gives me a boost on some algos. im still benchmarking them all so see the difference, but m7m gave me ~10% boost and im running on a skylake core i5 7600k If you're using a SHA build on a Skylake it will use the openssl implementation of sha256 but not the HW acceleration. With a normal compile it will use the included SPH implementation of sha256. My previous testing showed the SPH version to be faster that the SW openssl version. Perhaps newer versions of openssl have improved the SW implementation. IIRC you're using openssl 1.1. If you see differences in algos that don't use sha256 (SHA not listed in algo features) then there's something else happening. Edit: I did a test and can confirm about 10% improvement in m7m when compiled for SHA (openssl 1.0.2) and run on a Haswell. I need to do more testing. Edit2: slower with openssl 1.0.1, looks like openssl improved in 1.0.2, good catch. |
|
|
|
funny thing... after cross compiling sha version, it actually gives me about +10% on m7m with a skylake cpu...
Please clarify. Windows? What did you compare with, precompiled binaries? |
|
|
|
D:\cpuminer-opt-3.7.1-windows>cpuminer-aes-avx2.exe -a yescryptr16 -o localhost:rpcport -u user -p pass -t 16
Like I said you must specify http:// when solo mining. Compiling SHA for Windows is still a problem. It's possible to compile with msys2 but you have to know what you're doing. Still there are problems with the build, it crashes everytime there's a stratum error. |
|
|
|
Yes I use yescryptr16 and it's solo mining.
The only way I succeeded was but connecting a vpn... weird...
So now I can mine using the built-in miner or using minerd, I'm getting around 1100h/s but wanted to see the difference with yours as I always get better results with it!
Please post the info I requested. You shouldn't get stratum errors solo mining. |
|
|
|
Do you mean to say that SHA is now enabled in binaries? Or only for yescrypt and yescriptr16 or that it still needs to be compiled regardless? Also I am trying to mine Yenten but keep getting [2017-10-31 12:54:42] stratum_recv_line failed
[2017-10-31 12:54:42] ...retry after 10 seconds There is no SHA support in any binaries for any algos. The only way to get it is to compile yourself with a supported CPU, compiler, openssl, and algo. I'm not aware of any working pools but the error you see suggests a connection was made and then failed. Need more info including command line (minus sensitive data) and miner output. If there is a working pool I can do some testing myself. I see you also posted connection problems in the Yenten thread. That is likely the cause of your stratum errors, assuming you are trying to connect to an external address, ie a pool. Stratum is the default if you don't specify the protocol in the url. If you're mining the wallet you must specify -o http://<ipaddr>:<port> Also don't use -a yescrypt for yenten, that's the old yescrypt but was used as a quick and dirty hack in yenten-minerd. |
|
|
|
woaw which cpu is that? my i7 thread 0: 8852 hashes, 0.16 khash/s and cant solve any block .test pool or solo doesnt mather I just built this algo in to yiimp,
Please test it at stratum+tcp://vdiff.thecryptopool.com:6234 -u <YOUR WALLET> -p c=YTN
PLEASE NOTE THIS IS A BETA TEST ON THIS ALGO.
Ill be monitoring to see and may take the stratum offline if coins are failing.
Hi, I'm mining in your pool I am doing it right? [2017-10-29 16:50:35] Accepted 6/6 (100%), 61.04 kH, 2535.41 H/s [2017-10-29 16:50:38] CPU #0: 18.55 kH, 431.87 H/s [2017-10-29 16:50:39] Accepted 7/7 (100%), 71.09 kH, 2552.67 H/s [2017-10-29 16:50:52] CPU #4: 24.19 kH, 428.96 H/s [2017-10-29 16:50:52] CPU #5: 24.60 kH, 433.61 H/s [2017-10-29 16:50:53] CPU #5: 292 H, 437.10 H/s [2017-10-29 16:50:53] Accepted 8/8 (100%), 78.43 kH, 2605.53 H/s [2017-10-29 16:50:55] CPU #1: 26.12 kH, 439.24 H/s [2017-10-29 16:50:55] CPU #2: 26.09 kH, 437.50 H/s [2017-10-29 16:50:58] CPU #1: 1459 H, 438.24 H/s [2017-10-29 16:50:58] Accepted 9/9 (100%), 87.63 kH, 2611.17 H/s Hello Amd fx 8320e 8 cores I have not resolved blocks You won't, those are yescrypt shares. Yet another pool configured for yescrypt instead of yescryptr16. You also need to use a yescryptr16 miner. |
|
|
|
Another update, sorry for the spam. Managed to install devtoolset-6 (GCC 6.3.1), it was quite straightforward: sudo yum install centos-release-scl
sudo yum install devtoolset-6
scl enable devtoolset-6 bash The errors are always there, but at least they more detailed. They are all very similar, I'll paste just one: In file included from algo/echo/aes_ni/vperm.h:20:0,
from algo/echo/aes_ni/hash:21:
/opt/rh/devtoolset-6/root/usr/lib/gcc/x86_64-redhat-linux/6.3.1/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)
^~~~~~~~~~~~~~~~ Searching in and here found just this similar question: https://stackoverflow.com/questions/43128698/inlining-failed-in-call-to-always-inline-mm-mullo-epi32-target-specific-opti but not much idea how to proceed. 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. |
|
|
|
Not until there's a stratum pool where I can test. It looks like the same hash function with different parameters. |
|
|
|
yup, after linking with pthreadGC2 it works fine.
and it looks like it brings a very slight improve in performance (about 1% or so in a few algos that i benchmarked)
compiling sha version also works, too bad i don't have hardware to test it
Good to read you got it working but too bad no significant improvement. At my end I got it working using http://www.msys2.org/ but again no significant performance difference. Msys2 is pretty clumsy to setup, nice installer but it only installs a minimal base system. Then you use a clumsy package manager to install everything else. gcc 6.3 7.2 and openssl 1.0.2l are available. Compiling with SHA works but I couldn't verify due to lack of SHA CPU. It works fine from within Msys2 shell, getting it to work from a DOS shell required copying all the DLLs included in Mingw, over 40 of them. I don't like bundling DLLs, just delivering a Windows binary is scary enough. I was hoping there was a way to download just the DLLs from Msys2 but they are all hidden in individual package files. It seems the only way to get them is to install Msys2 and all the packages that provide the DLLs. |
|
|
|
I'm trying to compile the 3.7.0 on a Centos 6.9 vm on virtualbox to later copy it ont a real machine server running the same Centos 6.9, I don't even know if it makes sense, but I'm doing it to not install extra packages in the real server. After managing to bypass several errors and difficulties such as the #pragma error of gcc 4.4.7 by upgrading gcc (not so obvious), now I'm stuck with these: Does a fix exist for the errors above or alternatively does a precompiled version exist of cpuminer-opt-3.7.0 to run in a Centos 6.9 system with this processor: https://ark.intel.com/it/products/88173/Intel-Xeon-Processor-E3-1245-v5-8M-Cache-3_50-GHz ( SSE4.1/4.2, AVX2 )? Thank you in advance. Those real servers would need most of the same packages, it's probably not worth it. As for your compile error the first error is always the most important. From what you posted it looks like the Intel intrinsics aren't insrtalled. You may find earlier errors for missing immintrin.h or files with similar names. I don't know if they exist for Centos 6, it's very old, or what the package might be called. |
|
|
|
|
The only reason to use pi would be if you had a few dozen and the aggregated hash was more efficient
(cost & power) than using real CPUs.
There's a thread in this forum with a guy doing this with 150 ARMs, he calls it 600 cores, claims it's more
efficient for the algo he mines with.
|
|
|
|
i have tried all of the -march options you have in winbuild-allarch.sh, and it also compiles with -march=znver1 , bringing sha support to windows (if you can find the source of workio thread issue) hope you can take it from here and make it work  workio is just a message relay between the miner threads and the stratum thread. If it's broken there is something fundamentally wrong with the build. The only dependencies workio has are curl and pthreads. A curl error would have produced a different error message. I'm still suspicious it's pthreads related because the workio polling loop would break down if pthreads was broken causing it to exit and producing the error message you saw. Can you confirm how it was linked? You should see either -lpthreads or -lpthreadsGC2. For mingw it should be -lpthreadsGC2 which it probably is because it was compiled for a mingw host. I have no other ideas. -lpthread how can i fix that? It's controlled by configure.ac at line 111: # GC2 for GNU static
if test "x$OS" = "xWindows_NT" ; then
# MinGW
AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthreadGC2",[])
else
AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthread",[])
fi
It works as intended in the old MSYS environment but on cygwin linking fails because it can't find pthreadGC2. I can't get cygwin to use the mingw toolchain which includes pthreadGC2. I've tried using --host and --build with no luck. |
|
|
|
i have tried all of the -march options you have in winbuild-allarch.sh, and it also compiles with -march=znver1 , bringing sha support to windows (if you can find the source of workio thread issue) hope you can take it from here and make it work workio is just a message relay between the miner threads and the stratum thread. If it's broken there is something fundamentally wrong with the build. The only dependencies workio has are curl and pthreads. A curl error would have produced a different error message. I'm still suspicious it's pthreads related because the workio polling loop would break down if pthreads was broken causing it to exit and producing the error message you saw. Can you confirm how it was linked? You should see either -lpthreads or -lpthreadsGC2. For mingw it should be -lpthreadsGC2 which it probably is because it was compiled for a mingw host. I have no other ideas. |
|
|
|
Unfornutaly, this miner don't work with equihash algorithm (exept an error from my side ?) !
Do you know a good CPU miner for equihash ?
yes, it doesnt support equihash try nheqminer: https://github.com/nicehash/nheqminer/Ok, thank you for the reply. NHEQMiner have no update since 10 months... But I will try this last version (My last version was the first, a long time ago :-).). Most brand new algos leave little room for improvement as they were initially written for the latest technolgies, unlike the reshuffled sha3 chains like phi, tribus, hsr ... They often also have a completely different code structure that is very difficult to import into cpuminer. In other words all pain, no gain. |
|
|
|
|
Show Posts
