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

joblo

legendary

Activity: 1470

Merit: 1114

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.

malafaya

sr. member

Activity: 490

Merit: 256

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.

Nik4691

sr. member

Activity: 352

Merit: 250

Quote from: minerbaba on January 03, 2017, 11:04:04 AM

Need help

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

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on January 03, 2017, 04:09:33 PM

Quote from: felixbrucker on January 03, 2017, 02:43:44 PM

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

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on January 03, 2017, 02:43:44 PM

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

hero member

Activity: 700

Merit: 500

Quote from: joblo on January 03, 2017, 01:23:37 PM

Quote from: felixbrucker on December 30, 2016, 09:12:29 AM

Quote from: joblo on December 30, 2016, 08:52:19 AM

Quote from: felixbrucker on December 30, 2016, 06:47:18 AM

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

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on December 30, 2016, 09:12:29 AM

Quote from: joblo on December 30, 2016, 08:52:19 AM

Quote from: felixbrucker on December 30, 2016, 06:47:18 AM

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?

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: minerbaba on January 03, 2017, 11:04:04 AM

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.

K1lo

full member

Activity: 151

Merit: 100

Moar mining!!! .. oh wait, that's too much

Quote from: minerbaba on January 03, 2017, 11:30:56 AM

Quote from: K1lo on January 03, 2017, 11:25:16 AM

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.

minerbaba

newbie

Activity: 91

Merit: 0

Quote from: K1lo on January 03, 2017, 11:25:16 AM

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

i5 4670

K1lo

full member

Activity: 151

Merit: 100

Moar mining!!! .. oh wait, that's too much

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

minerbaba

newbie

Activity: 91

Merit: 0

Need help

http://imgur.com/a/hVijU

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on December 30, 2016, 08:52:19 AM

Quote from: felixbrucker on December 30, 2016, 06:47:18 AM

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?

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on December 30, 2016, 06:47:18 AM

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

hero member

Activity: 700

Merit: 500

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

t2yax

sr. member

Activity: 462

Merit: 250

Arianee:Smart-link Connecting Owners,Assets,Brands

Quote from: joblo on December 27, 2016, 04:58:26 PM

Quote from: t2yax on December 27, 2016, 02:52:40 PM

miner just stops after some mining at lyra2z algo.program is not being closed,no errors,just mining and status update stops.
cpu i5 3337u os windows 10 pro redstone 1

pool is pool.mn

Happened once? Regularly? Restarting miner works?
What is CPU usage when this happens? Does pool still report a connection, what hashrate?
Try isolating the problem by trying other pools and algos. If it only happens at one pool I suspect
a pool problem.

1.Happened once,
2.restarting miner works
3.i did not checked but fan was not working so i guess its 0
4.yes,it reports connection
5.hashrate = 2.5H

i left my computer mining for whole night at same pool,and there was not any problem.
I guess its pool problem.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: t2yax on December 27, 2016, 02:52:40 PM

miner just stops after some mining at lyra2z algo.program is not being closed,no errors,just mining and status update stops.
cpu i5 3337u os windows 10 pro redstone 1

pool is pool.mn

Happened once? Regularly? Restarting miner works?
What is CPU usage when this happens? Does pool still report a connection, what hashrate?
Try isolating the problem by trying other pools and algos. If it only happens at one pool I suspect
a pool problem.

t2yax

sr. member

Activity: 462

Merit: 250

Arianee:Smart-link Connecting Owners,Assets,Brands

miner just stops after some mining at lyra2z algo.program is not being closed,no errors,just mining and status update stops.
cpu i5 3337u os windows 10 pro redstone 1

pool is pool.mn

bigvito19

full member

Activity: 706

Merit: 111

Does the miner suppose to be slow???
Is there another updated version?

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: crysx on December 14, 2016, 06:11:20 AM

though 32bit is STILL being used for some odd reason ( i just finished a windows migration ( ge / latitude ) and they used ALL 32bit windows desktops - go figure ) - i totally agree with your statement that a 64bit upgrade really is necessary - especially in this day and age ...

The issue with 32 bit is mainly feasibility, how much work is involved to develop and support 32 bit mining for how much it
wil produce: smaller architecture, no optimizations (maybe SSE2), lower memory bandwidth, less power efficient. But if you
want to pursue it I suggest cpuminer-multi as a starting point. I believe it still compiles in 32 bit and hasn't been poluted with
64bit optimizations.

I'm not really opposed to closed source but am a little reluctant to making comminments. I'm kinda liking just doiing my own
thing, when I want, how I want, if I want. But if there is something you think I can help with, PM me and we can probably work
it out.

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