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



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



  • Just looked up the java docs of 'SeekableByteChannel.position(long newPosition)'
    https://docs.oracle.com/javase/7/docs/api/java/nio/channels/SeekableByteChannel.html#position(long)
    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

    Download:

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

    Setup:

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

    Info:

    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)

    Changes:

    • 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