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

[joblo]

i can test it if there is a full cmdline

i have somewhat lost track of all the different problems and version that should fix/be tested against, so a brief summary with the cmd to test would be great as well

You can test x11evo with 3.5.4 at zpool with any btc address.

./cpuminer -a x11evo -o stratum+tcp://x11evo.mine.zpool.ca:3553 -u [btc addr] -p test

Testing timetravel needs the change in 3.5.5-pre (latest git). It is only for the purposes of testing timetravel on AMD CPUs
and is only available as source code.

If testing drags on I can build a bin of 3.5.5-pre specifically for you, just let me know which arch you need.

[1713556191]

1713556191

[1713556191]

1713556191

[1713556191]

1713556191

[felixbrucker]

i can test it if there is a full cmdline

i have somewhat lost track of all the different problems and version that should fix/be tested against, so a brief summary with the cmd to test would be great as well

You can test x11evo with 3.5.4 at zpool with any btc address.

./cpuminer -a x11evo -o stratum+tcp://x11evo.mine.zpool.ca:3553 -u [btc addr] -p test

Testing timetravel needs the change in 3.5.5-pre (latest git). It is only for the purposes of testing timetravel on AMD CPUs
and is only available as source code.

If testing drags on I can build a bin of 3.5.5-pre specifically for you, just let me know which arch you need.

just tested x11evo on zpool, all rejects (at a very high speed)

first it takes about 30 sec and then there are 800+ instantly rejected shares and a lot of output ( i have configured my stdout/stderr log file parsing to be rotated every 50mb file size and it somehow crashed that )

starting with -D didnt seem to reveal anything special, i can upload the 38MB logfile of the first wave of rejects with -D to pastebin if neccessary

i have not used x11evo before, speed was shown as 10MH/s (not sure if thats normal)

also this test was on intel cpu, nothing amd related

[joblo]

i can test it if there is a full cmdline

i have somewhat lost track of all the different problems and version that should fix/be tested against, so a brief summary with the cmd to test would be great as well

You can test x11evo with 3.5.4 at zpool with any btc address.

./cpuminer -a x11evo -o stratum+tcp://x11evo.mine.zpool.ca:3553 -u [btc addr] -p test

Testing timetravel needs the change in 3.5.5-pre (latest git). It is only for the purposes of testing timetravel on AMD CPUs
and is only available as source code.

If testing drags on I can build a bin of 3.5.5-pre specifically for you, just let me know which arch you need.

just tested x11evo on zpool, all rejects (at a very high speed)

first it takes about 30 sec and then there are 800+ instantly rejected shares and a lot of output ( i have configured my stdout/stderr log file parsing to be rotated every 50mb file size and it somehow crashed that )

starting with -D didnt seem to reveal anything special, i can upload the 38MB logfile of the first wave of rejects with -D to pastebin if neccessary

i have not used x11evo before, speed was shown as 10MH/s (not sure if thats normal)

also this test was on intel cpu, nothing amd related

What arch? Hash rate should be similar to my post above.

[felixbrucker]

well if no linux amd user chimes in a bin would be great

arch wise im using the corei7-avx, also for the last x11evo tests, should i try with sse2 bin (x11evo)?

the x11evo problem should be reproducable, or am i wrong?

edit: just saw your x11evo output, very strange, same capabilities

edit2: also happening with sse2 bin

edit3: seems to be a windows issue, running fine on my linux server (xeon e3-1265lv2), not working on 3 amd/intel windows boxes

[joblo]

well if no linux amd user chimes in a bin would be great

arch wise im using the corei7-avx, also for the last x11evo tests, should i try with sse2 bin (x11evo)?

the x11evo problem should be reproducable, or am i wrong?

edit: just saw your x11evo output, very strange, same capabilities

Yes very strange. You used bins I made so it's the same compiler version and I actually have the right
CPU to reproduce the problem.

- 3 users with same arch, 2 fail , one ok
- one fail on Linux, other on Win
- fail and ok in same pool

I can find no delta between the success and failures, I'm stuck.

While I'm stuck I'll build 3.5.5-pre-corei7-avx for you. Will PM link.

[oldDIN]

