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



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


  • admin

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

    It was just the number i use, too ... some other like the above also reported this range to be the 'golden' number. So it was just luck ... i saw your ram usage was very low and due to you had all optimized plots ... increasing chunkPartNonces would make sense.
    The perfect number for sure depends on hardware/gpu used ... thats why i wrote in miner config ... everyone should play with that value in 160000 steps.


  • admin

    @rds tried for my setup ... was few seconds slower than 960000 ... fear your formula is a little to simple, due hardware should have influence.



  • @rds Yeah, I just tried 524288 and that put me around 31-32 seconds. Maybe a bit faster than default (more testing needed), but I'll stick with 960000.



  • @sevencardz , when I ran my test, and yes I realize each system would be different, I picked the setting that used the least ram and still had the fastest time. Anything above my number still produced the same times within a few seconds.



  • @rds Well, a few seconds is a lot of time if you add up every single round you mine. :) For me, the times fluctuate 1 - 2 seconds from one round to the next, so it's hard to judge from just a few dozen tests whether the tweak did anything at all. Better to take the average scan time over 100 rounds or so for each chunkPartNonces, but I'm not going to bother. I've never seen a scan time below 30 seconds with all 13 of my drives until I tried the 960000 value, so I'm keeping it.



  • @sevencardz , that's my point. This observation is over 5-10 rounds. 1-2 seconds means -1 once +1 next even next. My point is I don't want to eat up extra memory for what is probably a negligible gain.



  • Hi all,

    New to burst, trying to figure out if I should use blago's miner or jminer. Both work.. but I can't tell which is more efficient for me. Is there a simple way to figure this out? There's a lot of numbers and I'm not really sure what all of it means yet. I just want to mine most efficiently. Currently mining around 7.5 TB on a 4 GHz Core i5 (OC) with a GTX 1060 3 GB card.

    I believe I should be using jminer as it is GPU-accelerated but almost everyone on pool.burstcoin.party uses blago.


  • Mod

    @minsc_tdp, use jminer, GPU-miner - faster than CPU-miner



  • Thanks blago. Why do you suppose so many people are still using blago miner? It's like 98% over on the burst party pool.


  • admin

    @minsc_tdp How about try creepMiner :-)


Log in to reply
 

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