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

[oldDIN]

I have collected 3.5.4-pre and checked on FX-6300, i3-2120  

XRE http://prnt.sc/e32b7c all rejected

MAC on FX-6300 Stop on block 50 - http://prnt.sc/e32czg  constantly

[joblo]

I have collected 3.5.4-pre and checked on FX-6300, i3-2120  

XRE http://prnt.sc/e32b7c all rejected

MAC on FX-6300 Stop on block 50 - http://prnt.sc/e32czg  constantly

Cryptonight works for me on i5-2400, same feature set as your i3 and same build.

1. How did you compile? What features were built? Did it work on 3.5.3?

2. That looks like a clean exit, like a timelimit. Did you use any options?

[Pennywis3]

Im using a few e5 2690 v2 ( 10 Core / 20 Threads ).

Using 12 threads for mining, geting about 580 h/s on Windows.
Am i doing something wrong? Anyway to speed this up? ( with Claymore i get about 740h/s ).

[oldDIN]

joblo XRE-Revolver Coin, algo - x11evo

collected so-
mingw64

git clone https://github.com/JayDDee/cpuminer-opt.git
cd cpuminer-opt
./autogen.sh
./configure CFLAGS="-Ofast -march=corei7-avx" CXXFLAGS="-Ofast -march=corei7-avx" --with-crypto --with-curl
make

[ivaness]

MAC on FX-6300 Stop on block 50 - http://prnt.sc/e32czg  constantly

same picture on FX-8350

[joblo]

MAC on FX-6300 Stop on block 50 - http://prnt.sc/e32czg  constantly

same picture on FX-8350

I missed the coin references in the first post

Problem 2: Stop at 50, both AMD, Both timetravel?

I don't have any AMD but works fine on my Intels.
I don't know what to say, I have no idea why it would do this. As it looks like a clean exit it seems the
program decided to exit but did not display a reason why.

Edit: I scanned the code and I can find no code that would exit based on the CPU, no code that would exit
after a certain number of share submits and no code that would exit without a message. In othrer words
it doesn't look like my code.

Lets start with where you got the code.

[joblo]

joblo XRE-Revolver Coin, algo - x11evo

collected so-
mingw64

git clone https://github.com/JayDDee/cpuminer-opt.git
cd cpuminer-opt
./autogen.sh
./configure CFLAGS="-Ofast -march=corei7-avx" CXXFLAGS="-Ofast -march=corei7-avx" --with-crypto --with-curl
make

problem1: x11evo all rejects

It works for me on my 15-2400. I noticed you used  -Ofast, recommended in -O3, as per build.sh.
try with -O3 instead. Also try with -march=native, it shouldn't make a difference but I'm stretching.

Edit: Also make sure its v3.5.4, x11evo was definitely broken in 3.5.3. Also try 3.5.1, last known working version.

[joblo]

Im using a few e5 2690 v2 ( 10 Core / 20 Threads ).

Using 12 threads for mining, geting about 580 h/s on Windows.
Am i doing something wrong? Anyway to speed this up? ( with Claymore i get about 740h/s ).

Optimum thread count for cryptonight is cache size in MB /  2. On an i7 ( 8 MB) 4 threads is best, an i5 (6 MB) 3 threads, etc,
You need 24 MB of cache for 12 threads, try reducing it to match your cache.

[joblo]

I will need to make a decision on releasing v3.5.4 based on the 2 reported problems.

1: x11evo all rejects

x11evo was broken in v3.5.3 so there is no regression. I have not been able to reproduce the problem
on a similar CPU. Unless this problem is bigger, seen by other users or if other algos are broken it
will not delay the release.

2. AMD CPUs exit after 50 submits

If this is a new problem in v3.5.4 it may affect the decision to release it. However, the
problem description is so unusual in that the symptoms indicate completely intentional
and normal behaviour by the program, but there is no code to make it behave like that.
It is notable it has been reported by 2 users. I don't have AMD CPUs to test with and can't
reproduce the problem on Intel. It is unlikely this will be resolved quickly. I will probably
proceed with the release unless new information points to a problem with the code.

[felixbrucker]

I will need to make a decision on releasing v3.5.4 based on the 2 reported problems.

1: x11evo all rejects

x11evo was broken in v3.5.3 so there is no regression. I have not been able to reproduce the problem
on a similar CPU. Unless this problem is bigger, seen by other users or if other algos are broken it
will not delay the release.

