burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms)
-
@Gunner101 Your config looks ok. I tried google for the exception you got, all i could find was, that your connections got terminated ... maybe by underlying OS ... got no real solution for you.
You could test if another pool works better for you. Others reported this error before, but until now i could not reproduce it, what makes it hard for me to search for a solution or debug into it.
I made little changes on jminer and provided you a download via PM, but not sure if they will solve this kind of issue, but worth to try.
-
@Gunner101 Thanks for providing the logfile. No more time right now, will take a more deep look into it later. For now you could 1. disable debug mode and live with it. 2. Try another pool or Blagos miner, with 11TB you do not absolutely need GPU support, maybe it works better for you.
https://github.com/Blagodarenko/miner-burst/releases
If you get comparable errors there, it would at least indicate, it has nothing to do with jminer :-)
-
@luxe thanks for spending time with me to try and fix it and ill try some stuff at my end as I mentioned on dropbox. peace :D
-
@Gunner101 thanks for feedback and testing ... i can only improve things, if i know the problems. But re install win will not help, there are connections getting terminated and we need to find out why ... could be 1. pool side 2. your network 3. jminer ... therefore i asked you to switch pool, to eliminate reason 1 while i checked reason 3. :-)
-
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 :)