-MAC-
3.5.5-pre git corei7-avx - 50 off
3.5.5-pre with a change git code - works

-x11evo-
Rebuild 3.5.5-pre git
Intel - works
AMD - rejections after the first cache

[joblo]

-MAC-
3.5.5-pre git corei7-avx - 50 off
3.5.5-pre with a change git code - works

-x11evo-
Rebuild 3.5.5-pre git
Intel - works
AMD - rejections after the first cache

Thanks. MAC looks good I will proceed with the full fix in the next release.

Now about x11evo, I'm sorry I doubted your testing but as you can see I had to be absolutely sure.
I need to find some way of reproducing it and as the previous post said, I'm stuck.

You can continue to use 3.5.5-pre for MAC until the next release, for x11evo use
3.5.4 if you can (it's faster), or 3.5.1 if not until the problem is solved.

[joblo]

edit2: also happening with sse2 bin

edit3: seems to be a windows issue, running fine on my linux server (xeon e3-1265lv2), not working on 3 amd/intel windows boxes

Awsome data. All failures are Windows on AMD CPUs, everything else works.
Now there's a delta. I can put my thinking cap back on.

Edit: ignore that I misread slightly.

You report failure on Windows Intel and AMD, working on Intel Linux.

OldDIN reports Linux fail on AMD, ok on Intel.

It looks more like all failures are on AMD. Your testing doesn't have Linux/AMD but oldDIN
filled that void.

Clearly an AMD issue and likely related to the timetravel issue where it failed only on AMD.
Now I got a lead to follow.

[felixbrucker]

edit2: also happening with sse2 bin

edit3: seems to be a windows issue, running fine on my linux server (xeon e3-1265lv2), not working on 3 amd/intel windows boxes

Awsome data. All failures are Windows on AMD CPUs, everything else works.
Now there's a delta. I can put my thinking cap back on.

I think this also relates to the other issue as it was also AMD related. In that case a macro was messing up timetravel
on AMD but it worked ok on Intel. There may be something similar going on with x11evo.

well its also broken for intel on windows for me (i5-3330) so it cant be specific to amd (x11evo)

i just tested the bin you sent me, it also exits on 50 accepted shares, is that expected?

[joblo]

edit2: also happening with sse2 bin

edit3: seems to be a windows issue, running fine on my linux server (xeon e3-1265lv2), not working on 3 amd/intel windows boxes

Awsome data. All failures are Windows on AMD CPUs, everything else works.
Now there's a delta. I can put my thinking cap back on.

I think this also relates to the other issue as it was also AMD related. In that case a macro was messing up timetravel
on AMD but it worked ok on Intel. There may be something similar going on with x11evo.

well its also broken for intel on windows for me (i5-3330) so it cant be specific to amd (x11evo)

i just tested the bin you sent me, it also exits on 50 accepted shares, is that expected?

No. OldDIN reported ok. Maybe I sent you the wrong code, Let me check.

Edit: I looked at the exact source I used to build your test load and it is correct.

I removed the macro that caused me problems with x11evo.

It seems if the bench stats collection runs on an AMD CPU mining timetravel the miner will exit.

The easy workaround is to disable stats, which I intend to do by default in the next release.

Finding root cause is impossible until I can reproduce it.

The swap macro failed for me on x11evo but worked on timetravel. I still don't understand why but it
led me to believe there is a problem using that macro in some situations, particularly on AMD.
I therefore removed the macro from timetravel in 3.5.5-pre. Now oldDIN reports testintg ok but you still report
miner exit after 50 submits.

oldDIN can you confirm cpu-miner.c is the same in 3.5.5-pre as 3.5.4?

Code:

diff cpuminer-opt-3.5.4/cpu-miner.c cpuminer-opt-3.5.5-pre/cpu-miner.c

In 3.5.5-pre opt_stratum_stats should be initialized to true and never changed, the same as it was
in 3.5.4. The only significant change is in timetravel.

Here's the diff from git...

https://github.com/JayDDee/cpuminer-opt/commit/977415a25bc13cf4fd871f50cf82a75eb8a5cde8

[felixbrucker]

i could be wrong, but i believe his test which was working was with the rpc user/pass stats/benchmark lines added to not enable the benchmark submit

[joblo]

i could be wrong, but i believe his test which was working was with the rpc user/pass stats/benchmark lines added to not enable the benchmark submit

Yes that's an invalid test because it avoids the problem by not running the stats. The stats need to run
at 50 submits and not exit for the test to be successful.

[joblo]

A status summary just to make sure I keep my head straight.
Scrutinize my assertions to confirm you agree.

1. x11evo problem has been identified as an AMD only issue, still unresolved.

2. timetravel problem was believed to be fixed with 3.5.5-pre but felixbrucker
reports it fails on AMD/Win and works on Intel/Linux. oldDIN reports 3.5.5-pre
fails on Intel/Linux. This contradicts my results where it works on Intel/Linux.

The current discrepency is with timetravel using 3.5.5-pre on Intel/Linux.
Need to doublecheck those results as requested in previous post.

[felixbrucker]

A status summary just to make sure I keep my head straight.
Scrutinize my assertions to confirm you agree.

1. x11evo problem has been identified as an AMD only issue, still unresolved.

2. timetravel problem was believed to be fixed with 3.5.5-pre but felixbrucker
reports it fails on AMD/Win and works on Intel/Linux. oldDIN reports 3.5.5-pre
fails on Intel/Linux. This contradicts my results where it works on Intel/Linux.

The current discrepency is with timetravel using 3.5.5-pre on Intel/Linux.
Need to doublecheck those results as requested in previous post.

1.1 x11evo is reported broken in amd on windows, intel on windows
1.2 x11evo is reported working in intel on linux

2.1 timetravel exits on 3.5.5-pre and below (3.5.3 and 3.5.4 tested) on amd on windows
2.2 timetravel does not exit on intel on windows and intel on linux

[oldDIN]

Again, it seems you got me all wrong, English is not my

W7-64-pro

MAC- AMD Intel
Git miner exit after 50 submits.
Git + code change in cpu-miner.c - work

Code:

if (rpc_pass && rpc_user)
     opt_stratum_stats &= (strstr(rpc_pass, "stats") != NULL) || (strcmp(rpc_user, "benchmark") == 0);

I collected everything under the window, not under linux (( Excuse me, I did not say immediately

[felixbrucker]

W7-64-pro AMD Intel

just to clarify: are you using intel or amd, or is it exiting on both on windows?

[oldDIN]

2 computers, old -Intel, newer - AMD

[felixbrucker]

2 computers, old -Intel, newer - AMD

that would be something new: exiting also on intel (on windows)

[joblo]

Again, it seems you got me all wrong, English is not my

W7-64-pro

MAC- AMD Intel
Git miner exit after 50 submits.
Git + code change in cpu-miner.c - work

Code:

if (rpc_pass && rpc_user)
     opt_stratum_stats &= (strstr(rpc_pass, "stats") != NULL) || (strcmp(rpc_user, "benchmark") == 0);

I collected everything under the window, not under linux (( Excuse me, I did not say immediately

Thanks for the clarification. Let me absorb it for a bit so I can understand.

Edit: OK the git test is valid but the git+code change test is invalid because stats collection was disabled.
The conclusion is the change I made in 3.5.5-pre (git) did not fix the problem. Is that correct?

[felixbrucker]

Again, it seems you got me all wrong, English is not my

W7-64-pro

MAC- AMD Intel
Git miner exit after 50 submits.
Git + code change in cpu-miner.c - work

Code:

if (rpc_pass && rpc_user)
     opt_stratum_stats &= (strstr(rpc_pass, "stats") != NULL) || (strcmp(rpc_user, "benchmark") == 0);

I collected everything under the window, not under linux (( Excuse me, I did not say immediately

Thanks for the clarification. Let me absorb it for a bit so I can understand.

Edit: OK the git test is valid but the git+code change test is invalid because stats collection was disabled.
The conclusion is the change I made in 3.5.5-pre (git) did not fix the problem. Is that correct?

a yes from me (judging from the git pre bin you sent)

i can give you teamviewer access to one amd windows machine for rapid testing if neccessary