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

[felixbrucker]

Hi joblo,

i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)

i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.

would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.


cheers

[joblo]

Hi joblo,

i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)

i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.

would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.


cheers

Failover can be easilly implemented using a shell script and "cpuminer -r 0". It can do exactly as you suggest.

[felixbrucker]

Hi joblo,

i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)

i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.

would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.


cheers

Failover can be easilly implemented using a shell script and "cpuminer -r 0". It can do exactly as you suggest.

i fail to see how this would allow automatic switching to the main pool after recovery (one may be able to just restart the whole miner (script) every n minutes to achieve this, but thats just ugly)

to achieve this one has to monitor the "main" pool and all other backup pools for availability and switch back to the higher prio one if recovered

of course i might be able to run a single miner on the main pool and detect the failed connection via stdout/err passing and start another (second) miner using the second pool while still running the (not connecting) main miner and killing all other miners if the main miner reconnects, but thats also very ugly


am i missing something here?

[minerbaba]

Need help

http://imgur.com/a/hVijU

[K1lo]

What is your CPU? I suspect it doesn't support AVX2 instructions.

[minerbaba]

What is your CPU? I suspect it doesn't support AVX2 instructions.

i5 4670

[K1lo]

What is your CPU? I suspect it doesn't support AVX2 instructions.

i5 4670

Well according to http://ark.intel.com/products/75047/Intel-Core-i5-4670-Processor-6M-Cache-up-to-3_80-GHz your CPU supports AVX2. Have you tried one of the other mining binaries? Have you tried to benchmark scrypt without doing any actual mining?

Perhaps you've got a program on your machine interfering with the miner, or your hardware is a bit wonky or you've found a bug in the miner causing by your parameters.

[joblo]

Need help

Only stratum mining is supported.

Edit: The algo may also be a problem. Only default scrypt has been tested and known to work.

[joblo]

Hi joblo,

i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)

i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.

would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.


cheers

Failover can be easilly implemented using a shell script and "cpuminer -r 0". It can do exactly as you suggest.

i fail to see how this would allow automatic switching to the main pool after recovery (one may be able to just restart the whole miner (script) every n minutes to achieve this, but thats just ugly)

to achieve this one has to monitor the "main" pool and all other backup pools for availability and switch back to the higher prio one if recovered

of course i might be able to run a single miner on the main pool and detect the failed connection via stdout/err passing and start another (second) miner using the second pool while still running the (not connecting) main miner and killing all other miners if the main miner reconnects, but thats also very ugly


am i missing something here?

What you are asking is more than I am willing to do just for fun.

With a shell script you can put a timelimit on the backup pool. You won't detect exactly ewhen the primary pool recovers but you're
still mining something until the backup times out. If the primary pool is still down it will immediately switch back to the backup.
It's not perfect but I don't see the feasibility in going the next step. I don't see pool failures as a big problem and I don't see much
gain from smoothing out the failure/recovery. The overhead of restarting the miner is trivial.

What exactly do you expect to gain? 

[felixbrucker]

Hi joblo,

i just noticed there is no note of failover support, is this possible already? (just use multiple stratum addresses etc like claymore miners do)

i checked ccminer (which cli parameters are very similar) which has one note of failover support back from 2015, but it seems this is only possible via config file.

would be a great addition to the miner to have failover support/define multiple pools via cli and they are getting used in the order they are appended.


cheers

Failover can be easilly implemented using a shell script and "cpuminer -r 0". It can do exactly as you suggest.

i fail to see how this would allow automatic switching to the main pool after recovery (one may be able to just restart the whole miner (script) every n minutes to achieve this, but thats just ugly)

to achieve this one has to monitor the "main" pool and all other backup pools for availability and switch back to the higher prio one if recovered

of course i might be able to run a single miner on the main pool and detect the failed connection via stdout/err passing and start another (second) miner using the second pool while still running the (not connecting) main miner and killing all other miners if the main miner reconnects, but thats also very ugly


am i missing something here?

What you are asking is more than I am willing to do just for fun.

