GPU plot generator v4.1.1 (Win/Linux)


  • admin

    @agente If generating in direct mode, there is a lot of disk activity without actual plotting at the beginning. However @cryo has released a new version that resolves this. Check for the new version.



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

    Error 112 is ERROR_DISK_FULL. Sounds like you doesn't have enough space on one of your disks.

    The disks are the same make/model/size. They were formatted before (Gpu) plotting, and a "plots" directory added. (But the resulting error is the same, even when there is no directory).

    The Nonces (number total per disk) is the same as per previous (of the same) HDDs already plotted (via Cpu). So the Drives are not full, nor are they under-Capacity for the new Gpu plot/s.

    But still getting the same "Error 112". Any suggestions? Unfortunately, the alternative, plotting via CPU, takes several days, per HDD.
    Thanks.



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

    Error 112 is ERROR_DISK_FULL. Sounds like you doesn't have enough space on one of your disks.

    After readjusting all of the numbers & parameters, the previous error message has vaporised...
    Only to be replaced by another one!
    [ ERROR ][ -5 ][ CL_OUT_OF_RESOURCES ] Error in step2 kernel launch

    But don't see this message anywhere in the ReadMe /##Troubleshooting section.
    Does the cognoscenti have any more sage advice? Thanks.



  • @BeholdMiNuggets doesn't that mean that the devices.txt isn't optimized for your system, causing it not to startup?



  • @haitch newer than 4.1.1.. I hope he release new ver on github



  • @BeholdMiNuggets The error CL_OUT_OF_RESOURCES is not so self explaining that it sounds. In brief: your card can't process the second step of the GPU kernel with your actual parameters (globalWorkSize and localWorkSize). This step is the most intensive one as it fills the GPU buffer with scoops by performing a lot of shabal hashes.

    To fix that:

    • Make sure your globalWorkSize can evenly divide your localWorkSize.
    • Try with lower localWorkSize values. If you run the listDevices command on your GPU platform it'll output some hints from the card (like the maxComputeUnits and maxWorkGroupSize soft values).

    You may say "why can't the plotter automatically determine those tricky parameters", the simple answer is: because the returned hint values don't ensure the success. In fact, most of the time, what graphic cards claim to support doesn't match with reality.

    Via the setup command, my actual strategy is:

    • for globalWorkSize, to take the minimum value between globalMemorySize / PLOT_SIZE and maxMemoryAllocationSize / PLOT_SIZE.
    • for localWorkSize, to take the maximum value between 1 and (maxWorkItemSizes[1] / 4) * 3. This formula sucks but it has the best results for now.


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

    ... In fact, most of the time, what graphic cards claim to support doesn't match with reality.

    \ gpuPlotGenerator ListDevices 2
    GPU plot generator v4.1.1
    Devices number: 2
    Id: 0
    Type: GPU
    Name: GeForce GTX 1080 Ti
    Vendor: NVIDIA Corporation
    Version: OpenCL 1.2 CUDA
    Driver version: 382.53
    Max clock frequency: 1670 MHz
    Max compute units: 28
    Global memory size: 11GB 0MB 0KB
    Max memory allocation size: 2GB 768MB 0KB
    Max work group size: 1024
    Local memory size: 48KB
    Max work-item sizes: (1024, 1024, 64)

    [devices.txt] --> [ 2 0 1024 1024 1024 ] /Ok?

    There are only a limited number of Cuda Pascal cards that can effectively Plot HDD for Bursting. Afaik, the various vendor versions alter the cooling & design, but this has no significant affect on the underlying performance & capabilities of each Nvidia Gpu.

    So the optimal [ Gpu Plot Generator 4.1.1 ] settings for all variants of the Gtx-1080Ti/1090 (for example) would be the same between manufacturers /models. Given this, it might be useful for Burst-Team users to publish what works for them, by Nvidia model. That is, the contents of their Working [devices.txt] file, and the Cmd line parameters.

    It seems counter-productive for every punter to have to corral so many variables in order to make this work!
    Thx.



  • @BeholdMiNuggets
    For your device.txt file, you can try : 2 0 8192 1024 8192
    In depth:

    • globalWorkSize: 8192 = 2GB GPU RAM
    • localWorkSize: 1024 = 1024 CUDA cores
    • hashesNumber: 8192 if your card is tied to your display, else 4.

    About the devices list, I totally agree on this. That was the idea behind an issue I opened a while ago. At that time I haven't found many volunteers to share and collect those parameters.

    I can gladly add a file on the official repository to list all the devices reported by the community along with working parameters and average nonces/minutes.



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

    @BeholdMiNuggets
    For your device.txt file, you can enter...

    Thanks, I'll try your suggested parameters tomorrow.

    • hashesNumber: 8192 if your card is tied to your display, else 4.

    Was not aware that the GPU being plugged up to a display made so much difference, but will adjust accordingly.

    About the devices list, I totally agree on this. That was the idea behind [an issue I opened a while ago]

    I'm guessing that there are only about a dozen Video Cards that are most prevalent for Burst-Plotting, so it's not a huge task.

    I can gladly add a file on the official repository to list all the devices reported by the community along with working parameters and average nonces/minutes.

    Hopefully, the punters on this Forum (& others) can provide some data.



  • @BeholdMiNuggets The hashesNumber should be renamed as intensity. Performances are almost the same between 8192 and 4. It's just that the global work will be divided in more steps to allow the graphic card to answer to standard display rendering calls, or else a watchdog kills the plotter to prevent the display to hang.



  • Trying to find optimal parameters for my GTX 1060 6gb card:
    Using Windows 7 x64, 8gb RAM, HexaCore AMD Phenom II X6 1055T, 2800 MHz (14 x 200)
    MSI gtx 1060 6gb (default values for core and mem), Geoforce Game Ready driver 382.53

    Config gives me following recommended parameters:
    1 0 6144 768 8192
    But it never started, driver crashes, out of resources errors.

    For me, the solutiong was in halving parameters in devices.txt
    Started with this: 1 0 6144 768 8192
    Now its: 1 0 1536 192 4096

    It works now in "direct" mode with my GTX1060 6gb.
    But the speed at start was 40 000 - 30 000 nonces per minute
    and dropped to 11 000

    GPU TDP jumping from 5% to 41%
    Temperature of GPU chip rised to 67C

    Tried this ones 1 0 2048 256 4096 - worked for 5 mins and driver crashes again.
    If i can help to someone with my hardware, to find a solution or optimised numbers PM me



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

    Trying to find optimal parameters for my GTX 1060 6gb card:
    Using Windows 7 x64, 8gb RAM, HexaCore AMD Phenom II X6 1055T, 2800 MHz (14 x 200)
    MSI gtx 1060 6gb (default values for core and mem), Geoforce Game Ready driver 382.53

    Config gives me following recommended parameters:
    1 0 6144 768 8192
    But it never started, driver crashes, out of resources errors.

    Are you sure about that <platform> value of [ 1 ]? Can you print out your > listPlatforms.
    I thought Windows/Nvidia was [ 2 ]. (With 0 being Windows/CPU, and 1 being Windows/AMD).
    Eg. devices.txt [ 2 0 6144 768 8192 ] in your example.



  • Sure
    0_1498218023419_devices.jpg


  • admin

    Found some time to finally test improved 'direct' mode in 4.1.1 (win)
    Impressive work @cryo, thanks a lot. I always used the 'buffer' mode until now, due it was faster for me, to use that and optimize after that. But now 'direct' mode works just awesome, and i love directly create optimized plots.

    As i plotted with the same GPU that is used for mining with jminer ... I had to choose some quite conservative settings in devices.txt, to not slow down mining too much. So for my 'RX 480' i used:

    1 0 8192 256 4096
    

    I only plotted to one drive at once for now. I suggest use as much memory as possible, as it reduces the needed drive operations and speeds up plotting a lot.

    My 'plot.bat' file to be able to run as admin:

    @setlocal
    @cd /d %~dp0 
    gpuPlotGenerator.exe generate direct E:/temp/12760599261465029898_7200000000_15257600_102400
    @pause
    

    15257600 for a ~4TB drive
    102400 to use 25GB of RAM (using ~6,25GB RAM reduces my nonces/minute by 25% )

    The result:
    0_1498222271286_Unbenannt.PNG

    Quite sure i can tweak it a little more, but for me, even with the conservative settings, it was twice as fast as plotting optimized via CPU.
    Round times with jminer increased by ~50% while plotting ... but both worked flawless together on same GPU.


Log in to reply
 

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