looks like there is a regression in 3.7.8:
4way lyra2z started throwing low difficulty shares error
Lyra2z 4way is a mess, that's why the warning is displayed on startup. First it is not expected to be fast, only a small portion of the algo (blake256) can be paralleled. The overhead of converting from 4way for blake256 to serial for lyra2 may be greater than the gain of blake256 4way. I'm using lyra2z as a test bed for blake256. 4way for the lyra2 code is not being seriously considered because it's already using AVX2. Blake256 has problems. Only 2 of the 4 lanes produce valid hash, the other 2 always invalid. In effect it is only working as 2way, when it works at all. I made a change in 3.7.8 but was unable to test it at the time. It seems it made things worse. I'm still working on it but there is no guarantee it will be fixed soon. Thanks for testing. I think I found the bug in lyra2z 4way, actually it's in blake256 4way. It looks like it's responsible for the lane corruption problem also. Unfortunately zpool dropped it before I could test it (yet again). |
|
|
|
Greetings, I am a user of Ubuntu 17.10 and my CPU is an i3 2100, after the last updates I could not use the program, chose to throw me the following error:
./cpuminer -a x11 --benchmark
********** cpuminer-opt 3.7.8 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX2 and SHA extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
CPU: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz.
SW built on Jan 4 2018 with GCC 6.4.0.
CPU features: SSE2 AVX.
SW features: SSE2 AVX.
Algo features: SSE2 AES AVX2 4WAY.
A CPU with AES and AVX2 is required!
I compile it using flag -march=native.
The only way to use it is to compile it from build-allarch.sh and using the executable cpuminer-sse42. Thanks in advance for any assistance.
It looks like there is a bug with some algos when using a CPU with AVX but not AVX2. Will be fixed in the next release. |
|
|
|
|
Nicehash sets the difficulty too high for cryptonight. It takes too long to find a share so the stratum
times out.
|
|
|
|
Hi Joblo! 3.7.8 avx-sha is better than ever! Im mining m7m algo, but I mine with both GPUs and Ryzen. The 16thread mining are slowing down the GPUs mining. How could I set CPU affinity for all threads but CPU0 (or threads 0 and 1)? I searched for an option to do it, but I havent found nothing  -t 14 --cpu-affinity 0xfffd should mine on logical cores 2 through 15 leaving cores 0 & 1 free. But I'm not sure threads 0 & 1 are mapped to the same physical core. You might have to play with the affinity mask to isolate 2 threads on the same physical core. Other possibilities include 0xfefe (threads 0 &  and 0xffee (threads 0 & 4). I can't think of any other way they could be mapped. Please let us know which one works. |
|
|
|
Hi there ! It's my first message as registered user, but I follow this project for months now  . I tried to (cross-)compile this project for windows 7 32bits version with no success. I guess you missed the requirements section in the OP which states a 64 bit CPU & OS are required. |
|
|
|
looks like there is a regression in 3.7.8:
4way lyra2z started throwing low difficulty shares error
Lyra2z 4way is a mess, that's why the warning is displayed on startup. First it is not expected to be fast, only a small portion of the algo (blake256) can be paralleled. The overhead of converting from 4way for blake256 to serial for lyra2 may be greater than the gain of blake256 4way. I'm using lyra2z as a test bed for blake256. 4way for the lyra2 code is not being seriously considered because it's already using AVX2. Blake256 has problems. Only 2 of the 4 lanes produce valid hash, the other 2 always invalid. In effect it is only working as 2way, when it works at all. I made a change in 3.7.8 but was unable to test it at the time. It seems it made things worse. I'm still working on it but there is no guarantee it will be fixed soon. Thanks for testing. |
|
|
|
That's very confusing. The output you posted for yescrypt is from the 4way build (avx2 but no sha). There is no
4way in the avx-sha build. I double checked the names just to make sure. They don't match those in README.txt
but that's only the the inclusion of aes in the name. The important features are correct.
The output I posted for yescrypt is from the avx-sha executable, not the avx2 executable. That's why I'm confused as well. That's really weird, I'm getting the same thing. I also getting lower hashrate with the 4way build. They were all built using the winbuild-cross.sh script that clearly shows the compile options and asociated file names. It looks like trial and error until I sort this out. More data points, now that m7m is back on ahashpool: cpuminer-4way-sha.exe getting around 590 kH/s cpuminer-avx-sha.exe getting around 565 kH/s cpuminer-aes-avx.exe getting around 575 kH/s cpuminer-aes-avx2.exe getting around 567 kH/s cpuminer-4way.exe getting around 543 kH/s cpuminer-sse2.exe getting around 550 kH/s cpuminer-sse42.exe getting around 540 kH/s cpuminer-aes-sse42.exe getting around 540 kH/s I found the problem. The avx-sha build is just a copy of the avx2 build. There was a "make clean" missing in the script so it didn't recompile for avx-sha and just reused the previous build. Your test results make more sense now. I'm rebuilding now and will upload a windows v2 build. Thanks for finding this. Regarding the planned name changes, I'm waiting because I intend to remove 4way as a seperate build if it's stable. The AVX2 builds will automatically have 4way enabled which will help reduce the number of targets I have to build. I'll finalize the naming afterward. |
|
|
|
That's very confusing. The output you posted for yescrypt is from the 4way build (avx2 but no sha). There is no
4way in the avx-sha build. I double checked the names just to make sure. They don't match those in README.txt
but that's only the the inclusion of aes in the name. The important features are correct.
The output I posted for yescrypt is from the avx-sha executable, not the avx2 executable. That's why I'm confused as well. That's really weird, I'm getting the same thing. I also getting lower hashrate with the 4way build. They were all built using the winbuild-cross.sh script that clearly shows the compile options and asociated file names. It looks like trial and error until I sort this out. |
|
|
|
Awesome! And I see official SHA support! Should also add that to the "what's new". I'm going to test avx-sha vs 4-way-sha on my Ryzen to see which is more quicker. And just for kicks, will compare to just straight avx. Thanks, and hope you have a happy new year! Update: Either it's reporting incorrectly, or there's other optimizations going on. Mining yescrypt:
********** cpuminer-opt 3.7.8 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI and AVX2 and SHA extensions.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
CPU: AMD Ryzen Threadripper 1950X 16-Core Processor .
SW built on Dec 30 2017 with GCC 5.3.1.
CPU features: SSE2 AES AVX AVX2 SHA.
SW features: SSE2 AES AVX AVX2 4WAY.
Algo features: SSE2 SHA.
Start mining with SSE2.
This is using avx-sha.exe - it doesn't list SHA in SW features. However, there is definitely an improvement in performance, though not really with yescrypt. Went from the previous avx-only EXE of 15.22 kH/s to now 15.32 kH/s, but within margin of error. However, xevan went from a 409.3 kH/s to 453.6 kK/s!!! What's interesting is that it lists 4WAY as a feature, which I thought wasn't a part of the avx-sha.exe build. Just to see if the avx-sha.exe build was any different than just avx only, I tried the closes avx-only build. With aes-avx.exe, I get about 14.9 kH/s for yescrypt and 413.8 kH/s for xevan. So definitely an improvement, but not on the algo I expected. Update 2: Also noticed some mismatched builds from Readme.txt. Actual builds: cpuminer-4way-sha.exe
cpuminer-4way.exe
cpuminer-aes-avx.exe
cpuminer-aes-avx2.exe
cpuminer-aes-sse42.exe
cpuminer-avx-sha.exe
cpuminer-sse2.exe
cpuminer-sse42.exe
From readme.txt" Exe name Compile flags Arch name
cpuminer-sse2.exe "-march=core2" Core2
cpuminer-sse42.exe "-march=corei7" Nehalem
cpuminer-aes-sse42.exe "-maes -msse4.2" Westmere
cpuminer-avx.exe "-march=corei7-avx" Sandybridge, Ivybridge
cpuminer-avx2.exe "-march=core-avx2" Haswell...
cpuminer-avx-sha "-march=corei7-avx -msha" Ryzen...
cpuminer-4way.exe "-march=core-avx2 -DFOUR_WAY" same as avx2
cpuminer-4way-sha.exe "-march=core-avx2 -msha -DFOUR_WAY" same as avx2-sha
Perhaps the names just needs to be matched up. That's very confusing. The output you posted for yescrypt is from the 4way build (avx2 but no sha). There is no 4way in the avx-sha build. I double checked the names just to make sure. They don't match those in README.txt but that's only the the inclusion of aes in the name. The important features are correct. |
|
|
|
It's my turm to ask fr help. I'm fine tuning the new Windows crposs compile environment and I'd like to remove one ugly workaround, editting configure.ac. This code should properly link pthreadGC2 when cross compiling: # 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
but the procedure requires the following edit: # 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="-lpthreadGC2",[])
fi suggesting the logic isn't working. Any suggestions to make the logic work? perhaps moving it to the case clause starting on line 45? That's kinda what I'm looking for but that tests $MINGW_TARGET and it returns Linux. What I really want to test is the host as specified by "--host=x86_64-w64-mingw32" but I can't figure out how. |
|
|
|
It's my turm to ask fr help. I'm fine tuning the new Windows crposs compile environment and I'd like to remove one ugly workaround, editting configure.ac. This code should properly link pthreadGC2 when cross compiling: # 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
but the procedure requires the following edit: # 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="-lpthreadGC2",[])
fi suggesting the logic isn't working. Any suggestions to make the logic work? |
|
|
|
Benchmark and getwork.
Both are provided as is. Getwork seems to work with most algos but is not guaranteed. I don't even know if the coin supports it. If you can find a miner that works I'll look into fixing it in cpuminer-opt. |
|
|
|
Btw, I've found an issue while testing...
i3-7350k @ 4.2 GHz, HT on, 8Gb RAM @ DDR4-2400 dual channels, WIN 10
The test below produces no output!
cpuminer-aes-avx -a lyra2z330 -t 4 --cpu-affinity 15
I got 100% load for all of 4 logical cpus, then it drops to 0% after 2 minutes, and stays there. Miner does not log any hashrate, and dooes not crash either. It reproduces stable - 10 out of 10 tests.
AVX2 build works okay with same settings.
Benchmark or pool? |
|
|
|
Dump the battery and run with charger, set a fan up to cool your phones, dump 20-30 of them in an mineral oil tank to cool them, take the plastic shell off to help with cooling etc etc. Like I said "if you know what you're doing".
That is no longer mobile nor a phone. The only time I'd consider mining with a phone is if I was stranded in a broken down car in a blizzard and it was my only source of heat. |
|
|
|
I would like to drop the sse42 (Nehalem) build. Nehalem users would be forced to use the sse2 build.
There is no sse42 targetted code in any algos that I'm aware of so there should be no difference in
performance. Please report if you have data that shows otherwise.
Some results for: Pentium G4600 @ stock, DDR4-2400@ dual channel, Win 10, stock 3.7.7 binaries from github. This CPU is not old, but lacks AVX/AVX2. System was clean and idle. I've used benchmark option: cpuminer-* -a * -t 4 --cpu-affinity 15 --benchmark for all algos. So, the ones where the difference is: yescryptr16 - ~498.5 H/s SSE2, ~512 H/s SSE42 skunk - ~285 kH/s SSE2, ~295 kH/s SSE42 nist5 - ~450 kH/s SSE42, ~460 kH/s SSE2 (ooops) I've retested these suspicious results 5 times each, but it seems to be not a mistake. Btw, the difference is less than minor. Maybe OS uses some of these (sse2/sse42) in the background, so this gives minor speed changes. I don't know. Disassembly may help to see if there are actual changes in binaries for these algos, or not. Your CPU has AES so you should use the aes-sse42 build. The issue really only applies to Nehalem and any possibly similar AMD architecture. I found a small difference in the yescrypt code but your results differ less than skunk which has identical code. |
|
|
|
Hey guys, first time trying CPU mining with my 3570k and i have weird problems. I downloaded CPU miner 3.7.7 and I followed these instructions
Make a shortcut or .bat file and use this command line, replace the [] with your own values :
[PATH_TO_CPU_MINER]\cpuminer-aes-avx2.exe -a lyra2z -o stratum+tcp://europe.lyra2z-hub.miningpoolhub.com:17025 -u [MPH_USERNAME].[WORKER] -p [PASSWORD]
The thing is i cant even manage to open the window,even when i try to open avx2.exe nothing happens. Do i miss something? I tried to create a bat file inside this folder too,made the path and all the adresses and still i cant make this work at all. Any suggestions?
Use avx not avx2 for your Ivybridge CPU. As previously mentioned you can always see the error by bypassing the bat file and typing the command at a comand prompt. |
|
|
|
|
Another note to Ryzen users with Linux. I found a note that Linux kernel 4.10 added Ryzen support.
I don't know precisely what that means but if performance isn't what you expected check the kernel
version. Linux 4.10 was included in Ubuntu 17.04 and Fedora 26.
|
|
|
|
|
This is a reminder to Windows binaries users. I intend to make some changes in the next release
to reduce the number of binaries I have to build each release.
I would like to drop the sse42 (Nehalem) build. Nehalem users would be forced to use the sse2 build.
There is no sse42 targetted code in any algos that I'm aware of so there should be no difference in
performance. Please report if you have data that shows otherwise.
AVX2 performance on Ryzen is still questionable. It was suggested I provide a avx-sha build. I will provide
either a avx-sha or avx2-sha build. This will not apply to 4way as it requires AVX2. Ryzen users please
test avx vs avx2 (not 4way) to determine which gets the best performance. The best algo to test AVX2
is lyra2rev2 as it has the most AVX2 code.
|
|
|
|
|
If L2 cache is the same size as L3 there would be no use for L3.
Ryzen has 2 MB L2 per 4 core CCX, or 512 kB per core.
|
|
|
|
|
Show Posts
