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

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: m1n1ngP4d4w4n on January 13, 2017, 05:29:05 PM

Thx for reply that fixed this issue. System is a bit old so probably some compilation error will show up that newer compiler will ignore probably or know how to fix auto.

I had another issue but i was able to fix it by looking on the web,

there was a compilation error

Quote

g++ -DHAVE_CONFIG_H -I. -Iyes/include -Iyes/include -fno-strict-aliasing -I. -Iyes/include -Iyes/include -g -O2 -MT algo/hodl/cpuminer-hodl.o -MD -MP -MF algo/hodl/.deps/cpuminer-hodl.Tpo -c -o algo/hodl/cpuminer-hodl.o `test -f 'algo/hodl/hodl.cpp' || echo './'`algo/hodl/hodl.cpp
In file included from /usr/include/c++/4.7/unordered_map:35:0,
from algo/hodl/hodl.cpp:8:
/usr/include/c++/4.7/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
make[2]: *** [algo/hodl/cpuminer-hodl.o] Error 1
make[2]: Leaving directory `/home/apps/cpuminer-opt'
make[1]: *** [all-recursive] Error 1

so i had to use manually and add compiler option

Quote

-std=c++0x

Quote

g++ -std=c++0x -DHAVE_CONFIG_H -I. -Iyes/include -Iyes/include -fno-strict-aliasing -I. -Iyes/include -Iyes/include -std=c++11 -g -O2 -MT algo/hodl/cpuminer-hodl.o -MD -MP -MF algo/hodl/.deps/cpuminer-hodl.Tpo -c -o algo/hodl/cpuminer-hodl.o `test -f 'algo/hodl/hodl.cpp' || echo './'`algo/hodl/hodl.cpp

now i have another one

Quote

cpuminer-cpu-miner.o: In function `check_cpu_capability':
cpu-miner.c:(.text+0x7b46): undefined reference to `set_incl'
cpu-miner.c:(.text+0x7b58): undefined reference to `set_incl'
cpu-miner.c:(.text+0x7b6a): undefined reference to `set_incl'
algo/argon2/cpuminer-argon2a.o: In function `argon2hash':
argon2a.c:(.text+0x21e): undefined reference to `argon_call'
algo/cpuminer-m7m.o: In function `swit2_':
m7m.c:(.text+0x1b5): undefined reference to `exp_n'
m7m.c:(.text+0x202): undefined reference to `exp_n'
collect2: error: ld returned 1 exit status

-std=gnu++11 is mentioned in the compile instructions. Check RELEASE_NOTES to see if you are missing something else.
Your latest errors make no sense, it's reporting undefined reference to a symbol that's defined in the same source file.

doktor83

hero member

Activity: 2548

Merit: 626

i have no problems compiling it on wheezy

m1n1ngP4d4w4n

full member

Activity: 224

Merit: 100

CryptoLearner

Thx for reply that fixed this issue. System is a bit old so probably some compilation error will show up that newer compiler will ignore probably or know how to fix auto.

I had another issue but i was able to fix it by looking on the web,

there was a compilation error

Quote

