|
I get a kick when people discuss two different things without realizing it.
VM in the OP is Virtual Machine not Virtual Memory.
CPU mining using a VM is possible but has limitations. Some advanced CPU features like AVX2
may not be supported in the VM even if presdent on the host CPU. It also makes little sense to
build a VM to mine with the CPU unless it is a different OS than the host and the SW isn't available
for the host OS.
GPU mining from a VM is not possible due to the lack of video driver support. Even if possible it
wouldn't make sense for the same reasons as for CPU mining.
|
|
|
|
That 3.6.3 version is not working with any algo on my i7 4770K.
I get 'The application was unable to start correctly (0xc000001d). Click OK to close the application.'
Windows? Linux? Command line? Windows 7, the same command line as previous versions, cpuminer-aes-avx2 -a deep -o stratum+tcp://yiimp.ccminer.org:3535 -u DMKs7ZFGFGTi7SG5CyTSJ1PTkQdHDdzdxE -p c=DEEP -t 6 It should work, try downloading a fresh copy. |
|
|
|
I've considered releasing the binaries that I compiled with the support for Ryzen.
Maybe you could share how you did it. I'm trying to upgrade my mingw setup with no luck. Can you run your build from a Windows command shell? |
|
|
|
hello when i try to running i get error Illegal instruction (core dumped)
i try to implement wolf answer to disable aes ni Configure with --disable-aes-ni but it seems cpuminer-opt dont have that option so my question are 1. How i solve this problem "Illegal instruction (core dumped)"? Or 2. How to disable aes ni in cpuminer-opt ? Thank you guys  If you're using the Windows binarires choose one that doesnt' have AES. If you're using Linux I need a lot more info. thank you for answer my question yes it work now, i try to install it on other computer out of curiosity why not use SSE4 or AVX-512m i think they are more new, and i think it will produce more good hash rate? i am sorry if sounds noob question, but really wonder to know Neither has any targetted code in cpuminer-opt. AVX512 is too new and there is little to be gained. As vectors get larger it becomes more difficult or impossible to implemement. Larger vectors also don't help with memory access which is the bottleneck on many CPU algos. |
|
|
|
The execution in the ubunto
./build.sh |
|
|
|
No I have not been able to figure out how to compile it myself, I used a pre-compiled version from a helpful person via youtube. https://www.youtube.com/watch?v=TA-dvvumwGU^ the download link is in the video description There are no issues with xevan on Ryzen. The only issues are with algos that use sha256 when compiled with SHA support. The prebuilt binaries referred to in the video are mine. There is no binary compiled with SHA support. Does the miner support more than 8 threads? If I edit the batch file to 16,15, or 14 threads it stops mining after a few minutes and locks up the pc (no display or mouse/keyboard but case fans etc still run) until I reset it. I have not tried it with anything between 8 and 14 threads at this point. Just curious to see if I should keep experimenting with thread count. Thanks! Yes it does. |
|
|
|
hello when i try to running i get error Illegal instruction (core dumped)
i try to implement wolf answer to disable aes ni Configure with --disable-aes-ni but it seems cpuminer-opt dont have that option so my question are 1. How i solve this problem "Illegal instruction (core dumped)"? Or 2. How to disable aes ni in cpuminer-opt ? Thank you guys If you're using the Windows binarires choose one that doesnt' have AES. If you're using Linux I need a lot more info. |
|
|
|
|
I believe I have found the root cause of the problems with m7m and SHA. The sph final function
re-initializes the context while the openssl version does not. The code sph in m7m took advantage of
this silent init while openssl was left with stale data.
I have also found that sha256t works at suprnova, but not at yiimp. This looks like a pool issue.
All issues with SHA should be fixed in the next release.
|
|
|
|
No I have not been able to figure out how to compile it myself, I used a pre-compiled version from a helpful person via youtube. https://www.youtube.com/watch?v=TA-dvvumwGU^ the download link is in the video description There are no issues with xevan on Ryzen. The only issues are with algos that use sha256 when compiled with SHA support. The prebuilt binaries referred to in the video are mine. There is no binary compiled with SHA support. |
|
|
|
You could remove the __SHA__ check and compile it with openssl sha256 instead of sph_256. It'll still run on other hardware just not accelerated.
I should have done that before releasing. M7m fails for me using openssl. I have something to work with now. |
|
|
|
Yes, non-sha compiles perfectly.
So the SHA code works on some algos but not on m7m, this is going to be a lot of work but I'm stuck without a Ryzen of my own to test with. |
|
|
|
I guess I wasn't reading it correctly. Anyways I found another algo I forgot about, skein. It also uses SHA but it doesn't work in 3.6.2. I think You misunderstood my question I want to know if a non-SHA compile works on Ryzen mining m7m, assuming the SHA build still fails. I reviewed the code again and I don't see any difference in the SHA code vs the non-SHA code after making the changes in the edit of my previous post. Here is the fix for algo/skein/skein.c 9c9
< #if defined __SHA__
---
> #if defined (SHA_NI)
17c17
< #if defined __SHA__
---
> #if defined (SHA_NI)
29c29
< #if defined __SHA__
---
> #if defined (SHA_NI)
45c45
< #if defined __SHA__
---
> #if defined (SHA_NI)
|
|
|
|
joblo, submitted a couple of pull requests to get it to compile on Ryzen. m7m is rejecting shares when built for Ryzen. cpuminer -a m7m -o stratum+tcp://xmg.suprnova.cc:7128 -u x -p x --cpu-priority 0 --api-bind 127.0.0.1:5500 --cpu-affinity 0x2 -D
********** cpuminer-opt 3.6.2 ***********
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 Apr 16 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-04-16 14:23:45] Binding process to cpu mask 2
[2017-04-16 14:23:45] 1 miner threads started, using 'm7m' algorithm.
[2017-04-16 14:23:45] Starting Stratum on stratum+tcp://xmg.suprnova.cc:7128
[2017-04-16 14:23:45] Binding thread 0 to cpu mask 2
[2017-04-16 14:23:45] Stratum session id: deadbeefcafebabe6e55180000000000
[2017-04-16 14:23:45] Stratum difficulty set to 8
[2017-04-16 14:23:48] stratum extranonce subscribe timed out
[2017-04-16 14:23:48] DEBUG: job_id='3fb1' extranonce2=00000000 ntime=aec4f358
[2017-04-16 14:23:48] m7m block 1283282, diff 4.488
[2017-04-16 14:23:55] CPU #0: 131.07 kH, 20.98 kH/s
[2017-04-16 14:24:06] DEBUG: [0 thread] Found share!
data 04000000ce6b8cd52940cbb5c79f0afe74ca0b2d4c5733152a0bdc87614fa230a43cbf7c6919c3c5e047a5ddfd618350d0cb63c87fec6e40538d324958ed2911645013d5aec4f358c709391c60670500
hash a246467dddbf887e5967eaada783eadbe98042a325e7fdba764274c74c050000
target 000000000000000000000000000000000000000000000000000000e0ff1f0000
[2017-04-16 14:24:06] CPU #0: 223.07 kH, 20.95 kH/s
[2017-04-16 14:24:06] Rejected 1/1 (100.0%), 223.07 kH, 20.95 kH/s
[2017-04-16 14:24:06] reject reason: low difficulty share of 0.000016677225528600396
[2017-04-16 14:24:06] factor reduced to : 0.67 It's hard to make sense of your pull request. This is the only error I found: - SHA256_CTX ctx_fsha256;
+ SHA256_CTX ctxf_sha256;
The non-SHA code works for me on 6700K, can you confirm it works on Ryzen? Edit: ok I found 2 more bugs, one a run time that would break the hash. 17c17
< #if defined __SHA__
---
> #if defined (SHA_NI)
188c188
< SHA256_CTX ctxf_sha256;
---
> SHA256_CTX ctx_fsha256;
273c273
< SHA256_Update( &ctxf_sha256, bdata, bytes );
---
> SHA256_Update( &ctxf_sha256, bdata_p64, bytes );
Do you still get rejects with these fixed? |
|
|
|
|
Thanks for the testing.
I found another issue, I forgot to implement SHA for m7m. Will do that and the changes in my previous post
and release 3.6.2.
|
|
|
|
The compile errors are mostly related to openssl 1.1.x. lbry and hodl are the only algos that prevent it from compiling. algo/lbry.c:52:4: error: unknown type name 'sph_sha512_context'
sph_sha512_context ctx_sha512 __attribute__ ((aligned (64))); My fix was to implement an openssl compliant sha512 instance. And fiddle with the algo/hodl/hodl.cpp:98:18: error: aggregate 'EVP_CIPHER_CTX ctx' has incomplete type and cannot be defined
EVP_CIPHER_CTX ctx; My fix was to instantiate the context as a pointer and pass it to each function as is and to change the cleanup routine to EVP_CIPHER_CTX_free(ctx). The compile log is at https://github.com/coinbutter/cpuminer-opt/blob/master/Compile%20log.txt because it's too long to post here. Some of the other changes I mostly made just for convenience sake on my part. I didn't change any of the min definitions in the uploaded code. In other news, groestl works in 3.6.1 if the AES portions are commented out. Have you found out anything about DMD not working? I noticed that in cpuminer-multi groestlcoin gets "SHA256(sctx->job.coinbase, (int) sctx->job.coinbase_size, merkle_root);" on line 1697 of cpu-miner.c and DMD gets the default of "sha256d(merkle_root, sctx->job.coinbase, (int) sctx->job.coinbase_size);" on line 1706. Good stuff, found 2 new bugs and one incompatibility. Lbry: coding error on my part, sph-sha2.h is still needed for sha512. I have found that the sph implementation of SHA is faster than openssl (prior to HW SHA) and SHA512 doesn't have HW support. Unless your testing shows openssl SHA512 is faster than sph SHA512 I'll stick with the sph version in 3.6.2. Hodl: Your compile log had no errors so it didn't help. The error suggests something missing in openssl, maybe #include issue. I'm tempted to relegate non-aes hodl to the legacy version, it's simpler than trying to fix it. Groestl: The AES version is broken in 3.6.1, fix already coded for 3.6.2. Dmd: Good catch, I missed that completely, simple to fix, will split groestl and dmd-gr in 3.6.2. I will also remove the SHA_NI hook and just rely on the builtin __SHA__ macro. Edit: will definitely relegate non-aes hodl to the legacy version. It's the only c++ code in the miner and removing it will make things simpler. |
|
|
|
joblo, My commits for the version listed below as cpuminer-znver1a are uploaded to https://github.com/coinbutter/cpuminer-opt/. It's got some of the other changes in my other versions but they're really rough, I only touched this version enough to compile and to use openssl 1.1.x for sha256t and lbry. I must have not had a clean system the last time I tested sha256t because the differences are much smaller than I recall. I noticed a lot of 'pool.mn:2947 asks job 64327 for block 8656' while the debug reports 'DEBUG: job_id='fb47''. Perhaps there is a type conversion issue. I'm still learning the coding but I'm impressed how the whole thing works. Still an 8% increase. The lbry changes are about 5% from 3.6.1 and 3% from 3.5.9.1. Thanks for testing, It's looking pretty good. Lbry submited valid shares using SHA so that proves the code works. I don't know what the issue is with sha256t, I'll look into it but it isn't SHA related. I'm curious about the compile errors you get with my code. I'd like to see them if you can post. I noticed you put in extra hooks for __SHA__. I put some logic in miner.h to define whether to compile with SHA, did it not work? Another change you made had to do with min/max. Those functions gave me problems previously and I implemented some hacks to workaround the issues. It appears those hacks may not work with newer compilers. |
|
|
|
No new algos or optimizations in the works, just a fix to groestl algo (use v3.5.9.1 until it's released).
I'm waiting for feedback from Ryzen users testing SHA so I can fix any issues.
joblo, I didn't realize you were waiting for that. I'll run some comparison tests tonight (3.5.9.1, 3.6.1 and a -znver1 (openssl 1.1.x, __SHA__ enabled) version. I get low difficulty rejected on sha256t for both versions. sha256t seems broken in all versions, even in ones where it used to work. I tested on yiimp. You mentioned code changes to get it to compile on Windows, what were they? |
|
|
|
|
Show Posts
