Tried -std=gnu11. he is using Arch linux, so i guess gcc 6.1.1
Downgraded to compile this. As long as you're compiling for AES you don't need GRS, just rip it out. If he's compiling for AES he shouldn't even need to have non-AES version compiled at all. Correct, but I haven't hooked it out because it was tedious work and wasn't causing any problems. It might make the compile a little faster but that's trivial. The entire groestl/sse2 dir can be deleted with only one linked source file to be removed from Makefile.am. That will work for an AES compile*. To make it compile for SSE2 replace all the references to the GRS macros in the algo files with the SPH version. In some cases the code is still there commented out. *I should qualify that. I don't recall if I have all the GRS refs hooked out of an AES compile. I'm considering doing that permanently as the benefit of GRS over SPH seems minimal. |
|
|
|
its even worst, its imported in private miners and sold!
That's disgusting. It is my opinion that miner development should be funded by the coin developers with the goal of keeping the source open. The current sale of private kernels hurts small miners who would take forever to ROI while the cost is peanuts for large farms. Keeping the source open makes for a more even playing field. And funding from coin developers or bounties ensures that miner devs get compensated. |
|
|
|
Tried -std=gnu11. he is using Arch linux, so i guess gcc 6.1.1
Downgraded to compile this. As long as you're compiling for AES you don't need GRS, just rip it out. |
|
|
|
g++ -fPIC -O3 -march=native -Wall -std=gnu++11 -Lyes/lib -Lyes/lib -o cpuminer cpuminer-cpu-miner.o cpuminer-util.o cpuminer-uint256.o cpuminer-api.o cpuminer-sysinfos.o cpuminer-algo-gate-api.o algo/groestl/cpuminer-sph_groestl.o algo/skein/cpuminer-sph_skein.o algo/bmw/cpuminer-sph_bmw.o algo/shavite/cpuminer-sph_shavite.o algo/shavite/cpuminer-shavite.o algo/echo/cpuminer-sph_echo.o algo/blake/cpuminer-sph_blake.o algo/heavy/cpuminer-sph_hefty1.o algo/blake/cpuminer-mod_blakecoin.o algo/luffa/cpuminer-sph_luffa.o algo/cubehash/cpuminer-sph_cubehash.o algo/simd/cpuminer-sph_simd.o algo/hamsi/cpuminer-sph_hamsi.o algo/fugue/cpuminer-sph_fugue.o algo/gost/cpuminer-sph_gost.o algo/jh/cpuminer-sph_jh.o algo/keccak/cpuminer-sph_keccak.o algo/keccak/cpuminer-keccak.o algo/sha3/cpuminer-sph_sha2.o algo/sha3/cpuminer-sph_sha2big.o algo/shabal/cpuminer-sph_shabal.o algo/whirlpool/cpuminer-sph_whirlpool.o crypto/cpuminer-blake2s.o crypto/cpuminer-oaes_lib.o crypto/cpuminer-c_keccak.o crypto/cpuminer-c_groestl.o crypto/cpuminer-c_blake256.o crypto/cpuminer-c_jh.o crypto/cpuminer-c_skein.o crypto/cpuminer-hash.o crypto/cpuminer-aesb.o crypto/cpuminer-magimath.o algo/argon2/cpuminer-argon2a.o algo/argon2/ar2/cpuminer-argon2.o algo/argon2/ar2/cpuminer-opt.o algo/argon2/ar2/cpuminer-cores.o algo/argon2/ar2/cpuminer-ar2-scrypt-jane.o algo/argon2/ar2/cpuminer-blake2b.o algo/cpuminer-axiom.o algo/blake/cpuminer-blake.o algo/blake/cpuminer-blake2.o algo/blake/cpuminer-blakecoin.o algo/blake/cpuminer-decred.o algo/blake/cpuminer-pentablake.o algo/bmw/cpuminer-bmw256.o algo/cubehash/sse2/cpuminer-cubehash_sse2.o algo/cryptonight/cpuminer-cryptolight.o algo/cryptonight/cpuminer-cryptonight-common.o algo/cryptonight/cpuminer-cryptonight-aesni.o algo/cryptonight/cpuminer-cryptonight.o algo/cpuminer-drop.o algo/echo/aes_ni/cpuminer-hash.o algo/cpuminer-fresh.o algo/groestl/cpuminer-groestl.o algo/groestl/cpuminer-myr-groestl.o algo/groestl/sse2/cpuminer-grso.o algo/groestl/sse2/cpuminer-grso-asm.o algo/groestl/aes_ni/cpuminer-hash-groestl.o algo/haval/cpuminer-haval.o algo/heavy/cpuminer-heavy.o algo/heavy/cpuminer-bastion.o algo/cpuminer-hmq1725.o algo/hodl/cpuminer-hodl.o algo/hodl/cpuminer-hodl-gate.o algo/hodl/cpuminer-hodl_arith_uint256.o algo/hodl/cpuminer-hodl_uint256.o algo/hodl/cpuminer-hash.o algo/hodl/cpuminer-hmac_sha512.o algo/hodl/cpuminer-sha256.o algo/hodl/cpuminer-sha512.o algo/hodl/cpuminer-utilstrencodings.o algo/hodl/cpuminer-hodl-wolf.o algo/hodl/cpuminer-aes.o algo/luffa/cpuminer-luffa.o algo/luffa/sse2/cpuminer-luffa_for_sse2.o algo/lyra2/cpuminer-lyra2.o algo/lyra2/cpuminer-sponge.o algo/lyra2/cpuminer-lyra2rev2.o algo/lyra2/cpuminer-lyra2re.o algo/keccak/sse2/cpuminer-keccak.o algo/cpuminer-m7mhash.o algo/cpuminer-neoscrypt.o algo/cpuminer-nist5.o algo/cpuminer-pluck.o algo/quark/cpuminer-quark.o algo/qubit/cpuminer-qubit.o algo/ripemd/cpuminer-sph_ripemd.o algo/cpuminer-scrypt.o algo/scryptjane/cpuminer-scrypt-jane.o algo/sha2/cpuminer-sha2.o algo/simd/sse2/cpuminer-nist.o algo/simd/sse2/cpuminer-vector.o algo/skein/cpuminer-skein.o algo/skein/cpuminer-skein2.o algo/cpuminer-s3.o algo/tiger/cpuminer-sph_tiger.o algo/x11/cpuminer-x11.o algo/x11/cpuminer-x11evo.o algo/x11/cpuminer-x11gost.o algo/x11/cpuminer-c11.o algo/x13/cpuminer-x13.o algo/x14/cpuminer-x14.o algo/x15/cpuminer-x15.o algo/x17/cpuminer-x17.o algo/yescrypt/cpuminer-yescrypt.o algo/yescrypt/cpuminer-yescrypt-common.o algo/yescrypt/cpuminer-sha256_Y.o algo/yescrypt/cpuminer-yescrypt-simd.o algo/cpuminer-zr5.o asm/cpuminer-neoscrypt_asm.o asm/cpuminer-sha2-x64.o asm/cpuminer-scrypt-x64.o asm/cpuminer-aesb-x64.o -lcurl -lz -ljansson -lpthread -lssl -lcrypto -lgmp
/usr/bin/ld: algo/groestl/sse2/cpuminer-grso-asm.o: relocation R_X86_64_32S against `grsoT0' can not be used when making a shared object; recompile with -fPIC
algo/groestl/sse2/cpuminer-grso-asm.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:1306: recipe for target 'cpuminer' failed
make[2]: *** [cpuminer] Error 1
make[2]: Leaving directory '/home/wolf/miners/cpuminer-opt-3.3.6'
Makefile:3336: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/wolf/miners/cpuminer-opt-3.3.6'
Makefile:658: recipe for target 'all' failed
make: *** [all] Error 2
I'm going to assume cpuminer-grso-asm.o was made from ASM, and that ASM was written for 32-bit? I don't know the history of all those SSE2 macros but I think your assumtion is correct. I am pretty fed up with the groestl sse2 code in particular. I have considered ripping it all out because there is an AES version and the GRS macros are only used on non-aes cpus. I'm not sure why you have the error. It's odd that it says to use -fPIC when it was already set. Anyway it compiled for me with -fPIC so I don't know what you did to break it. I literally downloaded it, tried build.sh - cleaned, added -fPIC, tried again. gcc vs g++ or 99 vs 11? gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Iyes/include -fno-strict-aliasing -I./compat/jansson -I. -Iyes/include -Wno-pointer-sign -Wno-pointer-to-int-cast -fPIC -O3 -march=native -Wall -Iyes/include -MT algo/groestl/sse2/cpuminer-grso-asm.o -MD -MP -MF algo/groestl/sse2/.deps/cpuminer-grso-asm.Tpo -c -o algo/groestl/sse2/cpuminer-grso-asm.o `test -f 'algo/groestl/sse2/grso-asm.c' || echo './'`algo/groestl/sse2/grso-asm.c
|
|
|
|
g++ -fPIC -O3 -march=native -Wall -std=gnu++11 -Lyes/lib -Lyes/lib -o cpuminer cpuminer-cpu-miner.o cpuminer-util.o cpuminer-uint256.o cpuminer-api.o cpuminer-sysinfos.o cpuminer-algo-gate-api.o algo/groestl/cpuminer-sph_groestl.o algo/skein/cpuminer-sph_skein.o algo/bmw/cpuminer-sph_bmw.o algo/shavite/cpuminer-sph_shavite.o algo/shavite/cpuminer-shavite.o algo/echo/cpuminer-sph_echo.o algo/blake/cpuminer-sph_blake.o algo/heavy/cpuminer-sph_hefty1.o algo/blake/cpuminer-mod_blakecoin.o algo/luffa/cpuminer-sph_luffa.o algo/cubehash/cpuminer-sph_cubehash.o algo/simd/cpuminer-sph_simd.o algo/hamsi/cpuminer-sph_hamsi.o algo/fugue/cpuminer-sph_fugue.o algo/gost/cpuminer-sph_gost.o algo/jh/cpuminer-sph_jh.o algo/keccak/cpuminer-sph_keccak.o algo/keccak/cpuminer-keccak.o algo/sha3/cpuminer-sph_sha2.o algo/sha3/cpuminer-sph_sha2big.o algo/shabal/cpuminer-sph_shabal.o algo/whirlpool/cpuminer-sph_whirlpool.o crypto/cpuminer-blake2s.o crypto/cpuminer-oaes_lib.o crypto/cpuminer-c_keccak.o crypto/cpuminer-c_groestl.o crypto/cpuminer-c_blake256.o crypto/cpuminer-c_jh.o crypto/cpuminer-c_skein.o crypto/cpuminer-hash.o crypto/cpuminer-aesb.o crypto/cpuminer-magimath.o algo/argon2/cpuminer-argon2a.o algo/argon2/ar2/cpuminer-argon2.o algo/argon2/ar2/cpuminer-opt.o algo/argon2/ar2/cpuminer-cores.o algo/argon2/ar2/cpuminer-ar2-scrypt-jane.o algo/argon2/ar2/cpuminer-blake2b.o algo/cpuminer-axiom.o algo/blake/cpuminer-blake.o algo/blake/cpuminer-blake2.o algo/blake/cpuminer-blakecoin.o algo/blake/cpuminer-decred.o algo/blake/cpuminer-pentablake.o algo/bmw/cpuminer-bmw256.o algo/cubehash/sse2/cpuminer-cubehash_sse2.o algo/cryptonight/cpuminer-cryptolight.o algo/cryptonight/cpuminer-cryptonight-common.o algo/cryptonight/cpuminer-cryptonight-aesni.o algo/cryptonight/cpuminer-cryptonight.o algo/cpuminer-drop.o algo/echo/aes_ni/cpuminer-hash.o algo/cpuminer-fresh.o algo/groestl/cpuminer-groestl.o algo/groestl/cpuminer-myr-groestl.o algo/groestl/sse2/cpuminer-grso.o algo/groestl/sse2/cpuminer-grso-asm.o algo/groestl/aes_ni/cpuminer-hash-groestl.o algo/haval/cpuminer-haval.o algo/heavy/cpuminer-heavy.o algo/heavy/cpuminer-bastion.o algo/cpuminer-hmq1725.o algo/hodl/cpuminer-hodl.o algo/hodl/cpuminer-hodl-gate.o algo/hodl/cpuminer-hodl_arith_uint256.o algo/hodl/cpuminer-hodl_uint256.o algo/hodl/cpuminer-hash.o algo/hodl/cpuminer-hmac_sha512.o algo/hodl/cpuminer-sha256.o algo/hodl/cpuminer-sha512.o algo/hodl/cpuminer-utilstrencodings.o algo/hodl/cpuminer-hodl-wolf.o algo/hodl/cpuminer-aes.o algo/luffa/cpuminer-luffa.o algo/luffa/sse2/cpuminer-luffa_for_sse2.o algo/lyra2/cpuminer-lyra2.o algo/lyra2/cpuminer-sponge.o algo/lyra2/cpuminer-lyra2rev2.o algo/lyra2/cpuminer-lyra2re.o algo/keccak/sse2/cpuminer-keccak.o algo/cpuminer-m7mhash.o algo/cpuminer-neoscrypt.o algo/cpuminer-nist5.o algo/cpuminer-pluck.o algo/quark/cpuminer-quark.o algo/qubit/cpuminer-qubit.o algo/ripemd/cpuminer-sph_ripemd.o algo/cpuminer-scrypt.o algo/scryptjane/cpuminer-scrypt-jane.o algo/sha2/cpuminer-sha2.o algo/simd/sse2/cpuminer-nist.o algo/simd/sse2/cpuminer-vector.o algo/skein/cpuminer-skein.o algo/skein/cpuminer-skein2.o algo/cpuminer-s3.o algo/tiger/cpuminer-sph_tiger.o algo/x11/cpuminer-x11.o algo/x11/cpuminer-x11evo.o algo/x11/cpuminer-x11gost.o algo/x11/cpuminer-c11.o algo/x13/cpuminer-x13.o algo/x14/cpuminer-x14.o algo/x15/cpuminer-x15.o algo/x17/cpuminer-x17.o algo/yescrypt/cpuminer-yescrypt.o algo/yescrypt/cpuminer-yescrypt-common.o algo/yescrypt/cpuminer-sha256_Y.o algo/yescrypt/cpuminer-yescrypt-simd.o algo/cpuminer-zr5.o asm/cpuminer-neoscrypt_asm.o asm/cpuminer-sha2-x64.o asm/cpuminer-scrypt-x64.o asm/cpuminer-aesb-x64.o -lcurl -lz -ljansson -lpthread -lssl -lcrypto -lgmp
/usr/bin/ld: algo/groestl/sse2/cpuminer-grso-asm.o: relocation R_X86_64_32S against `grsoT0' can not be used when making a shared object; recompile with -fPIC
algo/groestl/sse2/cpuminer-grso-asm.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:1306: recipe for target 'cpuminer' failed
make[2]: *** [cpuminer] Error 1
make[2]: Leaving directory '/home/wolf/miners/cpuminer-opt-3.3.6'
Makefile:3336: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/wolf/miners/cpuminer-opt-3.3.6'
Makefile:658: recipe for target 'all' failed
make: *** [all] Error 2
I'm going to assume cpuminer-grso-asm.o was made from ASM, and that ASM was written for 32-bit? I don't know the history of all those SSE2 macros but I think your assumtion is correct. I am pretty fed up with the groestl sse2 code in particular. I have considered ripping it all out because there is an AES version and the GRS macros are only used on non-aes cpus. I'm not sure why you have the error. It's odd that it says to use -fPIC when it was already set. Anyway it compiled for me with -fPIC so I don't know what you did to break it. |
|
|
|
tx, but yep the compiled/cpu flags was made fast
also the sysinfo could be cleaned, to get the cpu model from cpu id all the time... just dont had amd cpus to test it so i left the /proc/cpuinfo for now (better for arm or other weird SoC also)
configure.ac is what generate cpuminer-config.h on linux and mingw, the first line change the package defines
I moved the existing code to get the cpu model from cpu-miner.c to sysinfos.c, it's called cpu_brand_string. It only uses cpuid. I know it works on AMD, I just have to add the ARM hook. I'm also converting the has_* functions to inline for local usage with a wrapper for external use. It will avoid all function calls/returns in cpu_bestfeature and any other code in sysinfos.c that wants to quickly check a specific feature. I'm going to play with confgure.ac a bit to understand it better. If it works like make using timestamps I may be preventing regenerating configure by manually editting it. Considering the only change I've made to configure is the package version the untouched configure.ac should still be good and I should be able to go back to doing it the right way. |
|
|
|
@TPruvot I've finished merging the bench code with the following changes. I haven't implemented the configure.ac change yet. I need to understand better. Currently this file is not used so the change would have no effect, unless of course there is some magic using timestamps. And if there is I want to understand it before I mess with it. I've defined more symbolics in sysinfos.c for register access to improve readability. I've implemented the AVX1 check using a mask. I've defined a mask for FM3 but not implemented
a function to use it. Considering the cryptonight fix is in the upcoming release I don't want to wait too long. Edit: Wrote functions to detect all features. Rewrote cpu_bestfeature to use functions instead of reading flags directly. Only tested functions I use. Here's a link to a tool I used as a guide. Very complete and detailed. https://bitbucket.org/ariya/cpu-detect/src |
|
|
|
Where did the lyra2v2 kernel come from? Is it open source? |
|
|
|
I took a quick look at the patch but I want to pursue the cryptonight issue a bit more first, got an idea.
Before I implememnt the patch I need to understand the changes. I am particularly concerned about
the change to configure.ac. Given this file isn't being used currently by cpuminer-opt what will this do?
It works currently so trying to fix something that isn't broken can often break it.
Is this truly a diif vs 3.3.5? If so it' won't have some changes so the cpuid functions which didn't work correctly.
I moved the boolean algebra out of the bit definitions to the functions to keep the bit definitions pure.
I also defined symbolic names for the register array indexes, Some of the has_feature functions don't work in
3.3.5. As long as your changes don't rely on these bugs they should be ok with my changes.
Will touch base when I dig deeper into implementing the changes.
I've merged most of the changes but have some concerns. I would still like an explanation regarding configure.ac. I don't want to break it, I've done enough of that already when I don't fully understand what I'm doing. I have changed the implementation of the flags. The flags are defined as per the HW definition, not a mask that defines the feature they represent. This applies primarilly to AVX1 which requires 3 bits to define the feature. // http://en.wikipedia.org/wiki/CPUID
#define EAX_Reg (0)
#define EBX_Reg (1)
#define ECX_Reg (2)
#define EDX_Reg (3)
#define XSAVE_Flag (1 << 26)
#define OSXSAVE_Flag (1 << 27)
//#define AVX1_Flag ((1 << 28)|OSXSAVE_Flag)
#define AVX1_Flag (1 << 28)
#define XOP_Flag (1 << 11)
#define FMA3_Flag ((1 << 12)|AVX1_Flag|OSXSAVE_Flag)
#define AES_Flag (1 << 25)
#define SSE42_Flag (1 << 20)
#define SSE_Flag (1 << 25) // EDX
#define SSE2_Flag (1 << 26) // EDX
#define AVX2_Flag (1 << 5) // ADV EBX
(stuff snipped)
// westmere and above
bool has_avx1()
{
#ifdef __arm__
return false;
#else
int cpu_info[4] = { 0 };
cpuid( 1, cpu_info );
return ( ( cpu_info[ ECX_Reg ] & AVX1_Flag ) != 0 )
&& ( ( cpu_info[ ECX_Reg ] & XSAVE_Flag ) != 0 )
&& ( ( cpu_info[ ECX_Reg ] & OSXSAVE_Flag ) != 0 );
#endif
}
The current implementation or ORing the bits to create a mask doesn't work as intended. It will return true if any of the mask bits are set, It should only return true if all the mask bits are set. AVX1 is only available if all three bits are set. To do this with your mask you would need to do: has_avx = ( ( cpu_info[ ECX_Reg ] & AVX1_Flag ) == AVX1_Flag );
The same issue exists with FMA3 but I don't use it so didn't change it. Edit: I defined masks for AVX1 and FMA3: #define AVX1_mask (AVX1_Flag|XSAVE_Flag|OSXSAVE_Flag)
#define FMA3_mask (FMA3_Flag|AVX1_mask)
bool has_avx1()
{
#ifdef __arm__
return false;
#else
int cpu_info[4] = { 0 };
cpuid( 1, cpu_info );
return ( ( cpu_info[ ECX_Reg ] & AVX1_mask ) == AVX1_mask );
#endif
}
|
|
|
|
|
I have a solution for cryptonight on Windows.
Moving the ctx from local to global was the right fix but I neglected to make it thread safe. As a result
each thread was clobbering the same ctx. need to do some regression testing but my optimism has
returned.
Once that issue is closed I will merge the TPruvot bench test and release v3.3.6.
|
|
|
|
|
I took a quick look at the patch but I want to pursue the cryptonight issue a bit more first, got an idea.
Before I implememnt the patch I need to understand the changes. I am particularly concerned about
the change to configure.ac. Given this file isn't being used currently by cpuminer-opt what will this do?
It works currently so trying to fix something that isn't broken can often break it.
Is this truly a diif vs 3.3.5? If so it' won't have some changes so the cpuid functions which didn't work correctly.
I moved the boolean algebra out of the bit definitions to the functions to keep the bit definitions pure.
I also defined symbolic names for the register array indexes, Some of the has_feature functions don't work in
3.3.5. As long as your changes don't rely on these bugs they should be ok with my changes.
Will touch base when I dig deeper into implementing the changes.
|
|
|
|
I can show you a fun example of corrupting the stack deliberately with C in order to skip instructions  Wouldn't you need to use ASM to alter the stack pointer? Corrupting the contents is trivial and wouldn't cause the stack check to crash unless it verifies the frames which would be too time consuming. Corrupt stack contents would only crash on accessing a local variable, a subroutine call or on return. Nope! I don't need to modify the stack pointer directly, I need to CONTROL it. Now, if we know what the function epilogue is going to be (say a pop esp/rsp) - clobber the address on the stack using an invalid array index, and you've gained control of esp/rsp. As I said modifying the stack contents is trivial and would cause a different crash than the one I'm seeing. But it's irrelevent now as it no longer crashes after moving ctx to global. This tangent is bringing back some old memories of writing opcode patches for a stack based processor. It was like using an HP RPN calculator but was a bitch to keep the stack coherent. |
|
|
|
I can show you a fun example of corrupting the stack deliberately with C in order to skip instructions Wouldn't you need to use ASM to alter the stack pointer? Corrupting the contents is trivial and wouldn't cause the stack check to crash unless it verifies the frames which would be too time consuming. Corrupt stack contents would only crash on accessing a local variable, a subroutine call or on return. |
|
|
|
With 8 cores and little other CPU usage I get 575 kH/s on my i7 6700K @ 4 GHz. I don't know the typical performance
on AMD CPUs. Comparing with other AMD users is probably the best way to make sure your mining at optimum performance.
Yes other users are reporting 300 to 350 kh/s too. I think that is kinda low for an 8 core at 4ghz. The i7 6700K is a little superior to the fx 8350 but that difference in hashrate is almost double  Maybe if we compile the miner on our machine we get better performance? I always recommend compiling your own. AMD has some quirks, be sure to read the README.md. |
|
|
|
For the future, gcc has a flag: -fstack-usage when compiling it generates *.su files that have info how much bytes a function would need for stack. After adding that, recompiling cpuminer-opt on core2 and then printing all *.su files, sorted by size: $ find . -iname '*.su' -print0 | xargs -0 cat |sort -k2n|tail|column -t
x17.c:212:6:x17hash_alt 3904 static
cpu-miner.c:2689:5:main 4144 static
x17.c:87:13:x17hash 4256 static
hodl-wolf.c:28:5:scanhash_hodl_wolf 4304 static
scrypt.c:696:12:scanhash_scrypt 7680 dynamic,bounded
hmq1725.c:143:13:hmq1725hash 7744 static
scrypt.c:648:13:scrypt_1024_1_1_256_24way 9088 dynamic,bounded
m7mhash.c:195:5:scanhash_m7m_hash 12464 dynamic,bounded
api.c:511:13:api 17136 dynamic,bounded
cryptonight.c:172:6:cryptonight_hash_ctx 2097648 static
You might want to increase max stack size in makefile to 3mb or more, setting it to 2MB isn't enough because you need 2097648 bytes just for that function. Thanks for the info. I increased the stack size in Makefile.am to 3 MB but it made no difference. AES still produces rejects and non-aes still crashes. There is apparently another problem with the AES version other than the stack overflow (that is a huge stack compared with the other algos) because I solved that by reducing the local variables. So the situation now for AES seems the same code with no superficial Windows hooks works on Linux but produces rejects on Windows. By superficial I mean checks for Windows in cryptonight code. There may be some low level hooks in common code also used by other algos. The core2 build still crashes after moving ctx to global and increasing the stacksize to 3 MB in Makefile.am. It's either the same crash or a different one. I haven't followed up because my focus is on AES first. |
|
|
|
There are no command line parameters to worry about except the number of threads. 300 KH/s seems low for an 8 core @ 4 GHz, I get 575 on my i7-6700K. Your CPU supports both AES and AVX so if the miner is properly compiled it should use the optimized hasher. Just to confirm, did you download cpuminer-opt from here? http://cryptomining-blog.com/7930-windows-binaries-for-the-cpuminer-opt-3-3-5-cpu-miner/Also what was displayed on start up regarding CPU capabilities and optimization? Post the output if you can. Yes, I downloaded it from that source, lol here is what it looks like right now while working... i'm using 7 cores instead of 8  As you can see it is really sluggish but I have a wallet syncing in the background. Here is the start screen https://ctrlv.cz/Q9iLStartup looks good. Wallet synching can slow it down. Wait till that's done then close the wallet. Check your CPU usage to make sure nothing else is taking time. Ok, thanks. How much do you think should be the optimal speed for a cpu like this? With 8 cores and little other CPU usage I get 575 kH/s on my i7 6700K @ 4 GHz. I don't know the typical performance on AMD CPUs. Comparing with other AMD users is probably the best way to make sure your mining at optimum performance. |
|
|
|
|
Show Posts