2. AMD CPUs exit after 50 submits

If this is a new problem in v3.5.4 it may affect the decision to release it. However, the
problem description is so unusual in that the symptoms indicate completely intentional
and normal behaviour by the program, but there is no code to make it behave like that.
It is notable it has been reported by 2 users. I don't have AMD CPUs to test with and can't
reproduce the problem on Intel. It is unlikely this will be resolved quickly. I will probably
proceed with the release unless new information points to a problem with the code.

i have 3 amd cpus on windows running cryptonight, i can test those if there is a bin (for the exit issue), with 3.5.3 they have been running for the last 21 hrs


as im not using timetravel and/or x11evo i cant test them right away, maybe someone gives a full commandline from their mining so i can test with their mining account data/worker

[Landy1264]

i have 3 amd cpus on windows running cryptonight, i can test those if there is a bin (for the exit issue), with 3.5.3 they have been running for the last 21 hrs

as im not using timetravel and/or x11evo i cant test them right away, maybe someone gives a full commandline from their mining so i can test with their mining account data/worker

I can provide this win .bat: cpuminer-corei7.exe -o stratum+tcp://yiimp.ccminer.org:3555 --algo="timetravel" --threads="4" --retry-pause="5" -u MHcS2Q24fk7dyyhyppToERgnfeEdKN2WcN -p c=MAC
Maybe you can get the needed info

[joblo]

I will need to make a decision on releasing v3.5.4 based on the 2 reported problems.

1: x11evo all rejects

x11evo was broken in v3.5.3 so there is no regression. I have not been able to reproduce the problem
on a similar CPU. Unless this problem is bigger, seen by other users or if other algos are broken it
will not delay the release.

2. AMD CPUs exit after 50 submits

If this is a new problem in v3.5.4 it may affect the decision to release it. However, the
problem description is so unusual in that the symptoms indicate completely intentional
and normal behaviour by the program, but there is no code to make it behave like that.
It is notable it has been reported by 2 users. I don't have AMD CPUs to test with and can't
reproduce the problem on Intel. It is unlikely this will be resolved quickly. I will probably
proceed with the release unless new information points to a problem with the code.

i have 3 amd cpus on windows running cryptonight, i can test those if there is a bin (for the exit issue), with 3.5.3 they have been running for the last 21 hrs


as im not using timetravel and/or x11evo i cant test them right away, maybe someone gives a full commandline from their mining so i can test with their mining account data/worker

Thanks for the offer Felix. If I'm going to build bins I'll likely just make it a full release and deal with the issues
in the next release. I'm going to give a little more time for more info from the original users or others but as
it stands I will release as is.

It doesn't look like I broke anything that wasn't already broken, which was my main reason for the pre-release.

[joblo]

i have 3 amd cpus on windows running cryptonight, i can test those if there is a bin (for the exit issue), with 3.5.3 they have been running for the last 21 hrs

as im not using timetravel and/or x11evo i cant test them right away, maybe someone gives a full commandline from their mining so i can test with their mining account data/worker

I can provide this win .bat: cpuminer-corei7.exe -o stratum+tcp://yiimp.ccminer.org:3555 --algo="timetravel" --threads="4" --retry-pause="5" -u MHcS2Q24fk7dyyhyppToERgnfeEdKN2WcN -p c=MAC
Maybe you can get the needed info

This won't be v3.5.4 but it will provide another data point: 3rd AMD user using previous release.

[felixbrucker]

i have 3 amd cpus on windows running cryptonight, i can test those if there is a bin (for the exit issue), with 3.5.3 they have been running for the last 21 hrs

as im not using timetravel and/or x11evo i cant test them right away, maybe someone gives a full commandline from their mining so i can test with their mining account data/worker

I can provide this win .bat: cpuminer-corei7.exe -o stratum+tcp://yiimp.ccminer.org:3555 --algo="timetravel" --threads="4" --retry-pause="5" -u MHcS2Q24fk7dyyhyppToERgnfeEdKN2WcN -p c=MAC
Maybe you can get the needed info

This won't be v3.5.4 but it will provide another data point: 3rd AMD user using previous release.

im running it as we speak, will see if 3.5.3 behaves the same

i have used the exact same commandline

edit: it also exited in 3.5.3