With a shell script you can put a timelimit on the backup pool. You won't detect exactly ewhen the primary pool recovers but you're
still mining something until the backup times out. If the primary pool is still down it will immediately switch back to the backup.
It's not perfect but I don't see the feasibility in going the next step. I don't see pool failures as a big problem and I don't see much
gain from smoothing out the failure/recovery. The overhead of restarting the miner is trivial.

What exactly do you expect to gain? 

i plan to somehow enable pools to be configured with priorities in my own software (currently miner-manager, but somewhere soon an aio management software should replace all the different programs i have written)

ideally i configure a device (that is a rig/computer) to have miners and mining groups which have a set of pools configured to use. These pools have priorities (eg. 1, 10, 30) and also autoswitching for nicehash pools is just another pool in this list.

for example i plan to configure nicehash autoswitching pools to be prio 10, some other backup pool (maybe mph) with 20. I might also add another temporary pool on which i want to mine just shortly with prio 5 and disable it later on. in any case one of the stratums goes down, the miner should switch to the next pool in prio order.


im not very familiar with stratum and the details of how to communicate with it but from what ive read its just json rpc over sockets, so i *could* query the pool status myself *somehow* (dont know which methods are enough to verify stratum is working) and just create a stratum checker module my software uses

[joblo]

i plan to somehow enable pools to be configured with priorities in my own software (currently miner-manager, but somewhere soon an aio management software should replace all the different programs i have written)

ideally i configure a device (that is a rig/computer) to have miners and mining groups which have a set of pools configured to use. These pools have priorities (eg. 1, 10, 30) and also autoswitching for nicehash pools is just another pool in this list.

for example i plan to configure nicehash autoswitching pools to be prio 10, some other backup pool (maybe mph) with 20. I might also add another temporary pool on which i want to mine just shortly with prio 5 and disable it later on. in any case one of the stratums goes down, the miner should switch to the next pool in prio order.


im not very familiar with stratum and the details of how to communicate with it but from what ive read its just json rpc over sockets, so i *could* query the pool status myself *somehow* (dont know which methods are enough to verify stratum is working) and just create a stratum checker module my software uses

It would be possible for you to add a stratum checker to a miner manager but the miner will still create
its own conection. Every miner does this, changing it requires changing every miner you want to support.

[felixbrucker]

i plan to somehow enable pools to be configured with priorities in my own software (currently miner-manager, but somewhere soon an aio management software should replace all the different programs i have written)

ideally i configure a device (that is a rig/computer) to have miners and mining groups which have a set of pools configured to use. These pools have priorities (eg. 1, 10, 30) and also autoswitching for nicehash pools is just another pool in this list.

for example i plan to configure nicehash autoswitching pools to be prio 10, some other backup pool (maybe mph) with 20. I might also add another temporary pool on which i want to mine just shortly with prio 5 and disable it later on. in any case one of the stratums goes down, the miner should switch to the next pool in prio order.


im not very familiar with stratum and the details of how to communicate with it but from what ive read its just json rpc over sockets, so i *could* query the pool status myself *somehow* (dont know which methods are enough to verify stratum is working) and just create a stratum checker module my software uses

It would be possible for you to add a stratum checker to a miner manager but the miner will still create
its own conection. Every miner does this, changing it requires changing every miner you want to support.

yes indeed, i hoped for some of the miners to be able to handle this on their own, many already support this/some sort of, best miner in this regard seems to be sgminer

[Nik4691]

Need help

For this algo, you must set your virtual memory (pagefile) of your operating system to 32GB.

[malafaya]

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.

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) Xeon(R) CPU           X5560  @ 2.80GHz
CPU features: SSE2
SW built on Nov 28 2016 with GCC 4.8.3
SW features: SSE2
Algo features: SSE2
Start mining with SSE2

