<<  >> (p.81)
    Author Topic: [LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner  (Read 444205 times)

    • felixbrucker
    Hero Member
    *****
    Offline Offline

    Activity: 700
    Merit: 500


    View Profile WWW
    December 30, 2016, 11:47:18 AM
     #1601
    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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    December 30, 2016, 01:52:19 PM
     #1602
    Quote from: felixbrucker on December 30, 2016, 11: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.
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • felixbrucker
    Hero Member
    *****
    Offline Offline

    Activity: 700
    Merit: 500


    View Profile WWW
    December 30, 2016, 02:12:29 PM
     #1603
    Quote from: joblo on December 30, 2016, 01:52:19 PM
    Quote from: felixbrucker on December 30, 2016, 11: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?

  • minerbaba
    Newbie
    *
    Offline Offline

    Activity: 91
    Merit: 0


    View Profile
    January 03, 2017, 04:04:04 PM
     #1604
    Need help

    http://imgur.com/a/hVijU

  • K1lo
    Full Member
    ***
    Offline Offline

    Activity: 151
    Merit: 100

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


    View Profile
    January 03, 2017, 04:25:16 PM
     #1605
    What is your CPU? I suspect it doesn't support AVX2 instructions.
    Developer, tinkerer, miner, coin holder, hopelessly amateurish trader

  • minerbaba
    Newbie
    *
    Offline Offline

    Activity: 91
    Merit: 0


    View Profile
    January 03, 2017, 04:30:56 PM
     #1606
    Quote from: K1lo on January 03, 2017, 04:25:16 PM
    What is your CPU? I suspect it doesn't support AVX2 instructions.

    i5 4670

  • K1lo
    Full Member
    ***
    Offline Offline

    Activity: 151
    Merit: 100

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


    View Profile
    January 03, 2017, 04:50:37 PM
     #1607
    Quote from: minerbaba on January 03, 2017, 04:30:56 PM
    Quote from: K1lo on January 03, 2017, 04:25:16 PM
    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.
    Developer, tinkerer, miner, coin holder, hopelessly amateurish trader

  • joblo (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    January 03, 2017, 06:04:10 PM
    Last edit: January 03, 2017, 06:31:01 PM by joblo
     #1608
    Quote from: minerbaba on January 03, 2017, 04:04:04 PM
    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.
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • joblo (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    January 03, 2017, 06:23:37 PM
     #1609
    Quote from: felixbrucker on December 30, 2016, 02:12:29 PM
    Quote from: joblo on December 30, 2016, 01:52:19 PM
    Quote from: felixbrucker on December 30, 2016, 11: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? 
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • felixbrucker
    Hero Member
    *****
    Offline Offline

    Activity: 700
    Merit: 500


    View Profile WWW
    January 03, 2017, 07:43:44 PM
     #1610
    Quote from: joblo on January 03, 2017, 06:23:37 PM
    Quote from: felixbrucker on December 30, 2016, 02:12:29 PM
    Quote from: joblo on December 30, 2016, 01:52:19 PM
    Quote from: felixbrucker on December 30, 2016, 11: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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    January 03, 2017, 09:09:33 PM
     #1611
    Quote from: felixbrucker on January 03, 2017, 07: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.
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • felixbrucker
    Hero Member
    *****
    Offline Offline

    Activity: 700
    Merit: 500


    View Profile WWW
    January 03, 2017, 09:33:29 PM
     #1612
    Quote from: joblo on January 03, 2017, 09:09:33 PM
    Quote from: felixbrucker on January 03, 2017, 07: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

  • Nik4691
    Sr. Member
    ****
    Offline Offline

    Activity: 352
    Merit: 250



    View Profile
    January 04, 2017, 07:22:25 AM
     #1613
    Quote from: minerbaba on January 03, 2017, 04:04:04 PM
    Need help


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

  • malafaya
    Sr. Member
    ****
    Offline Offline

    Activity: 490
    Merit: 256



    View Profile
    January 11, 2017, 07:22:26 PM
    Last edit: January 11, 2017, 07:52:45 PM by malafaya
     #1614
    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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    January 11, 2017, 09:05:58 PM
     #1615
    Quote from: malafaya on January 11, 2017, 07: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.
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • malafaya
    Sr. Member
    ****
    Offline Offline

    Activity: 490
    Merit: 256



    View Profile
    January 11, 2017, 09:53:40 PM
     #1616
    Quote from: joblo on January 11, 2017, 09:05:58 PM
    Quote from: malafaya on January 11, 2017, 07: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.

  • joblo (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    January 11, 2017, 11:34:30 PM
    Last edit: January 12, 2017, 12:04:49 AM by joblo
     #1617
    Quote from: malafaya on January 11, 2017, 09:53:40 PM
    Quote from: joblo on January 11, 2017, 09:05:58 PM
    Quote from: malafaya on January 11, 2017, 07: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.
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • malafaya
    Sr. Member
    ****
    Offline Offline

    Activity: 490
    Merit: 256



    View Profile
    January 12, 2017, 12:06:39 AM
    Last edit: January 12, 2017, 12:16:50 AM by malafaya
     #1618
    Quote from: joblo on January 11, 2017, 11:34:30 PM
    Quote from: malafaya on January 11, 2017, 09:53:40 PM
    Quote from: joblo on January 11, 2017, 09:05:58 PM
    Quote from: malafaya on January 11, 2017, 07: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 (OP)
    Legendary
    *
    Offline Offline

    Activity: 1470
    Merit: 1114


    View Profile
    January 12, 2017, 01:35:30 AM
    Last edit: January 12, 2017, 05:36:28 AM by joblo
     #1619
    Quote from: malafaya on January 12, 2017, 12:06:39 AM
    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.
    AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
    https://bt.irlbtc.com/view/5226770.msg53865575#msg53865575
    BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,

  • malafaya
    Sr. Member
    ****
    Offline Offline

    Activity: 490
    Merit: 256



    View Profile
    January 12, 2017, 10:31:24 AM
     #1620
    Quote from: joblo on January 12, 2017, 01:35:30 AM
    Quote from: malafaya on January 12, 2017, 12:06:39 AM
    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!
    Pages: « 1 ... 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 [81] 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 ... 197 »
      Print  
Page 80
Viewing Page: 81

IRLBTC™ © 2025 IRLBTC.com