edit2: running the commandline without the thread and retry-pause params resulted in 54 accepted shares until it exited (i run it on a 8 core machine)

[joblo]

i have 3 amd cpus on windows running cryptonight, i can test those if there is a bin (for the exit issue), with 3.5.3 they have been running for the last 21 hrs

as im not using timetravel and/or x11evo i cant test them right away, maybe someone gives a full commandline from their mining so i can test with their mining account data/worker

I can provide this win .bat: cpuminer-corei7.exe -o stratum+tcp://yiimp.ccminer.org:3555 --algo="timetravel" --threads="4" --retry-pause="5" -u MHcS2Q24fk7dyyhyppToERgnfeEdKN2WcN -p c=MAC
Maybe you can get the needed info

This won't be v3.5.4 but it will provide another data point: 3rd AMD user using previous release.

im running it as we speak, will see if 3.5.3 behaves the same

i have used the exact same commandline

edit: it also exited in 3.5.3

Holy crap! It won't delay this release but this is a weird problem that will be difficult to debug.
Is this only with timetravel?

Try -D to get debug messages. Also try short form options and remove unnecessary ones just to
eliminate some variables.

[felixbrucker]

Is this only with timetravel?

its not happening in cryptonight, i have not tested other things (im using nicehash stratum for cryptonight)

Try -D to get debug messages. Also try short form options and remove unnecessary ones just to
eliminate some variables.

running right now, will post results with -D

[joblo]

Is this only with timetravel?

its not happening in cryptonight, i have not tested other things (im using nicehash stratum for cryptonight)

Try -D to get debug messages. Also try short form options and remove unnecessary ones just to
eliminate some variables.

running right now, will post results with -D

Thanks. I find no way an algo can cause the program to exit. It either returns with a share or without,
everything else is generic unless there's a crash.

[felixbrucker]

Is this only with timetravel?

its not happening in cryptonight, i have not tested other things (im using nicehash stratum for cryptonight)

Try -D to get debug messages. Also try short form options and remove unnecessary ones just to
eliminate some variables.

running right now, will post results with -D

Thanks. I find no way an algo can cause the program to exit. It either returns with a share or without,
everything else is generic unless there's a crash.

here is the output (ignore the weird symbols, have not used no colors option for logging)
http://pastebin.com/rt8CA4W9

at the bottom it exited and got restarted by my manager

[joblo]

Is this only with timetravel?

its not happening in cryptonight, i have not tested other things (im using nicehash stratum for cryptonight)

Try -D to get debug messages. Also try short form options and remove unnecessary ones just to
eliminate some variables.

running right now, will post results with -D

Thanks. I find no way an algo can cause the program to exit. It either returns with a share or without,
everything else is generic unless there's a crash.

here is the output (ignore the weird symbols, have not used no colors option for logging)
http://pastebin.com/rt8CA4W9

at the bottom it exited and got restarted by my manager

OK thanks. This issue will take a long time and I'll have to develop a strategy, so no quick fix.
I will need help from AMD users preferably those who originally reported the problem and
can compile their own so I can suggest adding some debugging code for testing.

[joblo]

I will need to make a decision on releasing v3.5.4 based on the 2 reported problems.

1: x11evo all rejects

x11evo was broken in v3.5.3 so there is no regression. I have not been able to reproduce the problem
on a similar CPU. Unless this problem is bigger, seen by other users or if other algos are broken it
will not delay the release.

2. AMD CPUs exit after 50 submits

If this is a new problem in v3.5.4 it may affect the decision to release it. However, the
problem description is so unusual in that the symptoms indicate completely intentional
and normal behaviour by the program, but there is no code to make it behave like that.
It is notable it has been reported by 2 users. I don't have AMD CPUs to test with and can't
reproduce the problem on Intel. It is unlikely this will be resolved quickly. I will probably
proceed with the release unless new information points to a problem with the code.

Update:

1. only reported by one user. Suspect wrong version was tested unless tested version is confirmed
to be 3.5.4.  v3.5.3 was known to be broken and produce rejects.

2. Confirmed issue with timetravel algo on AMD CPUs. However, it was also present in v3.5.3.
Debugging will take time.

With problem 1 being unconfirmed and having a plausible explanation and problem 2 being
non regressive the release will proceed and I will start building binaries.

The AMD/timetravel issue will be followed up later.