g++ -DHAVE_CONFIG_H -I. -Iyes/include -Iyes/include -fno-strict-aliasing -I. -Iyes/include -Iyes/include -g -O2 -MT algo/hodl/cpuminer-hodl.o -MD -MP -MF algo/hodl/.deps/cpuminer-hodl.Tpo -c -o algo/hodl/cpuminer-hodl.o `test -f 'algo/hodl/hodl.cpp' || echo './'`algo/hodl/hodl.cpp
In file included from /usr/include/c++/4.7/unordered_map:35:0,
from algo/hodl/hodl.cpp:8:
/usr/include/c++/4.7/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
make[2]: *** [algo/hodl/cpuminer-hodl.o] Error 1
make[2]: Leaving directory `/home/apps/cpuminer-opt'
make[1]: *** [all-recursive] Error 1

so i had to use manually and add compiler option

Quote

-std=c++0x

Quote

g++ -std=c++0x -DHAVE_CONFIG_H -I. -Iyes/include -Iyes/include -fno-strict-aliasing -I. -Iyes/include -Iyes/include -std=c++11 -g -O2 -MT algo/hodl/cpuminer-hodl.o -MD -MP -MF algo/hodl/.deps/cpuminer-hodl.Tpo -c -o algo/hodl/cpuminer-hodl.o `test -f 'algo/hodl/hodl.cpp' || echo './'`algo/hodl/hodl.cpp

now i have another one

Quote

cpuminer-cpu-miner.o: In function `check_cpu_capability':
cpu-miner.c:(.text+0x7b46): undefined reference to `set_incl'
cpu-miner.c:(.text+0x7b58): undefined reference to `set_incl'
cpu-miner.c:(.text+0x7b6a): undefined reference to `set_incl'
algo/argon2/cpuminer-argon2a.o: In function `argon2hash':
argon2a.c:(.text+0x21e): undefined reference to `argon_call'
algo/cpuminer-m7m.o: In function `swit2_':
m7m.c:(.text+0x1b5): undefined reference to `exp_n'
m7m.c:(.text+0x202): undefined reference to `exp_n'
collect2: error: ld returned 1 exit status

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: m1n1ngP4d4w4n on January 13, 2017, 04:40:48 PM

Hey joblo,

Im trying to compile cpuminer-opt v3.5.0 for a Intel(R) Xeon(R) CPU L3426 it support SSE2 and AES. Running debian wheezy, but the compiler always run into an error, wondering if you had some fix for it.

autogen & configure work properly no errors or warnings.

but when doing a make :

Quote

In file included from algo/hodl/hodl-gate.h:1:0,
from algo/hodl/hodl.cpp:2:
./algo-gate-api.h:126:49: error: using typedef-name ‘json_t’ after ‘struct’
In file included from ./miner.h:38:0,
from algo/hodl/hodl.cpp:1:
/usr/include/jansson.h:53:3: note: ‘json_t’ has a previous declaration here

Thanks

It looks like a stupid compile error that never seemed to get caught before. My compiler doesn't even generate a warning.

Code:

algo-gate-api.h line 126: bool ( *work_decode )            ( const struct json_t*, struct work* );

Take out the word struct from the json_t declaration, it's redundant because json_t is already a struct.
I made the change on my system and the compile didn't break.

Code:

algo-gate-api.h line 126: bool ( *work_decode )            ( const json_t*, struct work* );

m1n1ngP4d4w4n

full member

Activity: 224

Merit: 100

CryptoLearner

Hey joblo,

Im trying to compile cpuminer-opt v3.5.0 for a Intel(R) Xeon(R) CPU L3426 it support SSE2 and AES. Running debian wheezy, but the compiler always run into an error, wondering if you had some fix for it.

autogen & configure work properly no errors or warnings.

but when doing a make :

Quote

In file included from algo/hodl/hodl-gate.h:1:0,
from algo/hodl/hodl.cpp:2:
./algo-gate-api.h:126:49: error: using typedef-name ‘json_t’ after ‘struct’
In file included from ./miner.h:38:0,
from algo/hodl/hodl.cpp:1:
/usr/include/jansson.h:53:3: note: ‘json_t’ has a previous declaration here

Thanks

malafaya

sr. member

Activity: 490

Merit: 256

Quote from: joblo on January 12, 2017, 10:48:55 PM

Quote from: malafaya on January 12, 2017, 05:31:24 AM

I'm glad you found the problem. Now that you mention it, I also had lots of rejects mining vanilla at NiceHash, but at the time I "blamed" the compatibility between cpuminer-opt and NiceHash, just like with mining decred. In this case I just quit mining vanilla.

Thanks for your help, joblo!

Thank you for reporting this bug and for your help solving it. It was your observation that the thread count affected the reject rate
that was the major clue. It nice when someone puts some thought into reporting a problem.

No problem, joblo. I'm glad I could help.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: malafaya on January 12, 2017, 05:31:24 AM

I'm glad you found the problem. Now that you mention it, I also had lots of rejects mining vanilla at NiceHash, but at the time I "blamed" the compatibility between cpuminer-opt and NiceHash, just like with mining decred. In this case I just quit mining vanilla.

Thanks for your help, joblo!

