burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms)
-
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.
-
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.
-
@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
- if a drive have plot files where the filename indicates a longer file than the actual file size, the console line
-
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.
- You are right, the size calculations are based on the filename, i did not expect that miners are using 'incomplete' plotfiles ...
-
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.
-
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
-
Hi best config jminer.properties
winnerRetriesOnAsync=?
winnerRetryIntervalInMs=?
targetDeadline=?
restartInterval=?
chunkPartNonces=?
refreshInterval=?
connectionTimeout=?
-
I tried to use best values as default. Please read the comments in jminer.properties,
should explain the function.winnerRetriesOnAsync=?
winnerRetryIntervalInMs=?is just to receive winner, if it works for you, settings are ok.
restartInterval
feature was removed
conenctionTimeout
If you get no timeout errors it is fine.
targetDeadline
Has only effect on solo
chunkPartNonces
Read in jminer.properties comments
refreshInterval
Interval to check for new block, 1000ms should be fine.
-
PlotsCheker verifi ok. but I get this error jminer. Error: ReaderPartLoadedEvent for unknown chunkPartStartNonce: '500000001'! Please check for plot-file duplicate or overlapping plots e.g. use https://bchain.info/BURST/tools/overlap.
What I can do?. Thanks
-
First, that does not effect your mining ... just notifies you, that you have overlapping plots.
You could post your plotfile-names here, and i take a look.
-
I have been using version 0.3.4 for a long time, thought it was a good time to update, but it is telling me that my version of Java doesn't support 64 bit, do you know which one I have to use?
-
you can remove -d64 from start bat, to enable 32bit.
but if your system supports 64bit, install java64bit
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
-
6238401638398757545_500000001_3738944_3738944
-
@ajqjjj said:
6238401638398757545_500000001_3738944_3738944
This is not your only plotfile, guess there is another starting with 500000001 ?
If not, try:
https://forums.burst-team.us/topic/348/plotschecker

