Is a windows version available?
Clearly you write more posts than you read. Go back a couple of pages. |
|
|
|
|
I've retested blakecoin in cpuminer-opt v3.1.18 and it is now listed as supported.
|
|
|
|
It looks like your CPU doesn't have AES_NI support, but Intel says it does.
You didn't specify -march=native in your configure, it's worth a try. You could
also enter the follwoing command to determine which arch is native:
gcc -march=native -Q --help=target|grep march
What errors did you get with cpuminer-opt? Did you specify -march=native?
I download now ur miner. And read ur readme.md.) Now i compiled with -march=btver1 flag. Working.) Thx.)  Trouble in CPU. Friend gives me wrong CPU name... this shit is: Intel(R) Celeron(R) CPU G1840 @ 2.80GHz  Glad I could help. |
|
|
|
If you would like some help you could provide some more info.
Source clone:GIT https://github.com/wolf9466/hodlminer-wolf./autogen.sh configure.ac:14: installing './compile'
configure.ac:4: installing './config.guess'
configure.ac:4: installing './config.sub'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing './depcomp'
./configure CFLAGS="-O3" checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... -std=gnu99
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether gcc -std=gnu99 needs -traditional... no
checking dependency style of gcc -std=gnu99... gcc3
checking for ranlib... ranlib
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/endian.h usability... no
checking sys/endian.h presence... no
checking for sys/endian.h... no
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for sys/sysctl.h... yes
checking whether be32dec is declared... no
checking whether le32dec is declared... no
checking whether be32enc is declared... no
checking whether le32enc is declared... no
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for getopt_long... yes
checking whether we can compile AVX code... yes
checking whether we can compile XOP code... yes
checking whether we can compile AVX2 code... yes
checking for json_loads in -ljansson... yes
checking for pthread_create in -lpthread... yes
checking for gawk... (cached) mawk
checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.35.0
checking for libcurl >= version 7.15.2... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating compat/Makefile
config.status: creating compat/jansson/Makefile
config.status: creating cpuminer-config.h
config.status: executing depfiles commands
make make all-recursive
make[1]: Enter catalog `/home/username/hodlminer-wolf'
Making all in compat
make[2]: Enter catalog `/home/username/hodlminer-wolf/compat'
make[3]: Enter catalog `/home/username/hodlminer-wolf/compat'
make[3]: Target `all-am' не требует выполнения команд.
make[3]: exit catalog `/home/username/hodlminer-wolf/compat'
make[2]: exit catalog `/home/username/hodlminer-wolf/compat'
make[2]: Enter catalog `/home/username/hodlminer-wolf'
gcc -DHAVE_CONFIG_H -I. -Wall -pthread -march=native -Ofast -flto -fuse-linker-plugin -std=gnu11 -O3 -MT hodlminer-sha2.o -MD -MP -MF .deps/hodlminer-sha2.Tpo -c -o hodlminer-sha2.o `test -f 'sha2.c' || echo './'`sha2.c
mv -f .deps/hodlminer-sha2.Tpo .deps/hodlminer-sha2.Po
gcc -DHAVE_CONFIG_H -I. -Wall -pthread -march=native -Ofast -flto -fuse-linker-plugin -std=gnu11 -O3 -MT hodlminer-cpu-miner.o -MD -MP -MF .deps/hodlminer-cpu-miner.Tpo -c -o hodlminer-cpu-miner.o `test -f 'cpu-miner.c' || echo './'`cpu-miner.c
mv -f .deps/hodlminer-cpu-miner.Tpo .deps/hodlminer-cpu-miner.Po
gcc -DHAVE_CONFIG_H -I. -Wall -pthread -march=native -Ofast -flto -fuse-linker-plugin -std=gnu11 -O3 -MT hodlminer-util.o -MD -MP -MF .deps/hodlminer-util.Tpo -c -o hodlminer-util.o `test -f 'util.c' || echo './'`util.c
mv -f .deps/hodlminer-util.Tpo .deps/hodlminer-util.Po
gcc -DHAVE_CONFIG_H -I. -Wall -pthread -march=native -Ofast -flto -fuse-linker-plugin -std=gnu11 -O3 -MT hodlminer-hodl.o -MD -MP -MF .deps/hodlminer-hodl.Tpo -c -o hodlminer-hodl.o `test -f 'hodl.c' || echo './'`hodl.c
mv -f .deps/hodlminer-hodl.Tpo .deps/hodlminer-hodl.Po
gcc -DHAVE_CONFIG_H -I. -Wall -pthread -march=native -Ofast -flto -fuse-linker-plugin -std=gnu11 -O3 -MT hodlminer-aes.o -MD -MP -MF .deps/hodlminer-aes.Tpo -c -o hodlminer-aes.o `test -f 'aes.c' || echo './'`aes.c
aes.c: In function ‘ExpandAESKey256_sub2’:
aes.c:21:2: warning: implicit declaration of function ‘_mm_aeskeygenassist_si128’ [-Wimplicit-function-declaration]
tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
^
aes.c:21:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
^
aes.c: In function ‘ExpandAESKey256’:
aes.c:41:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x01);
^
aes.c:47:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x02);
^
aes.c:53:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x04);
^
aes.c:59:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x08);
^
aes.c:65:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x10);
^
aes.c:71:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x20);
^
aes.c:77:7: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
tmp2 = _mm_aeskeygenassist_si128(tmp3, 0x40);
^
aes.c: In function ‘AES256Core’:
aes.c:86:2: warning: implicit declaration of function ‘_mm_aesenc_si128’ [-Wimplicit-function-declaration]
for(int i = 1; i < 14; ++i) State = _mm_aesenc_si128(State, ExpandedKey[i]);
^
aes.c:86:36: error: incompatible types when assigning to type ‘__m128i’ from type ‘int’
for(int i = 1; i < 14; ++i) State = _mm_aesenc_si128(State, ExpandedKey[i]);
^
aes.c:88:2: warning: implicit declaration of function ‘_mm_aesenclast_si128’ [-Wimplicit-function-declaration]
return(_mm_aesenclast_si128(State, ExpandedKey[14]));
^
aes.c:88:2: error: incompatible types when returning type ‘int’ but ‘__m128i’ was expected
aes.c:89:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[2]: *** [hodlminer-aes.o] error 1
make[2]: exit catalog `/home/username/hodlminer-wolf'
make[1]: *** [all-recursive] error 1
make[1]: exit catalog `/home/username/hodlminer-wolf'
make: *** [all] error 2
It looks like your CPU doesn't have AES_NI support, but Intel says it does. You didn't specify -march=native in your configure, it's worth a try. You could also enter the follwoing command to determine which arch is native: gcc -march=native -Q --help=target|grep march What errors did you get with cpuminer-opt? Did you specify -march=native? |
|
|
|
Anyone can upload compiled native cpu miner for hodl linux? cant compile any source... fking errors...
(Ubuntu 14 x86_64)
Which one Wolf's? Anyone what works on G4400. I try complile Wolf from git - not makes... %) abrakabra)) Have you tried cpuminer-opt? (see sig) Yup, cant build... other error. -___- If you would like some help you could provide some more info. |
|
|
|
Look, I was giving you a suggestion, but you said I'm full of shit. So that's it.
If you are saying that EVP on machines that are AES-NI is slower than Wolf's, it's all fine, I really don't care. On my AMD FX machine EVP is faster than Wolfs. Period.
I already wasted too much time in something that it's not even my business, I thought I was giving you a good advise, my bad.
I apologize if my claim was wrong. (on my machine it's true, but maybe on yours isn't, I don't care anymore)
Like I said, have a nice night, it's time for to go to bed.
There's no need to pout. You're making a claim that the AES_NI optimized hodlminer-wolf is slower than the original on AMD CPUs with AES_NI. That is a serious claim and no one else has reported this so you need proof. This goes beyond being childish, you have made a serious charge against a respected dev whio was paid to develop the AES_NI enhanced miner. You've already gone too far, you need to follow through with proof or make a full retraction with an apology to Wolf. You have to calm down, I haven't make any charge against nobody, what are you talking about? listen to your self! All I did was telling you that on my machine, EVP was using AES-NI and it is faster than wolfs code. Period. There is no 'charges' against nobody, please!! And like I said, that only applied to the source code on the hodlcoin, I even told you the file where it was used: hodl.cpp My suggestion was that you could use EVP alone (whitout wolfs code) because it uses AES-NI automatically. Where is the accusation?? You are making a stupid and simple suggestion a matter way, way out of proportion. You doesn't even understand that I was trying to suggest something to improve your code. So, end of the story. I'm not gonna continue with this stupid conversation, it when from a simple suggestion to "charges against a respected dev'. Go figure! You don't realize the sum of your claims. You claim the original hodlminer is faster than Wolf's AES_NI optimized version. I'm not saying it isn't true in your case but you need to show proof to convince me. I can't replicate your results and they in fact prove the opposite. You're on AMD and I'm on Intel, there're may be something there that should be pursued but you haven't given me anything I can work with. You're coming accross as a troll. Prove me wrong. The original hodlminer was not promoted to use AES_NI and Wolf was contracted to implement one. His version produced higher hashrates and no one has complained. Either no one is mining hodl with AES enabled AMD CPUs, they aren't paying attention, or you're wrong. There is some foundation to your claim because Wolf is optimized for Intel, its performance on AMD may not be optimum. You can provide the answer if you stop throwing a hissy fit and stick to the issue. It's up to you. Edit: In your last 5 posts you haven't provided one piece of new information. Instead you're acting like a spoiled child whining because I didn't give you praise. Grow up. |
|
|
|
|
Nice to see some new algos in the pool.
Is blakecoin showing the correct hashrate? Wrong units maybe?
|
|
|
|
Anyone can upload compiled native cpu miner for hodl linux? cant compile any source... fking errors...
(Ubuntu 14 x86_64)
Which one Wolf's? Anyone what works on G4400. I try complile Wolf from git - not makes... %) abrakabra)) Have you tried cpuminer-opt? (see sig) |
|
|
|
Look, I was giving you a suggestion, but you said I'm full of shit. So that's it.
If you are saying that EVP on machines that are AES-NI is slower than Wolf's, it's all fine, I really don't care. On my AMD FX machine EVP is faster than Wolfs. Period.
I already wasted too much time in something that it's not even my business, I thought I was giving you a good advise, my bad.
I apologize if my claim was wrong. (on my machine it's true, but maybe on yours isn't, I don't care anymore)
Like I said, have a nice night, it's time for to go to bed.
There's no need to pout. You're making a claim that the AES_NI optimized hodlminer-wolf is slower than the original on AMD CPUs with AES_NI. That is a serious claim and no one else has reported this so you need proof. This goes beyond being childish, you have made a serious charge against a respected dev whio was paid to develop the AES_NI enhanced miner. You've already gone too far, you need to follow through with proof or make a full retraction with an apology to Wolf. |
|
|
|
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.
OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection. Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the AES_NI and non-AES_NI implementations. @joblo: You are already using it in hodl.cpp: EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv); EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize); EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2); EVP_CIPHER_CTX_cleanup(&ctx); All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary. Hope that I'm clear this time  I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions on an incompatible CPU. Without it the compile fails. Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it. I already did and it works perfect. If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general purpose tool while the Wolf miner is optimized for the specific task. If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into detail there are only three things that would motivate me to make design changes to a stable product: support for more algos, higher hashrates or Windows support. Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out. Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response. If it is faster how do I implement it? It is faster and you already did. EVP is already implemented in the file hodl.cpp It will select AES-NI automatically if the machine has it. All you need to do is get rid of the Wolf code and let your own code by itself; it will select AES-NI automatically, you don't have to change anything. Just try it and you will see. Note: get rid of all the code that you are using for the AES-NI section in the hodlcoin source, you don't need it. You're full of shit, Wolf is 30% faster. That's what you get when you are trying to help. Never mind, forget all that I told you. Have a nice one. Are you serious? That's a pretty childish response. If evp is so much better and is already implemented in the orignal hodlminer Why is it so much slower than Wolf? You've made a substantial claim without any data. My data contradicts your claims, Your move. |
|
|
|
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.
OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection. Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the AES_NI and non-AES_NI implementations. @joblo: You are already using it in hodl.cpp: EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv); EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize); EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2); EVP_CIPHER_CTX_cleanup(&ctx); All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary. Hope that I'm clear this time I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions on an incompatible CPU. Without it the compile fails. Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it. I already did and it works perfect. If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general purpose tool while the Wolf miner is optimized for the specific task. If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into detail there are only three things that would motivate me to make design changes to a stable product: support for more algos, higher hashrates or Windows support. Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out. Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response. If it is faster how do I implement it? It is faster and you already did. EVP is already implemented in the file hodl.cpp It will select AES-NI automatically if the machine has it. All you need to do is get rid of the Wolf code and let your own code by itself; it will select AES-NI automatically, you don't have to change anything. Just try it and you will see. Note: get rid of all the code that you are using for the AES-NI section in the hodlcoin source, you don't need it. You're full of shit, Wolf is 30% faster. |
|
|
|
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.
OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection. Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the AES_NI and non-AES_NI implementations. @joblo: You are already using it in hodl.cpp: EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv); EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize); EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2); EVP_CIPHER_CTX_cleanup(&ctx); All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary. Hope that I'm clear this time I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions on an incompatible CPU. Without it the compile fails. Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it. I already did and it works perfect. If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general purpose tool while the Wolf miner is optimized for the specific task. If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into detail there are only three things that would motivate me to make design changes to a stable product: support for more algos, higher hashrates or Windows support. Ok, the optimized Wolf miner runs slower than EVP when the machine is AES-NI capable. Again, I'm just giving you a suggestion, you are free to do whatever you want of course Whenever you got the time, just give it a try on a machine with AES-NI running just EVP and you will see what I'm talking about. And I'm just talking about the part for hodlcoin, wich is the only part that I've checked out. Did you mistype your first sentence? If evp was faster than Wolf I would have expected a more emphatic response. If it is faster how do I implement it? |
|
|
|
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.
OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection. Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the AES_NI and non-AES_NI implementations. @joblo: You are already using it in hodl.cpp: EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv); EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize); EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2); EVP_CIPHER_CTX_cleanup(&ctx); All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary. Hope that I'm clear this time I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions on an incompatible CPU. Without it the compile fails. Then just get rid of that code, you don't need that part because like I already said: EVP algo will detect AES-NI capability and will use it automatically. You don't need extra code for that, just get ride of it. I already did and it works perfect. If you've been digging into the code you realize I have implemented both existing hodl miners, the original hodlminer and the AES optimized hodlminer-wolf. The original hodlminer uses EVP so why is it slower than Wolf? Openssl/evp is likely a general purpose tool while the Wolf miner is optimized for the specific task. If you've followed previous discuusions about design changes you'll know I'm a tough sell. Without going into detail there are only three things that would motivate me to make design changes to a stable product: support for more algos, higher hashrates or Windows support. |
|
|
|
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.
OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection. Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the AES_NI and non-AES_NI implementations. @joblo: You are already using it in hodl.cpp: EVP_EncryptInit(&ctx, EVP_aes_256_cbc(), key, iv); EVP_EncryptUpdate(&ctx, cacheMemoryOperatingData, &outlen1, cacheMemoryOperatingData2, cacheMemorySize); EVP_EncryptFinal(&ctx, cacheMemoryOperatingData + outlen1, &outlen2); EVP_CIPHER_CTX_cleanup(&ctx); All that I'm saying is that you shouldn't do anything else but let it run by itself. in other words, don't try to select the best arch; just use native and don't fork the source code to use 'special case' for AES-NI, since EVP will select it automatically. Meaning: don't use '#ifdef AES_NI', it's not necessary. Hope that I'm clear this time I beg to differ. The NO_AES_NI check is needed to prevent the compiler from trying to compile AES_NI instructions on an incompatible CPU. Without it the compile fails. |
|
|
|
Evp, AFAIK, is an abstraction layer of openssl which automatically selects the best instruction set based on the current cpu. Not sure it applies to this project, maybe to hodlcoin or others with "standard" algos.
OK, it's associated with openssl, The only thing close I found for the acronym was enhanced virus protection. Few coins use openssl for their hashing algos so I don't see the point, and hodl already uses it for both the AES_NI and non-AES_NI implementations. |
|
|
|
Hey man, I have a suggestion for you. You don't need to find out if the hardware have AES-NI in the beginning. If you use EVP alone, it finds out by itself if the hardware is AES-NI capable, and if that's the case, it uses it automatically. You don't have to do anything additional.
I already tried it and it works perfectly. Just my two cents.
I don't know what EVP is? Where does it come into play at compile time, run time? |
|
|
|
Is there a Github repository of this?
Eventually but not yet. |
|
|
|
So as you could tell, I am new to mining. I have a question When I goto a pool it sometimes gives me a choice of difficulty. I didn't/don't know really what that means I have a single GTX 970 from what I gathered on the web if I am hashing at say 5,000 MH/s I should put d=8 in my password field? Is that correct ? Worker's speed Difficulty
<500 Mhash/s 1
500-1000 Mhash/s 2
1000-2000 Mhash/s 4
2000-4000 Mhash/s 8
4000-10000 Mhash/s 16
10000-40000 Mhash/s 32
>40000 Mhash/s 64 How do I enter that in my password field when I have a password ? Like -u Name.worker -p password,d=8 ? (Like that?) Like right now I am using dmd-gr and it says I am hashing at 13,600 kH/s How does this correlate with the -f line ? Is there a guide that really goes into detail about what all the settings mean and do ? Thanks from a newb miner Don't worry about it unless you are having problems like rejects. Most of the time the pool will adjust the diff so you get a reasonable share submission rate. It is only occasionally that setting the diff manually, as you described, is necessary. Diff has nothing to do with hashrate, I don't know where you got that info. |
|
|
|
Yes this is why we added "blocks" as a unit of measure in the drop down box when making a TD..
Crap, I missed that. You seem to be always one step ahead of me. |
|
|
|
PROS AND CONS OF LINUX--
With linux you loose 20-30% of your profit because you cannot run the fastest x86 private miners. You cannot run claymores decred+etherum miner. You cannot overclock.(Perhaps if you mess with the Cool bits). The 64bit build is using more power. Actually, you can OC, change voltage, and more quickly and simply do your OWN dev on *nix. Just because YOU can't learn how to flash your cards doesn't mean no one can. You shouldn't need to flash your cards in the first place. Once again Nix making things immensely more complicated so you can get so called 'stability' and brag about not rebooting your machine in three years. Windows isn't perfect, but going to nix is like using Windows 3.11. Almost everything you have to do in the CLI and occasionally you use the UI to pretend you're modern. It's not that much diferent on Windows. Anything you can do with a GUI you can do better with the CLI, even on Windows. It's just that Windows has put more focus on GUIs because of the demographic they market to. |
|
|
|
|
Show Posts