Thank you for reporting this bug and for your help solving it. It was your observation that the thread count affected the reject rate
that was the major clue. It nice when someone puts some thought into reporting a problem.

joblo

legendary

Activity: 1470

Merit: 1114

v3.5.0 released.

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

Quote from: joblo on January 12, 2017, 01:38:19 PM

In this release I will be removing support for the SSE2 optimized Groestl function. This will affect
all algos that include Groestl in their chain but only on CPUs that don't support AES, ie core2.
These algos include all of the X chains, quark, lyra2re, nist5, xevan, hmq1725, myriad and groestl.
It will still be possible to mine these algos on a core2 CPU but at a lower hashrate. Mining these algos
with a CPU has not been viable for some time with the introduction of ASICs for most of them.

Anyone with a non-AES CPU who wishes to mine any of these algos should continue to use v3.4.12.
It will remain available for download as a legacy release.

v3.5.0 also makes stratum+tcp:// the default protocol so it is no longer necessary to specify it in the URL.
The blakcoin problem discussed above is also fixed.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: malafaya on January 12, 2017, 04:31:49 PM

Quote from: joblo on January 12, 2017, 01:38:19 PM

This is a heads up for upcoming release 3.5.0.

In this release I will be removing support for the SSE2 optimized Groestl function. This will affect
all algos that include Groestl in their chain but only on CPUs that don't support AES, ie core2.

...

Just a side note: I don't have a core2, but my i3 does not support AES (though it supports AVX):

Code:

         **********  cpuminer-opt 3.4.12  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     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) i3-3110M CPU @ 2.40GHz
CPU features: SSE2 AVX
SW built on Nov 28 2016 with GCC 4.8.3
SW features: SSE2
Algo features: SSE2 AES AVX AVX2

Thanks for the update.

You would likely see a speed reduction mining the affected algos with v3.5.0 but It's generally a bad idea to mine with a laptop.

malafaya

sr. member

Activity: 490

Merit: 256

Quote from: joblo on January 12, 2017, 01:38:19 PM

This is a heads up for upcoming release 3.5.0.

In this release I will be removing support for the SSE2 optimized Groestl function. This will affect
all algos that include Groestl in their chain but only on CPUs that don't support AES, ie core2.

...

Just a side note: I don't have a core2, but my i3 does not support AES (though it supports AVX):

Code:

         **********  cpuminer-opt 3.4.12  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     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) i3-3110M CPU @ 2.40GHz
CPU features: SSE2 AVX
SW built on Nov 28 2016 with GCC 4.8.3
SW features: SSE2
Algo features: SSE2 AES AVX AVX2

Thanks for the update.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on January 12, 2017, 02:27:59 PM

what is the upside of removing the sse2 code? im not mining any of those algos, just curious

No upside for users, no downside either, users can still use v3.4.12. I have no real desire to support old architectures
but I'll do it if it doesn't create more work for me. The SSE2 groestl code is a PITA.

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on January 12, 2017, 01:38:19 PM

This is a heads up for upcoming release 3.5.0.

In this release I will be removing support for the SSE2 optimized Groestl function. This will affect
all algos that include Groestl in their chain but only on CPUs that don't support AES, ie core2.
These algos include all of the X chains, quark, lyra2re, nist5, xevan, hmq1725, myriad and groestl.
It will still be possible to mine these algos on a core2 CPU but at a lower hashrate. Mining these algos
with a CPU has not been viable for some time with the introduction of ASICs for most of them.

Anyone with a non-AES CPU who wishes to mine any of these algos should continue to use v3.4.12.
It will remain available for download as a legacy release.

v3.5.0 also makes stratum+tcp:// the default protocol so it is no longer necessary to specify it in the URL.
The blakcoin problem discussed above is also fixed.

Coming soon.

what is the upside of removing the sse2 code? im not mining any of those algos, just curious

joblo

legendary

Activity: 1470

Merit: 1114

This is a heads up for upcoming release 3.5.0.

In this release I will be removing support for the SSE2 optimized Groestl function. This will affect
all algos that include Groestl in their chain but only on CPUs that don't support AES, ie core2.
These algos include all of the X chains, quark, lyra2re, nist5, xevan, hmq1725, myriad and groestl.
It will still be possible to mine these algos on a core2 CPU but at a lower hashrate. Mining these algos
with a CPU has not been viable for some time with the introduction of ASICs for most of them.

