burstcoin-jminer v0.5.3 - GPU assisted PoC-Miner (All Platforms)
sebastian.gaia last edited by
I posted my problem on Github. After mining one block jminer gives me the error "2017-12-22 20:03:38.448 DEBUG 1124 --- [SimpleAsyncTaskExecutor-142] b.j.c.n.t.NetworkRequestMiningInfoTask : Unable to get mining info from wallet: null" and won't start the next block.
I am using the jminer 0.4.11 with Qbundle as local wallet in solo mining. BlagoMiner runs smoothly but brings the computer to it's limits.
The problem does not occur if it is a fast block and jminer gets interrupted during the read-process. But if reading is finished and jminer is waiting for a new block it will repeat this error on and on and won't start reading.
Thanks in regard
is it possible to connect to drives over lan? if so, is there any lan requirements?
Zaziki last edited by
i have tried it a while ago. I connected two units directly via Gbit LAN. I think i read 25TB in about 30 sec.
thanks @Zaziki I'm now ambitious in giving it a go and fortunately i have gigabit connections
zjsmwht last edited by
- 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:
- 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.
- What does the "GB" number mean. All internal SATA disks show "0GB" and all USB 3.0 disks "1GB".
- Is it somehow possible to show the "100% done...". message only? Just a cosmetic issue.
- What does the "avg." and "eff." value mean exactly? First one is "average" but what's the second one?
- 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.
- the size is calculated by the plotfile names
Linke @rds said:
- 'readProgressPerRound=0' and 'showDriveInfo=false' and 'showSkippedDeadlines=false'
- 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
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.
- support for POC2 plotfiles (will read twice the data pre-fork)
- 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
Both POC2 in pre-fork and POC1 in post-fork environment are tested now.
Thanks to the testnet providers!
- POC2 switch at block 502000 (changed default)
Digidigm last edited by
@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?
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.
Digidigm last edited by
@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.
- 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!
Cybermancer last edited by
Confirmed all issues are resolved.
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
juasker last edited by
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?
@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