[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[felixbrucker]

no need to rush this, its just a cosmetic thing, will wait for the next release instead of fiddling with the src

Edit: corrected references for v3.4.7

Edit2: the display format is in the API code and is generic for all algos so it needs to support fractions.

i suppose this is regarding the 10000.016... stuff? it just confused me as the diff is displayed as 10k/5k in the cli and from nicehash, just curious why it would add 0.016.. to the integer, this cant be sole fp conversion, or?

[1713557827]

1713557827

[1713557827]

1713557827

[1713557827]

1713557827

[1713557827]

1713557827

[joblo]

no need to rush this, its just a cosmetic thing, will wait for the next release instead of fiddling with the src

Edit: corrected references for v3.4.7

Edit2: the display format is in the API code and is generic for all algos so it needs to support fractions.

i suppose this is regarding the 10000.016... stuff? it just confused me as the diff is displayed as 10k/5k in the cli and from nicehash, just curious why it would add 0.016.. to the integer, this cant be sole fp conversion, or?

The diff is calculated using floating point math so isn't precise, the cli code is specific to cryptonight so it truncates the fraction
when displaying the diff.

[felixbrucker]

no need to rush this, its just a cosmetic thing, will wait for the next release instead of fiddling with the src

Edit: corrected references for v3.4.7

Edit2: the display format is in the API code and is generic for all algos so it needs to support fractions.

i suppose this is regarding the 10000.016... stuff? it just confused me as the diff is displayed as 10k/5k in the cli and from nicehash, just curious why it would add 0.016.. to the integer, this cant be sole fp conversion, or?

The diff is calculated using floating point math so isn't precise, the cli code is specific to cryptonight so it truncates the fraction
when displaying the diff.

ahh i understand, i thought diff was an integer set by stratum

[joblo]

no need to rush this, its just a cosmetic thing, will wait for the next release instead of fiddling with the src

Edit: corrected references for v3.4.7

Edit2: the display format is in the API code and is generic for all algos so it needs to support fractions.

i suppose this is regarding the 10000.016... stuff? it just confused me as the diff is displayed as 10k/5k in the cli and from nicehash, just curious why it would add 0.016.. to the integer, this cant be sole fp conversion, or?

The diff is calculated using floating point math so isn't precise, the cli code is specific to cryptonight so it truncates the fraction
when displaying the diff.

ahh i understand, i thought diff was an integer set by stratum

It probably should be integer. try this

file util.c line 1631, add trunc( ) call

Code:

double difficulty = trunc( (((double) 0xffffffff) / target) );

[felixbrucker]

It probably should be integer. try this

file util.c line 1631, add trunc( ) call

Code:

double difficulty = trunc( (((double) 0xffffffff) / target) );

hm, but this does "flatten" the diff for every algo, right? i have seen stratum diffs with fractions (like 8.634 or something) which then would be flattened to the integer, doesnt this affect mining?

[joblo]

It probably should be integer. try this

file util.c line 1631, add trunc( ) call

Code:

double difficulty = trunc( (((double) 0xffffffff) / target) );

hm, but this does "flatten" the diff for every algo, right? i have seen stratum diffs with fractions (like 8.634 or something) which then would be flattened to the integer, doesnt this affect mining?

Only affects cryptonight. Any code protected by jsonrpc_2,  jr2, etc is only used for cryptonight.

Even if it's wrong it doesn't affect mining. The diff is just FYI for the client. the client just checks if it has changed so it can display
a message and saves it for the API.

[felixbrucker]

It probably should be integer. try this

file util.c line 1631, add trunc( ) call

Code:

double difficulty = trunc( (((double) 0xffffffff) / target) );

hm, but this does "flatten" the diff for every algo, right? i have seen stratum diffs with fractions (like 8.634 or something) which then would be flattened to the integer, doesnt this affect mining?

Only affects cryptonight. Any code protected by jsonrpc_2,  jr2, etc is only used for cryptonight.

Even if it's wrong it doesn't affect mining. The diff is just FYI for the client. the client just checks if it has changed so it can display
a message and saves it for the API.

ahh i see

[th3.r00t]

nice to see users using the api

i like apis

I like this WebUI!
Would mind sharing it?

Also your config regarding the API usage?

Thanks!

[felixbrucker]

I like this WebUI!
Would mind sharing it?

Also your config regarding the API usage?

Thanks!

actually its this, anybody is free to use it, i see it as training for my js coding skills, for now just hacking together

[Epsylon3]

joblo: some stuff to remove from your git :

Code:

0       0       algo/argon2/.dirstamp
0       0       algo/argon2/ar2/.dirstamp
0       0       algo/blake/.dirstamp
0       0       algo/bmw/.dirstamp
0       525     algo/bmw/sse2/bmw.c.new
0       0       algo/cryptonight/.dirstamp
0       0       algo/cubehash/.dirstamp
0       0       algo/cubehash/sse2/.dirstamp
0       0       algo/echo/.dirstamp
0       0       algo/echo/aes_ni/.dirstamp
0       0       algo/fugue/.dirstamp
0       0       algo/gost/.dirstamp
0       0       algo/groestl/.dirstamp
0       0       algo/groestl/aes_ni/.dirstamp
0       0       algo/groestl/sse2/.dirstamp
-       -       algo/groestl/sse2/.grso.c.swo
0       0       algo/hamsi/.dirstamp
0       0       algo/haval/.dirstamp
0       0       algo/heavy/.dirstamp
0       0       algo/hodl/.dirstamp
0       0       algo/jh/.dirstamp
0       0       algo/keccak/.dirstamp
0       0       algo/keccak/sse2/.dirstamp
0       0       algo/luffa/.dirstamp
0       0       algo/luffa/sse2/.dirstamp
0       558     algo/luffa/sse2/luffa_for_sse2.c.bak
0       0       algo/lyra2/.dirstamp
0       434     algo/m7m.c.old
0       0       algo/quark/.dirstamp
0       0       algo/qubit/.dirstamp
0       0       algo/ripemd/.dirstamp
0       0       algo/scryptjane/.dirstamp
0       0       algo/sha2/.dirstamp
0       0       algo/sha3/.dirstamp
0       0       algo/shabal/.dirstamp
0       0       algo/shavite/.dirstamp
0       0       algo/simd/.dirstamp
0       0       algo/simd/sse2/.dirstamp
0       0       algo/skein/.dirstamp
0       0       algo/tiger/.dirstamp
0       0       algo/whirlpool/.dirstamp
0       0       algo/x11/.dirstamp
0       0       algo/x13/.dirstamp
0       0       algo/x14/.dirstamp
0       0       algo/x15/.dirstamp
0       0       algo/x17/.dirstamp
0       0       algo/yescrypt/.dirstamp
0       50      comp.log
-       -       compat/gmp.del/x64/mpir.lib
-       -       compat/gmp.del/x86/mpir.lib
0       1928    compat/gmp.h.del

i suggest you edit .gitignore and add these lines :

Code:

.dirstamp
*.log
*.bak
*.new
*.del
*.del/

git rm <file>
git commit

[scryptr]

COMPILE PROBLEMS UNDER LINUX--

I noticed that the CPUMiner-OPT project was moved onto git!  That is a big thing, really.  It means that I can remotely log into my Linux mining rigs, clone git, and build the binary from my main computer. That saves jockeying a USB stick around to each rig.

Well, it should, at least.  The compile still fails on my Linux boxes.  I just want to run the "build.sh" and get a binary without any fuss.

The Windows binary runs fine on my i7 Sandybridge Win 7 x64 computer.  And, it mines CryptoNiight on NiceHash without a problem.  CPUMiner-Multi does not mine CryptoNight on NiceHash, it connects, and hashes, but the stratum connection fails when results are submitted.  There may be something quirky about the stratum at NiceHash.  TSIVs GPU CryptoNight CCminer behaves the same way on NiceHash, but mines CryptoNight on other pools with no problem.

SO, CPUMine-Multi compiles on Linux, but does not hash properly on NiceHash.  CPUMiner-OPT hashes well on NiceHash, but I can't get it to compile on my Linux boxes.  TSIV's CCminer for CryptoNight exhibits a very similar stratum error when mining on NiceHash as does CPUMiner-Multi.  I think all three miners do the hashing work correctly, but that NicHash has a stratum failure when results are submitted.  All three miners connect and begin to work properly.

I have the pre-requisites for compilation, and CCminer compiles on my Linux boxes, as does CPUMiner-Multi.  I need to get a clean compile of CPUMiner-OPT on my rigs.       --scryptr

[joblo]

COMPILE PROBLEMS UNDER LINUX--

I noticed that the CPUMiner-OPT project was moved onto git!  That is a big thing, really.  It means that I can remotely log into my Linux mining rigs, clone git, and build the binary from my main computer. That saves jockeying a USB stick around to each rig.

Well, it should, at least.  The compile still fails on my Linux boxes.  I just want to run the "build.sh" and get a binary without any fuss.

The Windows binary runs fine on my i7 Sandybridge Win 7 x64 computer.  And, it mines CryptoNiight on NiceHash without a problem.  CPUMiner-Multi does not mine CryptoNight on NiceHash, it connects, and hashes, but the stratum connection fails when results are submitted.  There may be something quirky about the stratum at NiceHash.  TSIVs GPU CryptoNight CCminer behaves the same way on NiceHash, but mines CryptoNight on other pools with no problem.

SO, CPUMine-Multi compiles on Linux, but does not hash properly on NiceHash.  CPUMiner-OPT hashes well on NiceHash, but I can't get it to compile on my Linux boxes.  TSIV's CCminer for CryptoNight exhibits a very similar stratum error when mining on NiceHash as does CPUMiner-Multi.  I think all three miners do the hashing work correctly, but that NicHash has a stratum failure when results are submitted.  All three miners connect and begin to work properly.

I have the pre-requisites for compilation, and CCminer compiles on my Linux boxes, as does CPUMiner-Multi.  I need to get a clean compile of CPUMiner-OPT on my rigs.       --scryptr

I need more info, you know the drill. The only outstanding compile issue I'm aware of is with newer versions of gcc.

[scryptr]

COMPILE PROBLEMS UNDER LINUX--

I noticed that the CPUMiner-OPT project was moved onto git!  That is a big thing, really.  It means that I can remotely log into my Linux mining rigs, clone git, and build the binary from my main computer. That saves jockeying a USB stick around to each rig.

Well, it should, at least.  The compile still fails on my Linux boxes.  I just want to run the "build.sh" and get a binary without any fuss.

The Windows binary runs fine on my i7 Sandybridge Win 7 x64 computer.  And, it mines CryptoNiight on NiceHash without a problem.  CPUMiner-Multi does not mine CryptoNight on NiceHash, it connects, and hashes, but the stratum connection fails when results are submitted.  There may be something quirky about the stratum at NiceHash.  TSIVs GPU CryptoNight CCminer behaves the same way on NiceHash, but mines CryptoNight on other pools with no problem.

SO, CPUMine-Multi compiles on Linux, but does not hash properly on NiceHash.  CPUMiner-OPT hashes well on NiceHash, but I can't get it to compile on my Linux boxes.  TSIV's CCminer for CryptoNight exhibits a very similar stratum error when mining on NiceHash as does CPUMiner-Multi.  I think all three miners do the hashing work correctly, but that NicHash has a stratum failure when results are submitted.  All three miners connect and begin to work properly.

I have the pre-requisites for compilation, and CCminer compiles on my Linux boxes, as does CPUMiner-Multi.  I need to get a clean compile of CPUMiner-OPT on my rigs.       --scryptr

I need more info, you know the drill. The only outstanding compile issue I'm aware of is with newer versions of gcc.

SUPRISE! CPUMINER-OPT COMPILED!!! --

I was working on my 750ti rig, and it would not compile.  I decided to try compilation on one of my ethminig rigs, and I started by checking for pre-requisites with "sudo apt-get install build-essential libssl-dev libcurl4-openssl-dev libjansson-dev libgmp-dev automake".  This prompted me to install the lacking components, and I selected "yes".  After which, I cloned your git, and the"build.sh" scrypt worked the first time.  Currently, I am mining CryptoNight on NiceHash with your CPUMiner-OPT.
.
Back to the 750ti rig.  I checked again for pre-requisites as above.  They were all in place.  But, from attempts to compile yesterday, I remembered an error "cannot find m4 directory".  The "m4" package was one of the freshly installed packages on the ethmining rig..  I checked for it on the 750ti rig with "whereis m4", and it is installed.  This may be the problem, the directory is not seen properly when compiling.  What do you suggest here?       --scryptr

[joblo]

COMPILE PROBLEMS UNDER LINUX--

I noticed that the CPUMiner-OPT project was moved onto git!  That is a big thing, really.  It means that I can remotely log into my Linux mining rigs, clone git, and build the binary from my main computer. That saves jockeying a USB stick around to each rig.

Well, it should, at least.  The compile still fails on my Linux boxes.  I just want to run the "build.sh" and get a binary without any fuss.

The Windows binary runs fine on my i7 Sandybridge Win 7 x64 computer.  And, it mines CryptoNiight on NiceHash without a problem.  CPUMiner-Multi does not mine CryptoNight on NiceHash, it connects, and hashes, but the stratum connection fails when results are submitted.  There may be something quirky about the stratum at NiceHash.  TSIVs GPU CryptoNight CCminer behaves the same way on NiceHash, but mines CryptoNight on other pools with no problem.

SO, CPUMine-Multi compiles on Linux, but does not hash properly on NiceHash.  CPUMiner-OPT hashes well on NiceHash, but I can't get it to compile on my Linux boxes.  TSIV's CCminer for CryptoNight exhibits a very similar stratum error when mining on NiceHash as does CPUMiner-Multi.  I think all three miners do the hashing work correctly, but that NicHash has a stratum failure when results are submitted.  All three miners connect and begin to work properly.

I have the pre-requisites for compilation, and CCminer compiles on my Linux boxes, as does CPUMiner-Multi.  I need to get a clean compile of CPUMiner-OPT on my rigs.       --scryptr

I need more info, you know the drill. The only outstanding compile issue I'm aware of is with newer versions of gcc.

SUPRISE! CPUMINER-OPT COMPILED!!! --

I was working on my 750ti rig, and it would not compile.  I decided to try compilation on one of my ethminig rigs, and I started by checking for pre-requisites with "sudo apt-get install build-essential libssl-dev libcurl4-openssl-dev libjansson-dev libgmp-dev automake".  This prompted me to install the lacking components, and I selected "yes".  After which, I cloned your git, and the"build.sh" scrypt worked the first time.  Currently, I am mining CryptoNight on NiceHash with your CPUMiner-OPT.
.
Back to the 750ti rig.  I checked again for pre-requisites as above.  They were all in place.  But, from attempts to compile yesterday, I remembered an error "cannot find m4 directory".  The "m4" package was one of the freshly installed packages on the ethmining rig..  I checked for it on the 750ti rig with "whereis m4", and it is installed.  This may be the problem, the directory is not seen properly when compiling.  What do you suggest here?       --scryptr

There is an m4 directory in the cpuminer-opt tarball but it got dropped from git. It is empty and unchanged for months. I can compile without it.
But it seems you can't. You could try adding it.

I could try uploading it to git again but I have no reason to expect different results. Maybe someone who understands autoconf better has
a suggestion.

[scryptr]

<SNIP>

There is an m4 directory in the cpuminer-opt tarball but it got dropped from git. It is empty and unchanged for months. I can compile without it.
But it seems you can't. You could try adding it.

I could try uploading it to git again but I have no reason to expect different results. Maybe someone who understands autoconf better has
a suggestion.

Thanks.  I did some web research, and tried a few suggestions, and it made no difference.  Right now, all of my HASWELL CPU rigs have successfully compiled CPUMiner-OPT.  The two rigs that won't compile your miner have Sempron 145 CPUs, and do not support AES.  They are running CPUMiner-Multi, and mining Lyra2re.  The HASWELL rigs are mining CryptoNight with yoiur software.  The rigs with AES support are running the optimised CPU miner, the rigs without are doing fine on Lyra2re.

Thanks for answering my questions.  I do wonder why tpruvot's CPUMiner-Multi is having difficulty with the NiceHash CryptoNight pool.  Perhaps I should post in his thread.       --scryptr

[joblo]

<SNIP>

There is an m4 directory in the cpuminer-opt tarball but it got dropped from git. It is empty and unchanged for months. I can compile without it.
But it seems you can't. You could try adding it.

I could try uploading it to git again but I have no reason to expect different results. Maybe someone who understands autoconf better has
a suggestion.

Thanks.  I did some web research, and tried a few suggestions, and it made no difference.  Right now, all of my HASWELL CPU rigs have successfully compiled CPUMiner-OPT.  The two rigs that won't compile your miner have Sempron 145 CPUs, and do not support AES.  They are running CPUMiner-Multi, and mining Lyra2re.  The HASWELL rigs are mining CryptoNight with yoiur software.  The rigs with AES support are running the optimised CPU miner, the rigs without are doing fine on Lyra2re.

Thanks for answering my questions.  I do wonder why tpruvot's CPUMiner-Multi is having difficulty with the NiceHash CryptoNight pool.  Perhaps I should post in his thread.       --scryptr

What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

[scryptr]

<SNIP>



What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

THAT TRICK DID NOT WORK--

I tried it earlier.  My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re.  What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash.       --scryptr

[joblo]

<SNIP>



What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

THAT TRICK DID NOT WORK--

I tried it earlier.  My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re.  What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash.       --scryptr

Could be more than one problem, AMD often doesn't compile with "-march=native", give it a try with "-march=core2". There is some discussion
about this with an AMD user several pages back in this thread. He has a good handle on the problems and I've let him take the lead as I don't have
any AMD CPUs.

The issue with cryptonight at Nicehash is they threw in a twist to the protocol that requires a miner update. TPruvot has been
quite busy with ccminer and yiimp so I don't expect a quick fix to cpuminer-multi, especially since those other projects are producing revenue.

[joblo]

joblo: some stuff to remove from your git :

Code:

0       0       algo/argon2/.dirstamp
0       0       algo/argon2/ar2/.dirstamp
0       0       algo/blake/.dirstamp
0       0       algo/bmw/.dirstamp
0       525     algo/bmw/sse2/bmw.c.new
0       0       algo/cryptonight/.dirstamp
0       0       algo/cubehash/.dirstamp
0       0       algo/cubehash/sse2/.dirstamp
0       0       algo/echo/.dirstamp
0       0       algo/echo/aes_ni/.dirstamp
0       0       algo/fugue/.dirstamp
0       0       algo/gost/.dirstamp
0       0       algo/groestl/.dirstamp
0       0       algo/groestl/aes_ni/.dirstamp
0       0       algo/groestl/sse2/.dirstamp
-       -       algo/groestl/sse2/.grso.c.swo
0       0       algo/hamsi/.dirstamp
0       0       algo/haval/.dirstamp
0       0       algo/heavy/.dirstamp
0       0       algo/hodl/.dirstamp
0       0       algo/jh/.dirstamp
0       0       algo/keccak/.dirstamp
0       0       algo/keccak/sse2/.dirstamp
0       0       algo/luffa/.dirstamp
0       0       algo/luffa/sse2/.dirstamp
0       558     algo/luffa/sse2/luffa_for_sse2.c.bak
0       0       algo/lyra2/.dirstamp
0       434     algo/m7m.c.old
0       0       algo/quark/.dirstamp
0       0       algo/qubit/.dirstamp
0       0       algo/ripemd/.dirstamp
0       0       algo/scryptjane/.dirstamp
0       0       algo/sha2/.dirstamp
0       0       algo/sha3/.dirstamp
0       0       algo/shabal/.dirstamp
0       0       algo/shavite/.dirstamp
0       0       algo/simd/.dirstamp
0       0       algo/simd/sse2/.dirstamp
0       0       algo/skein/.dirstamp
0       0       algo/tiger/.dirstamp
0       0       algo/whirlpool/.dirstamp
0       0       algo/x11/.dirstamp
0       0       algo/x13/.dirstamp
0       0       algo/x14/.dirstamp
0       0       algo/x15/.dirstamp
0       0       algo/x17/.dirstamp
0       0       algo/yescrypt/.dirstamp
0       50      comp.log
-       -       compat/gmp.del/x64/mpir.lib
-       -       compat/gmp.del/x86/mpir.lib
0       1928    compat/gmp.h.del

i suggest you edit .gitignore and add these lines :

Code:

.dirstamp
*.log
*.bak
*.new
*.del
*.del/

git rm <file>
git commit

I'm confused. Some of that stuff is just old trash I have to clean up but others like .dirstamp are already in .gitignore. Furthermore there
are no .dirstamp files in my original code. They were created by git, uploaded by git and not ignored by git.

Git also seems to have arbitrarilly deleted the m4 directory.

[Epsylon3]

once tracked, they are in git... gitignore just ignore the junk when you do git add

so you need to git rm & commit to remove that from git.

m4/ we dont care, we just "need" an empty folder (os specific stuff)