Anyone with a non-AES CPU who wishes to mine any of these algos should continue to use v3.4.12.
It will remain available for download as a legacy release.

v3.5.0 also makes stratum+tcp:// the default protocol so it is no longer necessary to specify it in the URL.
The blakcoin problem discussed above is also fixed.

Coming soon.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: evakka on January 12, 2017, 09:06:40 AM

Hi
At the moment I am mining Monero and FantomCoin (without extra cpu) via minergate with 5 CPU systems simultaneously for the same account.

I would also like to try cpuminer instead of minergate

Can you please share detailed instructions on how to accomplish this

BEWARE
Check at the left side
I am a Newbie Kiss

Thanks for the newbie warning.

Unfortunately using Minergate is not a good way to learn. It's a good way to mine without knowing anything.
The key concepts are the coin, the algo the pool and the miner. The miner connects to a pool to mine a coin using an algo.

The miner is a software program used to mine in a pool. Some miners use the CPU to mine, others use GPUs. cpuminer-opt
is a CPU miner. Different miner programs support different algos. Some only support one algo, other are multi-algo.

Monero coin uses the cryptonight algo. There are many different algos and even more different coins as many coins may use the
same algo. cpuminer-opt supports cryptonight.

Now read the instructions in the miner and any pool you want to mine on how to put all this together.

evakka

sr. member

Activity: 700

Merit: 265

Hi
At the moment I am mining Monero and FantomCoin (without extra cpu) via minergate with 5 CPU systems simultaneously for the same account.

I would also like to try cpuminer instead of minergate

Can you please share detailed instructions on how to accomplish this

BEWARE
Check at the left side
I am a Newbie Kiss

malafaya

sr. member

Activity: 490

Merit: 256

Quote from: joblo on January 11, 2017, 08:35:30 PM

Quote from: malafaya on January 11, 2017, 07:06:39 PM

Yes, "same result" = "same high reject count". Indeed, it points to something arch-related.

Actually, reported hashrate is about 30% higher with cpuminer-opt compared to cpuminer-multi (no SSE2 optimizations in multi, I believe). But with so many rejects, I have to stick to the latter.

Did you see the edit to my previous post? Also I checked the specs of the x5560 and it has 4/8 cores/threads. You said your system
has 24 threads, is it a multi CPU system? Is the number of CPUs a determining factor?

Edit: I found a bug in the code. Some data was not thread safe so one thread was ocasionally clobbbering the data of another. It's a race
condition that is more likely to fail with more threads. The bug affects blakecoin & vanilla.

Running multiple miner instances with fewer threads each should reduce the rejects until I get the fix released. However, the distribution
of threads may not be balanced so performance could be erratic.

Sorry, I hadn't seen your edit at the time.
I just tested what you suggested and it appears there is no problem when running 3 instances of the miner with 4 threads each: no rejects after 5 minutes, whereas a single instance of 12 threads generates >90% rejects.
And yes, it's a multi CPU system.

I'm glad you found the problem. Now that you mention it, I also had lots of rejects mining vanilla at NiceHash, but at the time I "blamed" the compatibility between cpuminer-opt and NiceHash, just like with mining decred. In this case I just quit mining vanilla.

Thanks for your help, joblo!

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: malafaya on January 11, 2017, 07:06:39 PM

Yes, "same result" = "same high reject count". Indeed, it points to something arch-related.

Actually, reported hashrate is about 30% higher with cpuminer-opt compared to cpuminer-multi (no SSE2 optimizations in multi, I believe). But with so many rejects, I have to stick to the latter.

Did you see the edit to my previous post? Also I checked the specs of the x5560 and it has 4/8 cores/threads. You said your system
has 24 threads, is it a multi CPU system? Is the number of CPUs a determining factor?

Edit: I found a bug in the code. Some data was not thread safe so one thread was ocasionally clobbbering the data of another. It's a race
condition that is more likely to fail with more threads. The bug affects blakecoin & vanilla.

