burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms)
-
burstcoin-jminer-0.4.9-SNAPSHOT
Download:
https://github.com/de-luxe/burstcoin-jminer/releases
Info:
I made some changes to hopefully fix connection issues and EOF bug/issue.
Not sure if it works, cause i could not reproduce it.Updates:
- readProgressPerRound=0 works now
- new property: 'showSkippedDeadlines=false' to deactivate display them (default is true)
- improved logs on connection problems
- hopefully fixed connection issues by using another executor and not limiting active connections
- fixed bug on show wrong best deadline in logs
- removed obsolete devPool support (no devPool type online anymore)
- updated libs and some minor changes
Edit: Had no time to test on pools ... will do a test right now. Maybe wait till tomorrow with updating, until i tested :-)
-
recently added an RX460 to my rig trying to get Jminer to run but all it will do is open and then close the screen right away , figured it was a driver issue or an issue with the device / platform , made sure all drivers are updated and have tryed device's 0/0 , 0/1 , 1/0 , 1/1, and no change
-
@Gibsalot You need to have the correct java version, which is not necessarily the most recent one from auto-update. You can also add 'pause' at the end of your batch file, then the window will stay open so that you can see what the error caused is.
-
What exactly do I need to install to run jminer? opencl driver is supplied with the nvidia driver I have installed and I have 64bit java installed.
-
@newsense2004 That should be it. Configure the platformID and deviceID as per gpuplotgenerator setup.
-
@haitch Finally got it working thanks.
-
burstcoin-jminer-0.4.10-SNAPSHOT
Download:
https://github.com/de-luxe/burstcoin-jminer/releases
Updates:
- 'debug=true' will now show details of 'NOT confirmed' deadlines, like the correct plotfile that caused it.
- new solo mining property 'recommitDeadlines', if set to true, it will recommit promising deadlines multiple times in a interval of a few seconds.

- fixed bug with solo mining property 'triggerServer', that had no effect.
- updated libs to latest versions.
-
@luxe thanks!
-
@luxe Thank you for your hard work and contribution to Burst. As always, Luxe keeps enhancing the miner :)
Is it possible to add a web interface feature with the miner to monitor the miner from distance and to trace and track submitted DLs over time?
-
@rnahlawi Currently the miner does not 'track' history except from logging. So first the miner would need a database to store his stuff into. 2nd whatever service could provide data from that database etc.
So sure everything is possible ... just a question of prio ... so much other things to do :-)
-
Hey @luxe I am curious about this property (chunkPartNonces), what does it mean exactly and how it could impact mining depending on the plots we have?
thanks :)
-
@vExact said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
Hey @luxe I am curious about this property (chunkPartNonces), what does it mean exactly and how it could impact mining depending on the plots we have?
thanks :)I ran a test on my miner using two different capacities. A small one (16TB) and a large one (88TB). Both showed the the lowest scan times when ChunkPartNonces (CPN) was near a value where CPN/TB~4096, I don't use the 320000 default but use powers of 2, so for each of these capacities, 16TB CPN=65.536 and 88TB CPN =524.288. Your mileage may vary possibly by GPU, CPU etc.
-
@rds interesting :) thanks for your input. But why particularly 4096? my drives are all 64kB formatted, could this also need to be taken into account or just the way plots are generated? I use Xplotter btw.
-
Well I should have had first read the description in the jminer.propertis lol
It is related to the stagger size of the plots :)# ----------------------------------------------------------------------------------- # chunkPartNonces - staggerSize defines number of nonces per chunk. # (default:320000) the miner will split chunks in smaller pieces called chunkParts. # this makes sense, to save memory and optimize speed. # in the best case chunkPart#1 will be checked before chunkPart#2 is # completely read ... depending on the power of your GPU. # if staggersize is smaller than chunkPartNonces, staggersize will be used. # e.g. play with +/- 160000 steps
-
@vExact , 4096 was derived empirically. I ran the miner on both sizes, 16TB and 88TB. They were running at the same time. So two instances of JMiner running at once. CPNs were varied for each run (3 rounds average scan time recorded) using CPN values:
16384
32768
65536
131072
262144
524288
1048576 and 2097152.Lowest average scan times using lowest CPN (memory) occurred near CPN/TB=4096.
Why 4096? Maybe because there are 4096 scoops in a plot file, maybe 64*4096 is the amount of memory used to construct one nonce, don't know for sure.
Also, the 2GB CPN crashed the system.
-
@rds so then following your reasoning and trials you made the optimal value for CPN would be the stagger size used for all your (optimized) plots where this value is a number with 2^n, meaning that the GB per plot is also a 2^n number. In any case let's wait for luxe to give his input here :)
-
@vExact said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
@rds so then following your reasoning and trials you made the optimal value for CPN would be the stagger size used for all your (optimized) plots where this value is a number with 2^n. In any case let's wait for luxe to give his input here :)
No, CPN would be total size of all your plots in the scan directories, as reported by the JMiner at 100%, in TB*4096. I like to push this number to a power of 2, as I believe it is more efficient as memory is structured in binary.
-
@vExact said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
Hey @luxe I am curious about this property (chunkPartNonces), what does it mean exactly and how it could impact mining depending on the plots we have?
thanks :)Well, the miner does not read one scoop and computes it.
It reads all scoops of staggersize/chunk into memory and than computes that data package.
On optimized plotfiles the miner would read all data of a plotfile first, and than compute it.
(without chunkPartNonces)Therefore there is the chunkPartNonces ... the miner divides the staggersize/chunk by chunkPartNonces to get a number of 'parts' he reads and than computes.
https://github.com/de-luxe/burstcoin-jminer/blob/master/src/main/java/burstcoin/jminer/core/reader/task/ReaderLoadDriveTask.java#L118
So on staggersize 8000 and chunkPartNonces 800 the miner will read and compute 10 parts, one after the other. It can compute part#1 while part#2 is still being loaded (different/independent thread pools) ...
So depending on your system memory / cpu and gpu ... the perfect size of chunkPartNonces may vary.
In general: lower = less memory usage, more cpu usage ... higher = more memory, less cpu usage.Currenty i'm using chunkPartNonces=920000 for my setup.
Edit: btw. if staggersize is smaller than chunkPartNonces ... chunkPartNonces has no effect at all. So it is for optimized plotfiles or plotfiles with high staggersize.
-
@luxe thanks for your reply. Let's say now I have a 2,56Tb mining capacity, consisting of 10 plots of 256GB each (1048576 nonces and staggersize for optimized plots). In this case which would be the optimal setup for chunkPartNonces?
-
@vExact for 2-3TB it does not matter much, just leave it like it is if you have no cpu or memory issue.



