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

I'm trying to understand what the change does.

Edit: it looks like opt_stratum_stats default will always be overridden by your code change. Also there is no command line
arg for the user to change it, and even if there was your code would always override it. It doesn't look right.

Edit: I've changed your code to do  &= instead of = to prevent it from overriding a previous disable setting.
Not pushed to git and not included in 3.5.5-pre.


But it still needs a command line option be implemented to allow users to enable stats.
And I still don't know what this code does.

by default its disabled in my miners, only -p stats allow it or -p "c=MAC,stats" etc

So your suggested code change enables the miner to ignore the request?

the pool always asks for stats at 50 100 150 and 200 shares, but the miner can ignore the request...

I just pushed a change to git that restores the old swap function. Awaiting test results.

I  still can't connect how stats collection triggers the problem with the macro even though
it's clear there is a problem with it. It's also not clear why it works on timetravel on Intel CPUs,
works for a while on AMD and doesn't work at all on x11evo. Bizarre.

Epsylon3, regarding the change you suggested, how does it affect things? Have there been
problems with stats collection from Intel CPUs?

I think I might be getting part of the picture. I found no mention of 50 submits in the miner code so I presume
it comes from the pool. I assume the pool requests the data after 50 submits in the session.

I can't yet connect it to AMD or timetravel or the program exiting.

After a quick look at the stratum code it doesn't look like it would exit or exit without a message
if stats fail. I also didn't find anything that would single out AMD other than reporting it in the stats.
And I didn't find anything that would connect to timetravel other than simly reporting it.

It looks like we found the trigger only. Removing the trigger may make the problem disappear for
now but I think this needs to be understood better.

I do have a lead in this area. Timetravel has a local function to swap 2 variables using a temp. I replaced
it with an oiptimized version that doesn't require the use of a temp. X11evo has a similar function and when
I tried to implement the optimized version it segfaulted. I'm wondering if there is a macro issue affecting
operator precedence. I've never had a good understanding of all the parentheses needed in c but it seems
like I should encapsulate the args in the macro...



I'd like to leave the trigger in place  to help get to the root problem.

Edit:

It still segfaults on x11evo with the macro change so it's a problem with the macro. This makes the
connection to timetravel. There is still no connection to AMD. That technique for swapping variables is tried and
true so it's starting to look like a compiler issue, possibly related to passing an expression as the arg instead
of a simple arg. Encapsulating the args should ensure they are fully evaluated before being used by the macro.
That this macro also has problems on Intel suggests it's not limited to AMD. Encapsulating the macro's args
should have eliminated any expansion weirdness due to the args being expressions rather than simple variables.
It's starting to look like the compiler messed up unless I missing something.

Any thoughts on passing expressions as arguments to macros?

Edit: more weird behaviour. Evaluating the args to local variables then passing the variables to the macro changed the
behaviour. It no longer crashed but produced only rejects. This change had an effect but it disn't fix iteven though the
change should have had no effect. It looks like this macro is cursed.

nice find, just checked yiimp, no amd stats available

50 ... the benchmark submit ?

about that, its nice to receive all your bench stats guys, but joblo, could you add the "stats" presence check in the password to enable/allow it

https://github.com/tpruvot/cpuminer-multi/blob/linux/cpu-miner.c#L3446

The plot thickens. It means the problem is in the miner. A silent crash seems more likely. I had thought
of an incompatibility with some optimized code but you eliminated that. That it happens only with
timetravel means it probably crashed in timetravel code. Much of that code is cloned from other algos so
I will focus on the code that is unique.

cpuminer-multi 1.3.1 x64 (referenced in the mac thread) does not exit on my amd ( but is a lot slower )

This can be a starting point for the investigation into the problem of the miner exiting after
50 submits when mining timetravel algo using an AMD CPU:

Problem description:

- silent exit after 50 submits
- only timetravel algo and AMD CPU
- multiple CPUs and architectures (SSE2 only or AES/AVX)
- reproduced by 3 users in versions 3.5.3 and 3.5.4

Analysis:

- there is no code to discriminate based on CPU type.
- there is no code to discriminate based on algo
- there is no code that makes decisions based on share count
- there is no code that exits voluntarilly without displaying a message
- other than a crash there is no timetravel specific code that can cause the program to exit

Based on the analysis above the only possibilities are a silent crash or an external event.
Reproducing the problem with SSE2 only eliminates a crash due to AES or AVX instructions.
A silent crash in timetravel code is still a remote possibility, but why only AMD.

An external event seems like a long shot but must be considered. That external force would
need to know the share count so that eliminates any other local software. The only entity
other than the miner itself that has this knowledge is the pool through the stratum connection.

I don't know if it is possible for the remote stratum server to somehow instruct or cause the miner
to exit and if so whether the miner would do so silently.

Plan:

I will do more analysis of the stratum code to see if it could exit silently.

I would like users to test using other timetravel miners on AMD CPUs. There is cpuminer-multi as
well as one or two others mentioned in the machinecoin thread

For Linux users it would be worth testing with gdb. At least with a backtrace we can see where the
program exited.

@joblo, i also just tested the amd issue with a sse2 bin, same problem, so its not some aes or avx code stuff (which amd might have done differently)

OK, so I didn't check the specs before replying. I just answered your question directly, what you could be doing wrong.

You also could have mentioned the cache size in your OP knowing it was important. You could also have mentioned what
version and whether there is a change from previous versions, or if this is your first time, dude.

It helps if you list the possibilities you eliminated, comparing CPU usage etc. To the best of my knowledge Claymore
performs slightly better than cpuminer-opt on cryptonight but most of that has been using 2 channel memory.
I don't know how they compare with 4 channels. Has he released a new faster version?

e5 2690 v2 has 25MB of cache

Well, ill try to figure something out.

cpuminer-opt v3.5.4 is released.

- 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.

Errata: AMD users have reported the miner exits silently after 50 share submissions
when mining timetravel algo. This problem is also present in previous versions
and is under investigation.

https://bitcointalksearch.org/topic/m.13542056

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.

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.

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

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.

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


running right now, will post results with -D