GPU plot generator v4.1.1 (Win/Linux)



  • @cryo

    I have successfuly compiled 4.0.4 on CentOS6.9 for NVidia.
    (kernel 2.6.32-696.3.1.el6.x86_64 and gcc-4.8.2 ).

    Compiling for AMD works (AMDAPPSDK-2.9-1)
    Problem is, I also have a R9-280x in the box, it is displayed, but when configuring it I do not get the opencl data for the GPU but for the CPU:

    Do you have a hint for me ?

    # bin/gpuPlotGenerator.exe listPlatforms
    -------------------------
    GPU plot generator v4.0.4
    -------------------------
    Author:   Cryo
    Bitcoin:  138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
    Burst:    BURST-YA29-QCEW-QXC3-BKXDL
    ----
    Platforms number: 2
    ----
    Id:       0
    Name:     AMD Accelerated Parallel Processing
    Vendor:   Advanced Micro Devices, Inc.
    Version:  OpenCL 1.2 AMD-APP (1445.5)
    ----
    Id:       1
    Name:     NVIDIA CUDA
    Vendor:   NVIDIA Corporation
    Version:  OpenCL 1.2 CUDA 8.0.0
    
    # bin/gpuPlotGenerator.exe listDevices 0
    -------------------------
    GPU plot generator v4.0.4
    -------------------------
    Author:   Cryo
    Bitcoin:  138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
    Burst:    BURST-YA29-QCEW-QXC3-BKXDL
    ----
    Devices number: 1
    ----
    Id:                          0
    Type:                        CPU
    Name:                        Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
    Vendor:                      GenuineIntel
    Version:                     OpenCL 1.2 AMD-APP (1445.5)
    Driver version:              1445.5 (sse2,avx)
    Max clock frequency:         2600MHz
    Max compute units:           16
    Global memory size:          63GB 11MB 436KB
    Max memory allocation size:  15GB 770MB 877KB
    Max work group size:         1024
    Local memory size:           32KB
    Max work-item sizes:         (1024, 1024, 1024)
    
    # ldd bin/gpuPlotGenerator.exe 
    	linux-vdso.so.1 =>  (0x00007ffe9d1b3000)
    	libOpenCL.so.1 => /opt/AMDAPPSDK-2.9-1/lib/x86_64/libOpenCL.so.1 (0x00007fb1dbae8000)
    	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb1db7d5000)
    	libm.so.6 => /lib64/libm.so.6 (0x00007fb1db551000)
    	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb1db33b000)
    	libc.so.6 => /lib64/libc.so.6 (0x00007fb1dafa6000)
    	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb1dad89000)
    	libdl.so.2 => /lib64/libdl.so.2 (0x00007fb1dab85000)
    	/lib64/ld-linux-x86-64.so.2 (0x00007fb1dbcf0000)
    
    


  • @luxe Thank you for your feedback. Yes I totally agree with you: the more RAM you have the faster it'll be. I reorder the generated plots in the CPU RAM buffer before writing 4096 times to the final file, no matter what the PLOTS_NB is.
    Another tweak is to ensure the CPU RAM buffer is envenly dividible by the GPU RAM size. Thus the graphic card won't be put on hold while the writing occurs.

    @vaxman The direct mode improvements are on the 4.1+ version. I updated the plotter to v4.1.3 to support CentOS (6 & 7) build (there is even CentOS binaries compiled against CUDA 8.0 SDK on my repository now).

    About your mixed AMD/NVidia environment, there is no runtime inter-compatibility between AMD and NVidia cards for now.
    Nevertheless, you can build two plotters: one with the libOpenCL.so from the CUDA SDK, and one with the AMD SDK. You won't be able to plot to one single file with your two cards together but it's not the best choice anyway if you use the direct mode.



  • @cryo can you explain this please, i think it would be usefull for all Nvidia users

    I have MSI GTX 1060 6Gb, DDR3 8Gb RAM, Geoforce Game Ready driver 382.53
    AMD Phenom II X6 1055T
    Using GPUplotter 4.1.1

    Recommended parameters: 1 0 6144 768 8192 - driver crashes
    1 0 1536 192 4096 - plotting speed dropping from 40-30k nonces to 11k
    1 0 2048 256 4096 - same speed, dropping to 11k - and system constantly lagging
    1 0 2048 256 2048 - 16.7k speed! system lagging too
    1 0 2048 192 2048 - 16.7 - 17k speed, rare lagging

    What i dont understand or doing wrong, why lower values, give better speed.
    And why system is constantly freezing?



  • @Weasel To solve the lag issue, as explained before, the last parameter (hashesNumber) is in charge of cutting the most intensive job to pieces.
    If your graphic card is tied to your display (if it's the one your system use to render your desktop and active windows), a value of 4096 won't let free time to your OS to send desktop refresh rendering. So the system will simply kill your process (there is a watchdog for that on every modern OSes).

    So, in brief, you don't have to lower the other parameters, just the last one, to a very low value (like 4 for example). There will only be more orders sent from the plotter to the GPU, but it shouldn't affect the whole througput.
    The best thing to do, of course, is to dedicate the graphic card to the plotter. Use you CPU graphic card (Intel graphics most likely) to render your desktop.

    Once you don't experience lags anymore, you can begin to touch to the other parameters to enhance the overall nonces/min. That part is entirely GPU dependant. From my tests, the globalWorkSize should be near the maxAllocationSize. For the localWorkSize, just try powers of 2 until you find the best value.



  • Hello, I am very new to Burst and cryptos in general but I really liked the idea of mining using a HDD. I am running into some issues while using the GPUPlotGenerator.

    First some back story. I looked up how to set up plots via YouTube and I started using the GPUPlotGenerator. I was running tests on small plots so see how everything worked and then yesterday I decided to attempt doing my first large plot (1500GB) using direct. I had the plotter run and I noticed it was not updating the % value. I did however notice that the plot on the drive was getting larger so I figured the update was just lagging behind. I woke up this morning to see that the plot was now the correct size but the percent was now updating at an incredibly slow amount. That is when I found this forum and read through everyone's very awesome replies. Now I know that I was using an older version of the GPUPlotGenerator and it will no longer take hours to create the initial harddrive space for the plot. However, I am still getting very slow plot times (1000 nonces/min). I am also monitoring my GPU and it will hit 100% load for a very short time (30 seconds) and then not use the GPU for a very long time. This leads me to believe that it is not my GPU being the bottle neck even though I am using a AMD Radeon R9 200 Series 2GB. The external that I am writing to is a Seagate Expansion which (from reading other posts) is very slow for plotting but my 1000 nonces/min seems extraordinary slow compared to what I have read. I have tried running tests for 1TB on my internal HDD using the newest version of the GPUPlotGenerator and I am receiving very similar results. My internal harddrives are 3 1TB Seagates configured in RAID 5.

    My Device.txt is set up like this: 1 0 1024 128 8192.

    If anyone has any insight on how to best speed up plot times I would greatly appreciate it. That or I will have to plot a 8TB in 2 weeks >_>

    Thanks!


  • admin

    @RandAlthor

    The external that I am writing to is a Seagate Expansion

    This an SMR drive, your plotting experience is going to be painful, but once done you'll mine just fine.



  • @haitch Thanks for the reply. I have been running some more tests and I am having much better performance using the buffer mode (17000/min). From my understanding, it will not create optimized plots and I will later have to optimize the plots. Since I ultimately want my plots to be optimized, should I first create them using the buffer mode and then optimize them or is it better to just plot them using Direct?

    Also, when using direct I get long (like an hour+) periods where the percent will not change and seems frozen. Is that expected?

    Lastly, do you have a recommendation on non-SMR external drives so I can be sure I purchase something that is good but also cost effective? Or is it just best to get the most $ per TB and then grit me teeth through the painful plot creation?

    Thanks!


  • admin

    @RandAlthor If you have the space, plot buffered, then optimize to the new drive.

    As for new storage: https://forums.burst-team.us/topic/6215/bulk-purchase



  • @haitch is there a thread for how to optimize plots post creation similar to how this one talks about the GPU Plot Generator? I thought I saw one earlier but I can't find it now. Also, are Western Digital the only non-SMR drives or are there others? I don't think I am ready to do a bulk purchase at the moment since I am still very new and just trying grasp how this stuff works.



  • I tried optimizing plots after creation. I was unendurably lengthy. I decided to nix that process and just replotted the drive from scratch.


  • admin

    @RandAlthor The bulk purchase can be 1 drive - it's bulk for the whole community, but you can get 1.

    As for non-SMR, pretty much anyone other than Seagate - WD, Samsung, HGST ...



  • @haitch Ah thank!

    @vmantilla did you experience major low downs when plotting with Direct? When I try to plot just 1TB, it will slow down to and sometime hang for an hour+. Maybe this is because the drive is an SMR?

    Also, does the difference between SMR and non-SMR only really show when plotting or is it a big difference when mining too? It would be ok if I just buy one non-SMR and then create an optimized plot to it then copy it over to a cheaper SMR drive, rigt?



  • @cryo anyways to resume the plot like xPlotter does :? ( just a enhancement )



  • @haitch would it be faster to plot direct to a drive that is not SMR? then transfer or no?


  • admin

    @HiDevin plotting to a regular drive, then transferring will be faster, but when I tried it, Windows was telling me it'd take 10 days to copy the file. Your mileage may be different .......



  • @haitch i did that with a 1tb file it took 7 hours to transfer i decided to just replot the next drive... giving gpuplotgen a whirl in direct mode on a usb 3.0 4tb sata 3 tb and usb 2.0 1tb drive.... the 4tb said it will be done in 17 hours...


  • admin

    @Lunas Good luck with that ............



  • @HiDevin Not for the moment. I have too much work to add this feature for now.



  • @Lunas said in GPU plot generator v4.1.1 (Win/Linux):

    I decided to just replot the next drive... giving gpuplotgen a whirl in direct mode on a usb 3.0 4tb sata 3 tb and usb 2.0 1tb drive.... the 4tb said it will be done in 17 hours...

    What GPU & Pc Etc are you using? Please let us know if it works out Ok. And what your (successful) Devices/Command parameters are. Thanks.



  • @BeholdMiNuggets i need to play with my devices file but currently
    im using 1792 192 8192
    with a r9 280x
    when i left it earlier it was going at 13k n/min with an estimate of 17 hours on the 4tb drive

    the pc is as follows
    Asrock a88x fata1ty killer+
    amd athlon x4 845
    8gb 2133mhz

    my drives are as follows
    1x 240 gb m500 crucial ssd no plots boot drive
    2x 4tb WD my books
    1x 3tb HGST Ultrastar 7K4000 enterprise
    2x 1tb wd essentials usb 2.0 with wd green warranty is up might shell them
    1x 500gb toshiba pocket size external
    1x 500gb hitachi 2.5" drive laptop salvage
    1x 500gb WD green
    1x 250gb hgst 2.5" laptop salvage
    1x 160gb hgst 2.5" laptop salvage
    1x 1tb WD black only 400gb it has other things on it...
    i also have all my thumb drives and micro sd that were not being used on it too... totaling 352gb
    4x 16gb thumb drives
    1x 32gb pny thumb drive slow and no longer reliable
    1x 32gb san disk
    32gb g.skill micro sd class 10 (10mb/s writes)
    64gb sony micro sd class 10 (best write speeds of the 3 24-40mb/s)
    128 gb pny micro sd class 10 (might be counterfeit has a slow write speed when advertised at much faster)

    Star tech 4 controller usb 3.0 pci-e 4x


Log in to reply
 

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