[ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 132.

scryptr

legendary

Activity: 1797

Merit: 1028

Quote from: joblo on September 25, 2016, 12:43:38 PM

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

legendary

Activity: 1470

Merit: 1114

Quote from: scryptr on September 25, 2016, 10:43:17 AM

Quote from: joblo on September 25, 2016, 10:26:08 AM

Quote from: scryptr on September 25, 2016, 09:33:03 AM

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

legendary

Activity: 1797

Merit: 1028

Quote from: joblo on September 25, 2016, 10:26:08 AM

Quote from: scryptr on September 25, 2016, 09:33:03 AM

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

legendary

Activity: 1470

Merit: 1114

Quote from: scryptr on September 25, 2016, 09:33:03 AM

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

legendary

Activity: 1797

Merit: 1028

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

Epsylon3

legendary

Activity: 1484

Merit: 1082

ccminer/cpuminer developer

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
git commit

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: th3.r00t on September 24, 2016, 01:13:04 PM

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 Cheesy

th3.r00t

sr. member

Activity: 312

Merit: 250

Quote from: felixbrucker on September 23, 2016, 02:55:48 PM

Quote from: Epsylon3 on September 23, 2016, 02:14:54 PM

nice to see users using the api

i like apis Cheesy

I like this WebUI!
Would mind sharing it?

Also your config regarding the API usage?

Thanks!

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on September 24, 2016, 08:34:57 AM

Quote from: felixbrucker on September 24, 2016, 04:15:57 AM

Quote from: joblo on September 23, 2016, 06:48:12 PM

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

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on September 24, 2016, 04:15:57 AM

Quote from: joblo on September 23, 2016, 06:48:12 PM

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

hero member

Activity: 700

Merit: 500

Quote from: joblo on September 23, 2016, 06:48:12 PM

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

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on September 23, 2016, 06:13:47 PM

Quote from: joblo on September 23, 2016, 06:12:03 PM

Quote from: felixbrucker on September 23, 2016, 06:01:40 PM

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

Quote from: joblo on September 23, 2016, 05:23:22 PM

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

hero member

Activity: 700

Merit: 500

Quote from: joblo on September 23, 2016, 06:12:03 PM

Quote from: felixbrucker on September 23, 2016, 06:01:40 PM

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

Quote from: joblo on September 23, 2016, 05:23:22 PM

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

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on September 23, 2016, 06:01:40 PM

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

Quote from: joblo on September 23, 2016, 05:23:22 PM

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

hero member

Activity: 700

Merit: 500

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

Quote from: joblo on September 23, 2016, 05:23:22 PM

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?

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: joblo on September 23, 2016, 03:07:02 PM

Quote from: felixbrucker on September 23, 2016, 02:08:39 PM

Quote from: joblo on September 23, 2016, 12:59:15 PM

I haven't made any changes to the API code but I looked through it and didn't see anything obvious. It should display
either net_diff if it's non-zero else stratum_diff. net-diff isn't used by cryptonight so it should display stratum_diff.
Don't know why it isn't.

i just confirmed its broken since 3.4.5 or 3.4.4b, 3.4.4 was working fine (though the stratum diff displayed was not 10k but 10000.016985)

The change in v3.4.5 was suggested by Nicehash to resolve issues with new work on cryptonight. I don't see an obvious link
to broken statum_diff. It will take some digging.

I have a fix. Although it's simple from a functional point of view the proper implementation involves code changes in 4 files.
However, there is a simple workaround you can use if you like.

In file cpu-miner.c line 2106

Code:

static void stratum_gen_work( struct stratum_ctx *sctx, struct work *work,
                              int thr_id )
{
    algo_gate.stratum_get_g_work( sctx, work, thr_id );
    if ( jsonrpc_2 ) return;                          // add this line
    if ( stratum_diff != sctx->job.diff )
    {
        char sdiff[32] = { 0 };
        // store for api stats
        stratum_diff = sctx->job.diff;
        if ( opt_showdiff && work->targetdiff != stratum_diff )
            snprintf( sdiff, 32, " (%.5f)", work->targetdiff );
        applog( LOG_WARNING, "Stratum difficulty set to %g%s", stratum_diff,
                            sdiff );
     }
}

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.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on September 23, 2016, 02:08:39 PM

Quote from: joblo on September 23, 2016, 12:59:15 PM

I haven't made any changes to the API code but I looked through it and didn't see anything obvious. It should display
either net_diff if it's non-zero else stratum_diff. net-diff isn't used by cryptonight so it should display stratum_diff.
Don't know why it isn't.

i just confirmed its broken since 3.4.5 or 3.4.4b, 3.4.4 was working fine (though the stratum diff displayed was not 10k but 10000.016985)

The change in v3.4.5 was suggested by Nicehash to resolve issues with new work on cryptonight. I don't see an obvious link
to broken statum_diff. It will take some digging.

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: Epsylon3 on September 23, 2016, 02:14:54 PM

nice to see users using the api

i like apis Cheesy

Epsylon3

legendary

Activity: 1484

Merit: 1082

ccminer/cpuminer developer

nice to see users using the api

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on September 23, 2016, 12:59:15 PM

I haven't made any changes to the API code but I looked through it and didn't see anything obvious. It should display
either net_diff if it's non-zero else stratum_diff. net-diff isn't used by cryptonight so it should display stratum_diff.
Don't know why it isn't.

i just confirmed its broken since 3.4.5 ~~or 3.4.4b~~, <=3.4.4b was working fine (though the stratum diff displayed was not 10k but 10000.016985)

Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 132. (Read 444040 times)