creepMiner - C++ Burst Miner (based on Uray's Miner)
-
@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.
-
@Tate-A Here is the 32 bit version -> https://github.com/Creepsky/creepMiner/releases/download/2.4.5/creepMiner-win32.zip
-
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:
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:
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 :)




