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



  • @DexterStoner can not test it but it seems you have to escape your plot dir:

    Y:\\Plots\\...

    Two backslashes instead of one.



  • @Creepsky Oh it worked, thanks.

    Do you know, if I already plotted that hard drive with different pool. And I want it to mine now on different pool with different account, can I reneame the plot and change numeric account id? will it work?



  • @DexterStoner you dont need to rename them, just change your pool (reward recipient) and wait a couple of rounds...

    Edit: sorry, misunderstood your question. This is not possible, you have to create new plot files



  • @Creepsky Ok, but what if I want to mine on 2 different pools with same account, on one plot with one pool and second on different pool but with different miner? is it possible? Also what deadline should I put? Sorry if those are dumb questions, I'm still learning :P



  • @DexterStoner not sure why would you want it but hey its your choice :) but here is the kicker you cant do it since only one reward id can be set. So you would need two separate accounts plot one plot with one account and another with another account. And two instances of miner (basically copy paste whole miner folder change reqyired setting and go)



  • @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?


Log in to reply
 

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