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

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




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


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

  • Just looked up the java docs of 'SeekableByteChannel.position(long newPosition)'
    It says:
    'Setting the position to a value that is greater than the current size is legal ... will immediately return an end-of-file indication.

    Guess if you get no IOException or something, all is fine ... but the miner is checking a 'empty' buffer for deadline ... no big deal if you gpu is not the bottleneck.

    Independent of that, i suggest creating 'complete' plot-files to be able to optimize them (guess that does not work with 'incomplete' ones).
    Optimizing your plot-files will not only improve mining speed ... but should also increase the lifetime of your drives.

  • @luxe

    thank you for looking into it. That's great, then i'm only burning som watts until i get non-lazy and fix my filenames or whatever.

    with your miner things are going pretty fast, with 3 pc's i get through my 80TB in less than 30 seconds. And without windows acting up, which it did before. I'll probably show up in a better position in your pie charts when i have been running jminer for 50 days....

  • burstcoin-jminer-0.4.4-SNAPSHOT






    Writing logfile is now disabled per default.
    Added some additional openCL info/support for easy setup.
    Fixed smaller bugs and stuck issue while solo-mining
    Added debug mode (will e.g. list incomplete plot-files)


    • support all available openCL devices
    • check for openCL support on startup, list available platforms/devices
    • prevent wallet from stuck on solo-mining e.g. on slow blocks/no open gui
    • writing logfile as optional feature
    • stop using jocl 0.2.0 as long as there is no performance improvement
    • provide info about 'incomplete' plot-files
    • enable selection logLevel DEBUG for users that are interested in more details

Log in to reply