creepMiner - C++ Burst Miner (based on Uray's Miner)



  • @LithStud Thanks :)



  • Last question, what should I put in "Target Deadline" ?



  • @DexterStoner that depends on pool, as some pools are limiting what deadlines they accept (as in deadlines longer than 24h will be declined). I just dont know in this case how it measured miliseconds/seconds/minutes, someone else will need to clarify



  • @LithStud said in creepMiner - C++ Burst Miner (based on Uray's Miner):

    @DexterStoner that depends on pool, as some pools are limiting what deadlines they accept (as in deadlines longer than 24h will be declined). I just dont know in this case how it measured miliseconds/seconds/minutes, someone else will need to clarify

    I would like to mine on m.burst4all.com I just couldn't find their deadline :(



  • @DexterStoner oh i think its fairly long one :) as plots they are using is bellow 1TB and small deadlines would be very rare



  • New (pre-)release: 1.4.5

    • Urays plot read algorithm got replaced with a new one
    • intelligent configuration file
    • secured shutdown function (webserver)
    • additional system infos on webserver
    • default scheme and port for URIs
    • thread safety (may be slower, but safer)


  • Is this miner 32 bit too?



  • @Tate-A I compile it for 64 bit only, but as far as I know I can compile it for 32 bit without changing the code. I will try it.





  • Thank you for your work on developing this.

    I'm running the latest build under Ubuntu 16.04, and I keep running into a situation where after an hour or so of running fine, it stops scanning the drives and submitting deadlines. System is rather old - dual 4-core Intel QX9775 and 16GB of RAM. This has happened with two different pools:

    0_1488138163330_Screenshot from 2017-02-26 13-38-56.png

    Here is the corresponding entries in the log file:

    --------------------------------------------------
    26.02.2017 19:24:08 (0, src/Miner.cpp, 175, Debug): Verification queue cleared.
    26.02.2017 19:24:08 (0, src/Miner.cpp, 178, Debug): Locking threads...
    26.02.2017 19:24:08 (0, src/Miner.cpp, 180, Debug): Threads locked, setting up new block 332450...
    26.02.2017 19:24:08 (0, src/Miner.cpp, 283, Notice): --------------------------------------------------
    block#      332450
    scoop#      1734
    baseTarget# 1035051
    --------------------------------------------------
    26.02.2017 19:29:02 (0, src/Miner.cpp, 175, Debug): Verification queue cleared.
    26.02.2017 19:29:02 (0, src/Miner.cpp, 178, Debug): Locking threads...
    26.02.2017 19:29:02 (0, src/Miner.cpp, 180, Debug): Threads locked, setting up new block 332451...
    26.02.2017 19:29:02 (0, src/Miner.cpp, 283, Notice): --------------------------------------------------
    block#      332451
    scoop#      1877
    baseTarget# 1079299
    --------------------------------------------------
    26.02.2017 19:29:11 (0, src/Miner.cpp, 175, Debug): Verification queue cleared.
    26.02.2017 19:29:11 (0, src/Miner.cpp, 178, Debug): Locking threads...
    26.02.2017 19:29:11 (0, src/Miner.cpp, 180, Debug): Threads locked, setting up new block 332452...
    26.02.2017 19:29:11 (0, src/Miner.cpp, 283, Notice): --------------------------------------------------
    block#      332452
    scoop#      1781
    baseTarget# 1007656
    --------------------------------------------------
    26.02.2017 19:31:36 (0, src/Miner.cpp, 175, Debug): Verification queue cleared.
    26.02.2017 19:31:36 (0, src/Miner.cpp, 178, Debug): Locking threads...
    26.02.2017 19:31:36 (0, src/Miner.cpp, 180, Debug): Threads locked, setting up new block 332453...
    26.02.2017 19:31:36 (0, src/Miner.cpp, 283, Notice): --------------------------------------------------
    block#      332453
    scoop#      2493
    baseTarget# 1011097
    --------------------------------------------------
    26.02.2017 19:34:07 (0, src/Miner.cpp, 175, Debug): Verification queue cleared.
    26.02.2017 19:34:07 (0, src/Miner.cpp, 178, Debug): Locking threads...
    26.02.2017 19:34:07 (0, src/Miner.cpp, 180, Debug): Threads locked, setting up new block 332454...
    26.02.2017 19:34:07 (0, src/Miner.cpp, 283, Notice): --------------------------------------------------
    block#      332454
    scoop#      1886
    baseTarget# 844649
    --------------------------------------------------
    26.02.2017 19:34:08 (0, src/Miner.cpp, 262, Information): --------------------------------------------------
    last block winner: 
    block#             332453
    winner-numeric     8786871724884427616
    winner-address     L2V2-AXNC-VW9G-9XBWM
    --------------------------------------------------
    26.02.2017 19:38:18 (0, src/Miner.cpp, 175, Debug): Verification queue cleared.
    26.02.2017 19:38:18 (0, src/Miner.cpp, 178, Debug): Locking threads...
    26.02.2017 19:38:18 (0, src/Miner.cpp, 180, Debug): Threads locked, setting up new block 332455...
    26.02.2017 19:38:18 (0, src/Miner.cpp, 283, Notice): --------------------------------------------------
    block#      332455
    scoop#      3151
    baseTarget# 869025
    --------------------------------------------------
    26.02.2017 19:38:19 (0, src/Miner.cpp, 262, Information): --------------------------------------------------
    last block winner: 
    block#             332454
    winner-numeric     2173983320505215447
    winner-address     EUGR-BZ97-JG3W-3CWCW
    winner-name        NeatCrypto
    --------------------------------------------------
    

    My config file:

    {
        "Start Server" : true,
        "logging" : {
            "config" : "information",
            "general" : "information",
            "miner" : "information",
            "nonceSubmitter" : "information",
            "path" : "",
            "plotReader" : "information",
            "plotVerifier" : "information",
            "server" : "fatal",
            "session" : "error",
            "socket" : "off",
            "wallet" : "information"
        },
        "maxBufferSizeMB" : 4096,
        "maxPlotReaders" : 0,
        "miningInfoUrl" : "http:\/\/pool.burstcoin.biz:8124",
        "miningIntensity" : 3,
        "output" : {
            "dirDone" : true,
            "lastWinner" : true,
            "nonceConfirmed" : true,
            "nonceFound" : true,
            "nonceOnTheWay" : true,
            "nonceSent" : true,
            "plotDone" : false
        },
        "passphrase" : {
            "algorithm" : "aes-256-cbc",
            "decrypted" : "",
            "deleteKey" : false,
            "encrypted" : "",
            "iterations" : 0,
            "key" : "",
            "salt" : ""
        },
        "plots" : [
            "\/media\/xxxxx\/New Volume\/plots",
            "\/media\/xxxxx\/one\/plots",
            "\/media\/xxxxx\/two\/plots",
            "\/media\/xxxxx\/three\/plots",
            "\/media\/xxxxx\/four\/plots",
            "\/media\/xxxxx\/five\/plots",
            "\/media\/xxxxx\/six\/plots",
            "\/media\/xxxxx\/seven\/plots",
            "\/media\/xxxxx\/eight\/plots",
            "\/media\/xxxxx\/nine\/plots"
        ],
        "poolUrl" : "http:\/\/pool.burstcoin.biz:8124",
        "serverUrl" : "http:\/\/192.168.0.100:8080",
        "submissionMaxRetry" : 3,
        "targetDeadline" : "0y 0m 20d 15:00:00",
        "timeout" : 45,
        "walletUrl" : "https:\/\/wallet.burst-team.us:8128"
    

    The only thing I can think of is the memory allocation, but System Monitor shows that there is still plenty of unused RAM. Any thoughts?



  • @RatPatrol Thank you for using the miner and telling about the problem!
    There is an issue on github with exactly the symptoms you described.
    I uploaded a fix (at least I hope it is a fix...) but it is not 100% tested: https://github.com/Creepsky/creepMiner/tree/2.4.6 (or https://github.com/Creepsky/creepMiner/tree/fix-mining-bug). Maybe you can give it a try.



  • @Creepsky Thank you! I'll give it a try and report back.

    Thank you again for your work on this.



  • @Creepsky It's been running for over 24 hours, and that issue has not popped up again. I also like how it simply displays eligible DLs.

    One thing I have noticed is that the read times have roughly doubled with this latest version:

    Previous version:
    0_1488246796560_Screenshot from 2017-02-26 16-01-25.png

    Current version:
    0_1488246829126_Screenshot from 2017-02-26 16-02-14.png

    I've tried changing a couple of settings in the config file....mainly buffer size and plot readers, but it seemed to have little to no effect on the read times. I'll keep playing with the settings and see if I can get an increase.



  • @RatPatrol glad to hear that :)

    Sorry, should have said that in the new version the read speed is measured in a different way.

    In the version before it was just plot size / time. But this is not true, because not the entire plot file is read.
    Now it is the real amount of read bytes / time, what results in a more realistic value.

    What you could change is the mining intensity (number of verifiers).
    I will create a performance measure version, so you can test and see the performance and figure out the bottleneck.



  • @Creepsky No worries.

    Thanks for the tip on changing the mining intensity. Setting it to '1' brought the read times close to what I was seeing originally. Because I don't fully understand what the verifiers do, am I compromising my reads by running at a lower number?



  • @RatPatrol you can see the plot readers as work producer and the verifiers as worker.
    Every plot reader is reading parts from the plot files and putting the data onto a stack. The verifiers are taking this data and looking for good deadlines inside of them.

    There is never more work to do as maxBufferSizeMB (in MB); if a new work block would exceed this value, the plot readers are waiting.

    Every plot reader and every verifier represents exactly 1 thread. If you have too many threads running, the program can begin to slow down, because the threads (plot reader, verifier, wallet requests, and so on) are blocking each other for a short amount of time (can be ns, can be ms).

    So its safe to use whatever settings fits to your computer - if it runs fine, just use them :)



  • @Creepsky Got it. Thank you for the explanation!



  • Hey @Creepsky ,
    I have few problems with the miner.

    1. What went wrong here? It seems like there slipt a to long DL thru:
      0_1489236695638_creepBug.png

    2.The miner stops minig after a while:
    0_1489236964552_creepstuck.png

    3.Sometimes my PC becomes unusable while the miner is reading the drives, even though the CPU is only at 70%.

    90% of the time the miner works fine.



  • Hey @Daforce,

    1 comes from a fast block. The sent nonce was found for the last block, but the pool (or wallet) calculated it for the current block. This happens mainly because of latency and high CPU load on the pool (or wallet) side.

    Unfortunately there is not much I can do :-\ a new parameter in the API of the wallet or pool would fix this, but that's not in my hands. (/burst?requestType=submitNonce&accountId=...&nonce=...&blockheight=...).

    Actually, I also could simply hide the bad nonce/deadline (what I really should do, thanks for your report).

    2 is a bug that was fixed in the latest release (https://github.com/Creepsky/creepMiner/releases/tag/2.5.0).

    3 is interesting. One thing I can think of why this happens is that I set the priority of the plot read threads to a very high value. If you have a lot of readers, it can happen that the OS gives compute time only for the readers, but not the rest of the system.

    Also, here I refer to the latest version, where I set the priority down.
    If this doesn't help, you could set "mining"."maxPlotReaders" to a value > 0 and < the amount of your plot drives and/or change "mining"."intensity" to a lower value.



  • @Creepsky ok thanks, for the reply.
    I will try the new version and report back, how it runs :)


Log in to reply
 

Looks like your connection to Burst - Efficient HDD Mining was lost, please wait while we try to reconnect.