burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms)
-
@luxe that worked hehehe
thanks bro!
-
@gpedro Well guess i have to check why https does not work ... i expected miners to use localhost :-) Never tested something else ...
-
@luxe yeah I thought so but I still didn't got the local wallet running on this PC hehe
-
got it Running, but for now pretty slow.
I have about 92TB, Read times ~2min 34s
With Blago i need about 52s in i7 4770.there must be sth wrong.
All my plots are optimized and One File per Drive.
I Read that r9 280x only Support opencl 1.2, is there maybe the Problem?
-
i tried to solo mine but even though its set up properly, local wallet up to date, I see blocks won by others but my disks aren't being read so its not mining. In actual fact, the disks have gone to sleep lol. Any suggestions? is there some sort of limitation such as passphrase length?
-
@Zaziki 280x is fine ... are you sure you use it? Please provide more details like screen of miner and/or your config.
@ZapbuzZ The miner will start mining as soon the connected wallet receives a new block ... if you provide your config i can take a look on it (without passphrase ... that is not limited as far as i know).
-
ok ty @luxe thanks for information. i decided to go to a pool for now. If I decide to mine solo mode again i will post the config.
-
@Luxe, note that in the config file the target deadline is listed in the solo section of the code, as if it's not applicable to pool mining. There are some pools, specifically the Lex code that does not override this value so it will apply when pool mining on Lex code pools. If someone sets up a short Target DL like 14400 for solo mining and forgets about it and swaps over to a lex code pool they will loose many DL submissions as skipped.
On your next revision, you may want to consider moving it into a more general section of the file. Just a thought.
-
@luxe Sorry for my late answer.
After finishing plotting, times got better - but still i think that 1400MB/s are not that fast. I read that u do 3500 with the same GPU.
Here Some Screens (startupInfo, plotted Files, oneBlock)
Some Info:
I have 6 Drives at the Mainboard internal SATA Controller (SATA6G).
Another 3 Drives are at a Adaptec 6805E Controller
all other Drives are connected via USB 3.0
-
@Zaziki i have more drives/controllers than you, due to parallel reading i reach higher MB/s (~30 sec round time is fine) ... your setup so far looks very good. Btw. you can mount drives to directories, you do not need to assign a-z drive letters ... https://technet.microsoft.com/en-us/library/cc753321(v=ws.11).aspx#BKMK_WINUI
-
@luxe thanks mate
-
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:
- 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?
Thanks!
-
@eneloop 1. I would guess that the R7 does not have enough threads to spawn one for each of your drives, so it has to recycle the threads after they're done reading the first dozen or so drives. You'll probably need a discreet GPU to turn those 70 second read times into 35 second ones.
- The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
- Modify the source code and recompile and you can make it say whatever you like. :)
- Dunno this one.
-
@sevencardz said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
@eneloop 1. I would guess that the R7 does not have enough threads to spawn one for each of your drives, so it has to recycle the threads after they're done reading the first dozen or so drives. You'll probably need a discreet GPU to turn those 70 second read times into 35 second ones.
- The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
- Modify the source code and recompile and you can make it say whatever you like. :)
- Dunno this one.
-
you don't have to modify the source code. There is a switch, "readProgressPerRound", in the config file. If you set it for 10 it will read out in 10% increments. If you set it for 2 it will readout 51 and 100. Set it for 1 and it should give you 1% and 100%.
-
Pretty sure average is for that readout segment, effective over the entire round.
-
@sevencardz said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
@eneloop 1. I would guess that the R7 does not have enough threads to spawn one for each of your drives, so it has to recycle the threads after they're done reading the first dozen or so drives. You'll probably need a discreet GPU to turn those 70 second read times into 35 second ones.
- The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
- I don't think this issue is related to the number of threads because I tried the same with only 5 internal disks. With 5 disks the times are better (because of less disks) but the USB disks are still idleing while the internal ones are read out. With 5 internal disks, additional 6 USB disks have to be read out at the same time if the limit is 11.
- The size of what is read from each disk? If yes, then jminer is not rounding. It shows 1GB only when it's at least 1GB. Wright?
Yes, they are from different manufacturers.
@rds said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
@sevencardz said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):
@eneloop 1. I would guess that the R7 does not have enough threads to spawn one for each of your drives, so it has to recycle the threads after they're done reading the first dozen or so drives. You'll probably need a discreet GPU to turn those 70 second read times into 35 second ones.
- The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
- Modify the source code and recompile and you can make it say whatever you like. :)
- Dunno this one.
-
you don't have to modify the source code. There is a switch, "readProgressPerRound", in the config file. If you set it for 10 it will read out in 10% increments. If you set it for 2 it will readout 51 and 100. Set it for 1 and it should give you 1% and 100%.
-
Pretty sure average is for that readout segment, effective over the entire round.
- I have that switch already enabled set to 1. As you say this gives me 1 and 100...only 100% would be fine. :-)
- Ok, thank you!
-
@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:
- 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?
Thanks!
- 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.
-
- Yep, every plotPath points to one physical drive. 'readerThreads' is set to 0.
This is how it looks like with no internal disks:
This is what the task manager shows me while internal disks are read out:
I:, H:, K:, J: are internal
C: system disk without mining
Z:, R:, O:, Q: are USB
Internals are read out in parallel, USB disks are idleing. I think task manager is true because beside the spinning noise I can't hear any noise from reading from the USB drives (while the internals are read out).
- Yep, every plotPath points to one physical drive. 'readerThreads' is set to 0.
-
@eneloop Ok, well i have internal and usb drives as well and i do not have that behavior ... all i can say right now, consider it is not 'only' a jminer issue but maybe a os or hardware issue, too.
TaskManager is surely true, the question is, why you have this and others don't.
jminer does not know if a drive is usb or sata ... just running a threadpool, with one thread for every drive ... seams very strange to me, why all usb drives should be handled after the sata ones.
First to try is ensure you have latest driver of usb-controllers installed ... even if i think it is unlikely the problem.Do you have all drives optimized? Did you change 'chunkPartNonces' ?
Edit:
Could you run https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx and post a screen of summary tab to help me understand what other bottlenecks are maybe the issue ...
e.g. enough memory ... is GPU at its limits?Some more detail: It is normal that not all drives read at same time in taskmanager, as the threads of cpu are limited ... but normally it should switch between drives, and not finish 1 and than read the second, thats not how it is implemented.
Maybe the only way for you to get better round times is investing in a more powerful environment ...
-
@luxe First, thanks for your help!
Latest drivers are installed. The same issue happens when USB drives are attached to the onboard USB ports of the mainboard. Drives are usually connected to a StarTech PCIe 2.0 x4 USB controller with 4 independet controller chips (I'd like to connect 4 drives each controller to have a total of 16 USB drives).
All of them have been plotted by xplotter with one single file on it, so yes they are all optimized. 'chunkPartNonces' is not defined -> 'chunkPartNonces=' in configI have 8 GB RAM installed. 1 GB is reserved as NVRAM for the integrated R7 cores of the AMD CPU.
GPU load from process explorer looks a little bit strange. It looks like it can't separate CPU from GPU load. Below you can also find a pic from GPU-z.
Maybe tomorrow I have some time to try a dedicated GPU.
-
@eneloop Thanks for the detailed screens, maybe you can improve a little by increasing default chunkPartNonces ... try 'chunkPartNonces=960000' (should increase memory usage and reduce cpu usage) and 'scanPathsEveryRound=false' for some tuning.
But after all, you attached a big capacity to a quite limited machine ... not only cpu/gpu usage counts but also the data bandwidth between components like cpu/gpu/memory. However your i/o graph indeed looks strange ... but try with the settings above. Any if it changes somethin maybe post i/o graph again.