[2017-01-11 19:10:08] Starting Stratum on stratum+tcp://blakecoin.mine.zpool.ca:
5743
[2017-01-11 19:10:08] 15 miner threads started, using 'blakecoin' algorithm.
[2017-01-11 19:10:10] Rejected 1/1 (100.0%), 7564.07 kH, 20.10 MH/s
[2017-01-11 19:10:10] reject reason: Invalid share
[2017-01-11 19:10:10] Rejected 2/2 (100.0%), 8022.78 kH, 20.66 MH/s
[2017-01-11 19:10:10] reject reason: Invalid share
[2017-01-11 19:10:10] Rejected 3/3 (100.0%), 8319.47 kH, 21.17 MH/s
[2017-01-11 19:10:10] reject reason: Invalid share
[2017-01-11 19:10:10] Accepted 1/4 (25.0%), 8078.69 kH, 21.64 MH/s
[2017-01-11 19:10:11] Rejected 4/5 (80.0%), 7410.25 kH, 21.68 MH/s
[2017-01-11 19:10:11] reject reason: Invalid share
[2017-01-11 19:10:11] Rejected 5/6 (83.3%), 7410.25 kH, 21.68 MH/s
[2017-01-11 19:10:11] reject reason: Invalid share
[2017-01-11 19:10:11] Rejected 6/7 (85.7%), 7410.25 kH, 21.68 MH/s
[2017-01-11 19:10:11] reject reason: Invalid share
[2017-01-11 19:10:12] Rejected 7/8 (87.5%), 15.67 MH, 22.84 MH/s
[2017-01-11 19:10:12] reject reason: Invalid share
[2017-01-11 19:10:12] Rejected 8/9 (88.9%), 23.35 MH, 23.54 MH/s
[2017-01-11 19:10:12] reject reason: Invalid share
[2017-01-11 19:10:12] Rejected 9/10 (90.0%), 23.35 MH, 23.54 MH/s
[2017-01-11 19:10:12] reject reason: Invalid share
[2017-01-11 19:10:12] Accepted 2/11 (18.2%), 23.35 MH, 23.54 MH/s
[2017-01-11 19:10:12] Accepted 3/12 (25.0%), 23.35 MH, 23.54 MH/s
[2017-01-11 19:10:13] Accepted 4/13 (30.8%), 23.40 MH, 24.21 MH/s
[2017-01-11 19:10:13] Accepted 5/14 (35.7%), 29.39 MH, 24.73 MH/s
[2017-01-11 19:10:13] Accepted 6/15 (40.0%), 29.39 MH, 24.73 MH/s
[2017-01-11 19:10:13] Rejected 10/16 (62.5%), 65.19 MH, 28.21 MH/s
[2017-01-11 19:10:13] reject reason: Invalid job id
[2017-01-11 19:10:14] Rejected 11/17 (64.7%), 59.85 MH, 28.19 MH/s
[2017-01-11 19:10:14] reject reason: Invalid share
[2017-01-11 19:10:14] Rejected 12/18 (66.7%), 59.85 MH, 28.19 MH/s
[2017-01-11 19:10:14] reject reason: Invalid share
[2017-01-11 19:10:14] Rejected 13/19 (68.4%), 55.02 MH, 28.20 MH/s
[2017-01-11 19:10:14] reject reason: Invalid share
[2017-01-11 19:10:15] Rejected 14/20 (70.0%), 55.02 MH, 28.20 MH/s
[2017-01-11 19:10:15] reject reason: Invalid share
[2017-01-11 19:10:15] Rejected 15/21 (71.4%), 59.01 MH, 28.27 MH/s
[2017-01-11 19:10:15] reject reason: Invalid share
[2017-01-11 19:10:15] Rejected 16/22 (72.7%), 58.12 MH, 28.69 MH/s
[2017-01-11 19:10:15] reject reason: Invalid share
[2017-01-11 19:10:16] Rejected 17/23 (73.9%), 54.64 MH, 28.72 MH/s
[2017-01-11 19:10:16] reject reason: Invalid share
[2017-01-11 19:10:16] Rejected 18/24 (75.0%), 50.01 MH, 28.37 MH/s
[2017-01-11 19:10:16] reject reason: Invalid share
[2017-01-11 19:10:16] Rejected 19/25 (76.0%), 51.60 MH, 28.37 MH/s
[2017-01-11 19:10:16] reject reason: Invalid share
[2017-01-11 19:10:17] Rejected 20/26 (76.9%), 48.78 MH, 28.48 MH/s
[2017-01-11 19:10:17] reject reason: Invalid share

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.

[joblo]

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.

[malafaya]

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.

[joblo]

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]

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]

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]

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!