Author

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

legendary
Activity: 1470
Merit: 1114

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.
hero member
Activity: 700
Merit: 500

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)
legendary
Activity: 1470
Merit: 1114

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.
legendary
Activity: 1470
Merit: 1114
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.
member
Activity: 115
Merit: 10
Tip: 1JBSwRgm7iMzc7uyhnJdxH7hSECdJkdMoj

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
hero member
Activity: 700
Merit: 500
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
legendary
Activity: 1470
Merit: 1114
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.
legendary
Activity: 1470
Merit: 1114
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.
legendary
Activity: 1470
Merit: 1114
joblo XRE-Revolver Coin, algo - x11evo

collected so-
mingw64

Quote
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.
legendary
Activity: 1470
Merit: 1114
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.

newbie
Activity: 13
Merit: 0
MAC on FX-6300 Stop on block 50 - http://prnt.sc/e32czg  constantly
same picture on FX-8350
member
Activity: 85
Merit: 10
joblo XRE-Revolver Coin, algo - x11evo

collected so-
mingw64

Quote
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
full member
Activity: 327
Merit: 100
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 ).
legendary
Activity: 1470
Merit: 1114
I have collected 3.5.4-pre and checked on FX-6300, i3-2120  Angry

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?
member
Activity: 85
Merit: 10
I have collected 3.5.4-pre and checked on FX-6300, i3-2120  Angry

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

MAC on FX-6300 Stop on block 50 - http://prnt.sc/e32czg  constantly
full member
Activity: 144
Merit: 100
Eager to learn
yep , speed is correct and slightly increased

thx for fast response , good job done , great
legendary
Activity: 1470
Merit: 1114
unfortunatly updated from 3.5.3 to 3.5.4   aes avx CPU support is gone somewhere only sse2 shows up in  ( Mining with ) but on Pool´s Benchmark recognized as  AVX    ?

@ i7 2600

     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU:         Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
CPU features: SSE2 AES AVX
SW built on Feb  1 2017 with GCC 5.4.0
SW features: SSE2 AES AVX
Algo features: SSE2
Start mining with SSE2

[2017-02-01 04:37:35] Starting Stratum on stratum+tcp://yiimp.ccminer.org:3555
[2017-02-01 04:37:35] 8 miner threads started, using 'timetravel' algorithm.
[2017-02-01 04:37:36] Stratum difficulty set to 0.125 (0.00049)
[2017-02-01 04:37:36] timetravel block 389200, diff 1.817
[2017-02-01 04:37:38] CPU #1: 65.54 kH, 63.51 kH/s
[2017-02-01 04:37:38] CPU #0: 65.54 kH, 63.41 kH/s
[2017-02-01 04:37:38] CPU #2: 65.54 kH, 63.56 kH/s
[2017-02-01 04:37:38] CPU #3: 65.54 kH, 63.59 kH/s


OK I know what's wrong. I had to reorder some things for the command line option checking and now the CPU capabilities
check is done before the algo is registered so it doesn't know the algo's features. Speed should be correct for your CPU,
I need to rework that.

Edit: fixed in git, will be included in final release.
full member
Activity: 144
Merit: 100
Eager to learn
unfortunatly updated from 3.5.3 to 3.5.4   aes avx CPU support is gone somewhere only sse2 shows up in  ( Mining with ) but on Pool´s Benchmark recognized as  AVX    ?

@ i7 2600

     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU:         Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
CPU features: SSE2 AES AVX
SW built on Feb  1 2017 with GCC 5.4.0
SW features: SSE2 AES AVX
Algo features: SSE2
Start mining with SSE2

[2017-02-01 04:37:35] Starting Stratum on stratum+tcp://yiimp.ccminer.org:3555
[2017-02-01 04:37:35] 8 miner threads started, using 'timetravel' algorithm.
[2017-02-01 04:37:36] Stratum difficulty set to 0.125 (0.00049)
[2017-02-01 04:37:36] timetravel block 389200, diff 1.817
[2017-02-01 04:37:38] CPU #1: 65.54 kH, 63.51 kH/s
[2017-02-01 04:37:38] CPU #0: 65.54 kH, 63.41 kH/s
[2017-02-01 04:37:38] CPU #2: 65.54 kH, 63.56 kH/s
[2017-02-01 04:37:38] CPU #3: 65.54 kH, 63.59 kH/s
legendary
Activity: 1470
Merit: 1114
I'm doing something different with v3.5.4, I've submitted the code to git but haven't
built the binaries yet. There are two reasons, it's quicker and this release has a higher risk
of problems that I want to shake out.

v3.5.4 contains small code changes to many algos that will take forever to test. I'l wait about a
day for problem reports before making the formal release.

I'd also like confirmation on improvements, it's hard to tell when the improvement is well within
the margin of error.

- x11evo fixed (broken in v3.5.2) and optimized 23% faster
- Small improvements of 1% to 3% on many algos including timetravel,
   xevan and cryptonight.
- More code cleanup and compiler warning reduction.
- Improved checking for missing command line arguments.

https://github.com/JayDDee/cpuminer-opt
legendary
Activity: 1470
Merit: 1114
you can also toggle warnings per kind with CFLAGS :

-Wimplicit-function-declaration vs -Wno-implicit-function-declaration

but they are there for a good reason in general Wink

Agreed, I didn't want to disable them everywhere, just the block of code where I call the
registration functions because these implicit declarations aren't going away. I actually added some includes to
remove some of the others. Most of the remaining warnings are due to the optimized macros.
I'm going to have to do something about those.
Jump to: