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



  • @luxe said in burstcoin-jminer v0.4.11 - GPU assisted PoC-Miner (All Platforms):

    @eneloop said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):

    My setup:

    • 19x 8 TB disks: 8x SATA mainboard, 3x SATA PCIe Controller, 8x USB 3.0 (PCIe controller with 4 USB 3.0 controller chips, 2 disks each port/controller)
    • AMD A8-7670K APU with R7 cores used for jminer
    • burstcoin-jminer v0.4.10 with Win10 x64

    What's going wrong / questions:

    1. All 11 internal SATA disks are read out first and when they finished their work, all USB 3.0 are read out. Is this kind of prioritization a bug or a feature? I believe I loose a lot of time because of that.
    2. What does the "GB" number mean. All internal SATA disks show "0GB" and all USB 3.0 disks "1GB".
    3. Is it somehow possible to show the "100% done...". message only? Just a cosmetic issue. 🙂
    4. What does the "avg." and "eff." value mean exactly? First one is "average" but what's the second one?

    alt text

    Thanks!

    1. No, they may finish after the internal ones, but they should all read parallel, as long every plotPath points to one physical drive ... jminer uses one thread for every plotPath.
      Ensure you have 'readerThreads=0' having this setting changed could lead to your problems.
      As it would limit the threads in reader thread pool.
    2. the size is calculated by the plotfile names
      Linke @rds said:
    3. 'readProgressPerRound=0' and 'showDriveInfo=false' and 'showSkippedDeadlines=false'
    4. avg = over the whole round, eff. = since last log ... e.g. perfect configured setup would not get slower/lower eff. in the end.

    Mark as read, very good answer . helped me also



  • burstcoin-jminer v0.4.12 force local difficulty is a gem for CG pools


  • admin

    burstcoin-jminer-0.5.0-SNAPSHOT

    With this version, jminer supports both POC1 and POC2 plotfiles. This will also be the case after the fork.
    However, to handle POC2 pre-fork and POC1 post-fork, twice the amount of data needs to be read and also more CPU and memory resources will be used. The best case for a miner would be, to have converted up to 50% of plotfiles once the fork happens. That would cause the mining setup to behave exactly the same pre and post fork. I hope to make the switch from POC1 to POC2 as smooth as possible for users of jminer, like myself.

    Only use one type, POC1 or POC2 on one drive ('plotPath'), mixed will be skipped.

    Ensure your POC2 plotfiles do not have staggersize in filename, or they will be treated like POC1.
    e.g. If you use JohnnyFFM/Poc1to2Converter you need to remove it manually.

    Read speed is calculated by plotsize, so if jminer reads twice the data on e.g. POC2 pre-fork, the numbers displayed will not be accurate.

    Ensure to use Java8 (in command line java -version) Java9 will cause issues for now!

    Ensure to check for jminer updates before fork, as i did not test jminer in a post-fork environment yet and a additional update my be needed.

    Download:

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

    Updates:

    0.5.0

    • support for POC2 plotfiles (will read twice the data pre-fork)

    0.4.12

    • Allow the client to force use of its own targetDeadline on pool mining
    • Add option for dynamic targetDeadline in case of PoCC pool
    • Compatibility for chaining JMiner to CreepMiner


  • I've stopped mining until the fork occurs mainly that my rig was crap anyway. Refit rig + plot poc2 = will be poc2 ready. Thanks @luxe


  • admin

    burstcoin-jminer-0.5.1-SNAPSHOT

    Notice:

    Both POC2 in pre-fork and POC1 in post-fork environment are tested now.
    Thanks to the testnet providers!

    Download:

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

    Updates:

    0.5.1

    • POC2 switch at block 502000 (changed default)


  • @luxe Downloaded and begun testing with it. Seems ok. Giving some errors about "Strange DL........" and referencing a specific plot file. All my drives are still POC1. Spin through plots are twice as long. Do you wish to see the errors posted here?


  • admin

    @digidigm said in burstcoin-jminer v0.5.1 - GPU assisted PoC-Miner (All Platforms):

    Strange DL

    Strange DL means the miner found a deadline for a specific nonce and the pool/wallet returned another deadline on 'commitNonce' for that nonce ... this usualy indicates a corrupted or incomplete plotted plotfile or problems with the drive. If it comes up and up again for same plotfile, I would suggest replotting the specific plotfile.

    Edit: Could also be caused due to miningInfo has changed for same blockheight, but if that happens jminer should Restart round short after that.



  • @luxe It was random and came up on at least two different drives. Let me do some more extensive testing and get back to you.
    Thanks


  • admin

    burstcoin-jminer-0.5.2-RELEASE

    Download:

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

    Updates:

    0.5.2

    • Read speeds are calculated correctly on POC1/POC2 now.
    • Fixed timing issue that caused 'duplicate plot file' errors.
    • Added 'connection' info in %. replacing 'get mining info errors'


  • its a winner!



  • Confirmed all issues are resolved.


  • admin

    Please re-download release, to get two additional minor issues fixed. There was a divide by zero problem on connection statistic.



  • running now i'm happy with it when poc2 turns on it'll be interesting to observe poc2 running without conversion when its time thanks again @luxe heh I decided to run my new system I refurbished most of



  • Hello, i have a problem with miner v 0.5+. It takes double of time reading plots comparing with with v0.4.12
    v4.12:
    0_1529469914405_jminerold.PNG v5.2:
    0_1529469952568_jminer1.PNG

    Also i noticed that v5.2 shows +20% of mining speed. The confugurations are the same, but with the new miner i only can have chunkPartNonces=320000 and with the older one chunkPartNonces=480000

    Should it work like that? or there is any way to fix it?


  • admin

    @juasker POC2 is active since block 502000 ... Still mining POC1 plotfiles means double the data needs to be read, also the convert POC1->POC2 requires more CPU and memory (thats why your old chunkPartNonces setting does not work anymore) ... you will need to convert your plotfiles, to change behaviour back to pre-fork. Please check https://burstforum.net/topic/9185/hard-fork-resources-everything-a-happy-burster-needs!

    From jminer 0.5.x release Notice:
    Supports both, POC1 and POC2 plotfiles. This will also be the case after the fork.
    However, to handle POC2 pre-fork and POC1 post-fork, twice the amount of data needs to be read and also more CPU and memory resources will be used. The best case for a miner would be, to have converted up to 50% of plotfiles once the fork happens. That would cause the mining setup to behave exactly the same pre and post fork.



  • I am very pleased with this latest version of jminer with poc2 I was surprised to win several blocks prior and just after the fork. blocks aren't much to rave about but 64tb in 30 seconds a round is an achievement for my personal record. Thanks @luxe I shall expand my storages back to full capacity shortly to see the final result 🙂


  • admin

    @zapbuzz Glad to hear, for me the lastest release is not 100% stable yet .. but i'm monitoring and working on it.



  • @luxe Thanks a lot for the explaination. Started converting plots.



  • @luxe said in burstcoin-jminer v0.5.2 - GPU assisted PoC-Miner (All Platforms):

    @zapbuzz Glad to hear, for me the lastest release is not 100% stable yet .. but i'm monitoring and working on it.

    Any plans to release and updated version above V5.2 ?


  • admin

    @digidigm said in burstcoin-jminer v0.5.2 - GPU assisted PoC-Miner (All Platforms):

    Any plans to release and updated version above V5.2 ?

    @digidigm Yes, do you have any concrete issues with that version?