burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms)



  • 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)

    alt text alt text alt text

    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


  • admin

    @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:

    1. 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.
    2. What does the "GB" number mean. All internal SATA disks show "0GB" and all USB 3.0 disks "1GB".
    3. Is it somehow possible to show the "100% done...". message only? Just a cosmetic issue. :-)
    4. What does the "avg." and "eff." value mean exactly? First one is "average" but what's the second one?

    alt text

    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.

    1. The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
    2. Modify the source code and recompile and you can make it say whatever you like. :)
    3. 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.

    1. The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
    2. Modify the source code and recompile and you can make it say whatever you like. :)
    3. Dunno this one.
    1. 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%.

    2. 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.

    1. The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
    1. 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.

    1. 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.

    1. The GB number is just size. Some of your 8TB drives seem to be a bit larger than 8TB. Lucky you.
    2. Modify the source code and recompile and you can make it say whatever you like. :)
    3. Dunno this one.
    1. 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%.

    2. Pretty sure average is for that readout segment, effective over the entire round.

    1. I have that switch already enabled set to 1. As you say this gives me 1 and 100...only 100% would be fine. :-)
    2. Ok, thank you!

  • admin

    @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:

    1. 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.
    2. What does the "GB" number mean. All internal SATA disks show "0GB" and all USB 3.0 disks "1GB".
    3. Is it somehow possible to show the "100% done...". message only? Just a cosmetic issue. :-)
    4. What does the "avg." and "eff." value mean exactly? First one is "average" but what's the second one?

    alt text

    Thanks!

    1. 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.
    2. the size is calculated by the plotfile names
      Linke @rds said:
    3. 'readProgressPerRound=0' and 'showDriveInfo=false' and 'showSkippedDeadlines=false'
    4. avg = over the whole round, eff. = since last log ... e.g. perfect configured setup would not get slower/lower eff. in the end.


    1. Yep, every plotPath points to one physical drive. 'readerThreads' is set to 0.
      This is how it looks like with no internal disks:

    alt text

    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).

    alt text


  • admin

    @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 config

    I have 8 GB RAM installed. 1 GB is reserved as NVRAM for the integrated R7 cores of the AMD CPU.

    alt text

    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.

    alt text

    alt text

    Maybe tomorrow I have some time to try a dedicated GPU.


  • admin

    @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.



  • @luxe Holy crap, that's it man!
    'scanPathsEveryRound' was already set to false, 'chunkPartNonces' did it!
    Will play around a little bit with other numbers.
    Without remote access rounds are finished within 40 sec.

    alt text

    alt text


  • admin

    @eneloop Yep looks much better now :-) Happy mining. Wow i expected some improvements, but that is has such a huge impact ... i was totally wrong with hardware causing you issues, too.

    Edit:
    Remember you get real numbers only on 2nd round running ... as for first round after start, there may be still data in caches. Important while testing out other numbers.



  • @luxe It looks like 'chunkPartNonces=960000' is already a really good number. How did you estimate this number for my setup?
    Now I have something around 900 MB/s eff. 900 MB/s seems to be the maximum for this setup (mainboard+cpu+ram), because 19 drives are able to read more than 900 MB/s. Just to get a feeling for this number: How fast is that in comparison to other setups? Are there way faster setups out there (with consumer boards, not server hardware)? I mean, AMD FM2+ plattform is far away from high-end. Thanks!



  • @eneloop said in burstcoin-jminer v0.4.10 - GPU assisted PoC-Miner (All Platforms):

    @luxe It looks like 'chunkPartNonces=960000' is already a really good number. How did you estimate this number for my setup?
    Now I have something around 900 MB/s eff. 900 MB/s seems to be the maximum for this setup (mainboard+cpu+ram), because 19 drives are able to read more than 900 MB/s. Just to get a feeling for this number: How fast is that in comparison to other setups? Are there way faster setups out there (with consumer boards, not server hardware)? I mean, AMD FM2+ plattform is far away from high-end. Thanks!

    I did a test on my system and found best chunkparts nonce for me was ~4096*size of farmed files (TB).

    I get 900-1100 MBs.



  • @luxe @eneloop @ChuckNorris There's definitely something to this chunkPartNonces tweak...

    13 x 8TB drives, GTX 960
    Tested each scenario back and forth over a dozen rounds or so:

    chunkPartNonces=381440, avg ~790, eff ~300, round time 32-33 seconds
    chunkPartNonces=960000, avg ~840, eff ~440, round time 30-31 seconds

    Just a second or two faster, but I'll take it. :)

    EDIT: Also tried 1920000 a few times, but saw no difference to 960000.



  • @sevencardz , try 524,288 see what you get??

    13 x 8=104.
    104 x 4096=425,924.
    2^19=524,288 (I like powers of 2).


Log in to reply
 

Looks like your connection to Burst - Efficient HDD Mining was lost, please wait while we try to reconnect.