burstcoin-jminer v0.4.2 - GPU assisted PoC-Miner (All Platforms)



  • Requirements:

    • Java8
    • openCL driver/sdk

    Features:

    • solo and all pools supported
    • AMD and nVIDIA supported
    • Windows, Linux and Mac etc. supported (WARNING: Win7 has strange caching issues on BURST mining!)
    • for a QUICKSTART check README.txt

    Download:
    burstcoin-jminer-0.4.2-RELEASE (i suggest using latest: burstcoin-jminer-0.4.4-SNAPSHOT)
    https://github.com/de-luxe/burstcoin-jminer/releases

    Setup: jminer.properties
    https://github.com/de-luxe/burstcoin-jminer/wiki/configure-jminer.properties

    Info/Support:
    https://bitcointalk.org/index.php?topic=1170987

    BurstcoinForum recovery:
    https://github.com/de-luxe/burstcoin-jminer/wiki/burstforum.com-thread-recovery



  • Ahhh. Urgent on here to. Lol

    Good to share the downloads


  • administrators

    If you mine with CPU (blago) and assisted GPU and you want that your GPU is running at full speed speed high priority or with lower priority you can change your .bat file to:

    C:\Windows\System32\cmd.exe /C START "Java" /high java -jar -Xmx2G -XX:+UseG1GC burstcoin-jminer-0.3.6-RELEASE.jar

    you can change /high to /low
    also you can change -Xmx2G to a lower or higher value like -Xmx1G (for 1GB RAM). Depends on your system.



  • @jaggard suggested a tool to fix Win7 caching/memory issues:
    https://bitcointalk.org/index.php?topic=1170987.msg13847299#msg13847299

    Who can confirm, that it works?



  • @luxe said:

    Who can confirm, that it works?

    Seams that it does not work, ...
    https://bitcointalk.org/index.php?topic=1170987.msg13874525#msg13874525



  • New beta version available for testing

    burstcoin-jminer-0.4.2-SNAPSHOT

    Currently working on a update for jminer, feel free to test it.

    Download:

    https://github.com/de-luxe/burstcoin-jminer/releases/tag/0.4.2-SNAPSHOT

    Improvements:

    • updated used libs (including openCL, use latest drivers!)
    • better handling/info on fast blocks
    • incorrect size info of plots, GB and TB are decimal, calculation is binary fixed
    • eff.read is more likely the average read speed - now we have avg. and eff. speed were eff. is speed since last info shown.
    • add optional plot-drive info output
    • make memory usage more effective and adjustable
      (memory usage reduced up to ~50% per default, optimize more by editing 'readerThreads' property)
    • write console output to logfile

    Setup

    jminer is configured in 'jminer.properties' that has to be in same folder.

    For a quick start check:
    https://github.com/de-luxe/burstcoin-jminer/blob/master/README.md
    or README file included in download.

    For all available settings check:
    https://github.com/de-luxe/burstcoin-jminer/blob/master/jminer.default.properties
    or jminer.properties included in download.

    Run

    Ensure you have java8 (64bit) and latest openCL drivers installed execute (or use included *.bat):
    java -jar -d64 -XX:+UseG1GC burstcoin-jminer-0.4.2-SNAPSHOT.jar

    '-d64' - ensures it is 64bit
    '-XX:+UseG1GC' - garbage collector that will free unused memory

    Reported issues:

    • not all GPUs may support updated openCL lib, (on issues continue using version 0.3.6)
    • ...

    Help

    Please post your results, suggestions, issues ... bug-tickets could be directly created on github, too.


  • administrators

    @luxe I can confirm that AMD R9/79xx cards work fine with the new snapshot along with nVidia 960's, however my nVidia 750Ti crashes on startup.

    H.


  • administrators

    @luxe
    It works nicely after I corrected your typo in your post:

    java -jar -d64 -XX:+UseG1GC burstcoin-jminer-0.4.2-RELEASE.jar

    it should be SNAPSHOT. Then it runs :)

    Great.



  • @daWallet copy&paste :-) corrected it.

    If you start the miner, does it say OpenCL 1.2 or OpenCL 2.0 on starting context?


  • administrators

    @luxe It starts openCL 1.2 context.


  • administrators

    @Luxe - On an nVidia 960 I get a 1.2 context, on an AMD 7970 I get a 2.0 context.

    H.



  • Thanks for feedback, so openCL 1.2 and openCL 2.0 are supported.
    For GPU that only supports openCL 1.1 jminer 0.3.6 has to be used. (e.g. 750 Ti)


  • administrators

    Is adding OpenCL 1.1 support feasible? Would be nice to have a single miner for any card, especially with the additional functionality in the 0.4.2 build.

    H.



  • jocl is used for openCL, i took the version 0.2.0-RC, what is maybe not a good idea ...
    (native libraries for 32 and 64 bit Windows, and for 64 bit Linux)
    Guess i should use the version 0.1.9 ...
    (native libraries for 32 and 64 bit Windows, 32 and 64 bit Linux and 64 bit MacOS)
    even if we loose openCL 2.0 support ... not sure.

    or i just compile two different versions ... using both libs in one version would be tricky i guess.


  • administrators

    Yeah, trying to use two versions of a library in the same executable isn't going to be pretty.



  • @haitch i made two binaries, you could use 'burstcoin-jminer-0.4.2-RELEASE-JOCL19' for all your machines, if OpenCL 2.0 is not that important to you.


  • administrators

    @luxe Thanks, I'll give them a test.



  • burstcoin-jminer-0.4.3-SNAPSHOT

    Download:

    https://github.com/de-luxe/burstcoin-jminer/releases/tag/0.4.3-SNAPSHOT

    Info:

    I expect the miner to be more stable and memory usage should be constant now.

    Changes:

    • bugfixes (fixed 'walletServer' npe)
    • updated versions of used libs (spring+jetty)
    • providing some info about used pool on startup (balance, total mined, number of miners)
    • add miner and capacity info on commit nonce to pool (e.g. to see miner version+ capacity on burst.ninja)

    Please test and report :-)



  • 0.4.3 works fine on my 3 pcs, it seems to be about 50 to 100% faster than the POC java miner, and smoke stopped coming out of the cabinets...

    i have a few suggestions :

    • if a drive have plot files where the filename indicates a longer file than the actual file size, the console line
      read 'D:/plots' (8TB 87GB) in '23s 278ms' will show too many TB's - seems like the TB count is derived from filenames, not actual file size. I noticed bc i had a 4TB drive that was reported as 5TB, that confused me a bit.
      As plotting sometimes gets interrupted it is common (at least for me) to have a file where the filename indicates more nonces than it actually have.
    • when showing the winner, show the human readable name also.
      not sure how to find it, perhaps the wallet knows,
      perhaps a file where the user can put in known names for burst addresses he knows.
    • The FINISH line could print out the time version of the deadline too

    Great miner! It works very efficiently and is super easy to set up, well documented too, in the properties file



  • Thanks for you feedback and suggestions, always motivating to get some positive response ...

    • You are right, the size calculations are based on the filename, i did not expect that miners are using 'incomplete' plotfiles ...
      If it is just the size calculation that is incorrect, i'm quite happy ... would think that this results in error messages ... and maybe not finish round correctly. I'm not sure yet, how to fix/harden that. Miner could just 'rename' the files internal based on startnonce and size or something.
    • Showing the winner name and printing the time version of deadline should be no problem ... i will think about ... still have a GUI in mind anyway ... templates for logs would also be cool, so every user can adjust/build his own output format/translations.


  • @luxe

    It seems to work fine, but i have not checked if it misses out on the partly truncated files, or if it skips files after having stumbled upon a truncated one. Not sure how i should go about testing that. console output does not indicate any problems, and i do get blocks, but then i also have lots of terabytes of files that are in order.

    The internal renaming scheme seems to be a viable solution that keeps the rest of the code as it is.
    Perhaps make a file renaming tool that simply renamed plot files in current dir, to reflect their real size?


Log in to reply