Running multiple miner instances with fewer threads each should reduce the rejects until I get the fix released. However, the distribution
of threads may not be balanced so performance could be erratic.

malafaya

sr. member

Activity: 490

Merit: 256

Quote from: joblo on January 11, 2017, 06:34:30 PM

Quote from: malafaya on January 11, 2017, 04:53:40 PM

Quote from: joblo on January 11, 2017, 04:05:58 PM

Quote from: malafaya on January 11, 2017, 02:22:26 PM

I'm not sure what the cause is but I'm having trouble mining blakecoin algo with SSE2 version at ZPool. I get lots of rejects.
This does not happen in another AVX-capable machine, even with the SSE2 version of the miner.
tpruvot's cpuminer-multi-1.3 also works fine there.
After some tests, I think it may have to do with the number of threads used as reducing this number seems to reduce the problem (the other machine, the one working fine, has less logical CPUs: max 8 ).
This machine is a 24 logical CPUs X5560.

If I set the -D (debug) flag, I can confirm the share difficulty hash is correctly below the target.
What could the problem be?

edit: I purposely set difficulty low to generate a lot of shares in a small time. It's the same outcome if I set it adequately high.

I've never seen a problem like this before. I've seen interemittant rejects caused by a bug but not clusters of valid and rejected
shares. I've also never seen the number of threads ever cause rejects. There is only one implementation of blakecoin in
cpuminer-opt so there is no different code path on CPUs with AVX.

The fact that it works fine on another CPU in the same pool virtually isolates the problem to that system, eliminating both the
pool and the miner SW as the problem.

You can confirm this by trying different SW and different pools. I borrowed the blakecoin code from cpuminer-multi. Coincidentally
the developper is also the manager of the yiimp pool which has the blakecoin algo. If only that one CPU has problems I suspect a
problem with it or the RAM, Do you have ECC RAM? Has that system had other problems? Maybe run some tests, particularly stress
on the CPU to get it hot. Maybe the higher miner thread count is raising the temp and inducing more faults. Also moinitor the temp
to ensure it isn't overheating.

I also tried running it in two other systems with similar architecture (same SSE2-capable Xeon X5560 @ 2.80GHz, but just 16 logical processors) with the same result. Also temperature has never been an issue with other algos on that system, and I don't think it is with this one either: rejects start immediately after I start the miner. I can start reproducing the problem with as low as 8 threads (out of 24 max) although with a smaller proportion of rejects. Possibly a bug(?) in this CPU model? I guess I'll have to do with cpuminer-multi-1.3 for blakecoin in that specific machine.
Thank you for your input.

By "same result" do you mean that multiple machines with the same CPU arch are producing rejects? That would suggest a problem with
that specific arch. The thread count correlation indicates the problem is somehow load related, if not heat specifically.

cpuminer-multi will give the same performance as cpuminer-opt for blakecoin, if it works on that CPU.

Yes, "same result" = "same high reject count". Indeed, it points to something arch-related.

Actually, reported hashrate is about 30% higher with cpuminer-opt compared to cpuminer-multi (no SSE2 optimizations in multi, I believe). But with so many rejects, I have to stick to the latter.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: malafaya on January 11, 2017, 04:53:40 PM

Quote from: joblo on January 11, 2017, 04:05:58 PM

Quote from: malafaya on January 11, 2017, 02:22:26 PM

I'm not sure what the cause is but I'm having trouble mining blakecoin algo with SSE2 version at ZPool. I get lots of rejects.
This does not happen in another AVX-capable machine, even with the SSE2 version of the miner.
tpruvot's cpuminer-multi-1.3 also works fine there.
After some tests, I think it may have to do with the number of threads used as reducing this number seems to reduce the problem (the other machine, the one working fine, has less logical CPUs: max 8 ).
This machine is a 24 logical CPUs X5560.

If I set the -D (debug) flag, I can confirm the share difficulty hash is correctly below the target.
What could the problem be?

edit: I purposely set difficulty low to generate a lot of shares in a small time. It's the same outcome if I set it adequately high.

I've never seen a problem like this before. I've seen interemittant rejects caused by a bug but not clusters of valid and rejected
shares. I've also never seen the number of threads ever cause rejects. There is only one implementation of blakecoin in
cpuminer-opt so there is no different code path on CPUs with AVX.

The fact that it works fine on another CPU in the same pool virtually isolates the problem to that system, eliminating both the
pool and the miner SW as the problem.

You can confirm this by trying different SW and different pools. I borrowed the blakecoin code from cpuminer-multi. Coincidentally
the developper is also the manager of the yiimp pool which has the blakecoin algo. If only that one CPU has problems I suspect a
problem with it or the RAM, Do you have ECC RAM? Has that system had other problems? Maybe run some tests, particularly stress
on the CPU to get it hot. Maybe the higher miner thread count is raising the temp and inducing more faults. Also moinitor the temp
to ensure it isn't overheating.

I also tried running it in two other systems with similar architecture (same SSE2-capable Xeon X5560 @ 2.80GHz, but just 16 logical processors) with the same result. Also temperature has never been an issue with other algos on that system, and I don't think it is with this one either: rejects start immediately after I start the miner. I can start reproducing the problem with as low as 8 threads (out of 24 max) although with a smaller proportion of rejects. Possibly a bug(?) in this CPU model? I guess I'll have to do with cpuminer-multi-1.3 for blakecoin in that specific machine.
Thank you for your input.

By "same result" do you mean that multiple machines with the same CPU arch are producing rejects? That would suggest a problem with
that specific arch. The thread count correlation indicates the problem is somehow load related, if not heat specifically.

cpuminer-multi will give the same performance as cpuminer-opt for blakecoin, if it works on that CPU.

Edit: the problem could be purely reated to the number of threads. I would like you to do a few tests.

Find the max number of threads that run without rejects. Then try running two instances of cpuminer,
each instance with the max stable thread count. Make sure the first instance is stable before starting the second.

This will determine if the problem is the number of threads on the CPU of the number of threads in the process.

malafaya

sr. member

Activity: 490

Merit: 256

Quote from: joblo on January 11, 2017, 04:05:58 PM

Quote from: malafaya on January 11, 2017, 02:22:26 PM

I'm not sure what the cause is but I'm having trouble mining blakecoin algo with SSE2 version at ZPool. I get lots of rejects.
This does not happen in another AVX-capable machine, even with the SSE2 version of the miner.
tpruvot's cpuminer-multi-1.3 also works fine there.
After some tests, I think it may have to do with the number of threads used as reducing this number seems to reduce the problem (the other machine, the one working fine, has less logical CPUs: max 8 ).
This machine is a 24 logical CPUs X5560.

If I set the -D (debug) flag, I can confirm the share difficulty hash is correctly below the target.
What could the problem be?

edit: I purposely set difficulty low to generate a lot of shares in a small time. It's the same outcome if I set it adequately high.

I've never seen a problem like this before. I've seen interemittant rejects caused by a bug but not clusters of valid and rejected
shares. I've also never seen the number of threads ever cause rejects. There is only one implementation of blakecoin in
cpuminer-opt so there is no different code path on CPUs with AVX.

The fact that it works fine on another CPU in the same pool virtually isolates the problem to that system, eliminating both the
pool and the miner SW as the problem.

You can confirm this by trying different SW and different pools. I borrowed the blakecoin code from cpuminer-multi. Coincidentally
the developper is also the manager of the yiimp pool which has the blakecoin algo. If only that one CPU has problems I suspect a
problem with it or the RAM, Do you have ECC RAM? Has that system had other problems? Maybe run some tests, particularly stress
on the CPU to get it hot. Maybe the higher miner thread count is raising the temp and inducing more faults. Also moinitor the temp
to ensure it isn't overheating.

I also tried running it in two other systems with similar architecture (same SSE2-capable Xeon X5560 @ 2.80GHz, but just 16 logical processors) with the same result. Also temperature has never been an issue with other algos on that system, and I don't think it is with this one either: rejects start immediately after I start the miner. I can start reproducing the problem with as low as 8 threads (out of 24 max) although with a smaller proportion of rejects. Possibly a bug(?) in this CPU model? I guess I'll have to do with cpuminer-multi-1.3 for blakecoin in that specific machine.
Thank you for your input.

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