GPU plot generator v4.1.1 (Win/Linux)
-
@GabryRox With the buffer strategy the bottleneck part is the computing power, to some extent. However, for the direct strategy it's the IO bandwidth.
There are two solutions to efficiently use the direct strategy:- Plot to a faster disk (a SSD is the best choice), then copy the resulting files to a slower disk.
- Plot multiple disks at once, up to your computing power (based on your observations you could easily plot to 10 drives at the same time with one single GPU and fill them in the same amount of time).
@haitch The long delay is gone with the new version when you launch it with admin rights (4.1+). Still, it takes time to write each plot.
@BeholdMiNuggets The bad alloc error is a RAM issue. The [staggerSize] in the direct mode is used to determine the amount of RAM used by the process. Example:
# Will generate an optimized plots file named [123456_0_1000000_1000000] (250GB) using 250MB of RAM. ./gpuPlotGenerator generate direct 123456_0_1000000_1000
-
@cryo said in GPU plot generator v4.1.1 (Win/Linux):
@BeholdMiNuggets The bad alloc error is a RAM issue. The [staggerSize] in the direct mode is used to determine the amount of RAM used by the process. Example:
# Will generate an optimized plots file named [123456_0_1000000_1000000] (250GB) using 250MB of RAM. ./gpuPlotGenerator generate direct 123456_0_1000000_1000Thanks Cyro (& others). - Any chance you give us another, practical /eg - for optimised (gpu) plots?
~ Don't see a ReadMe file in the current version of the GPU plotter, so referencing previous editions.Eg.(just a random example!).
For an Nvidia Gtx-1080Ti GPU (aka Gtx-1090), with 11Gb of Gram /frame-buffer. On a Pc with a Total of 16Gb of RAM. And 2x 8Tb HDDs (say). ***What could /should the [ devices.txt ] file contain?
And what would the process Command Line be?Much appreciated, /B.M'Nugs.
-
@BeholdMiNuggets The
README.mdfile is available in the repository. I've forgotten to include it in the binary releases, I corrected this for thev4.1.1.About your example:
The GPU RAM buffer must be paired with a CPU RAM buffer. Also, another buffer needs to be created for each output file to store the
staggerSizereordered plots.
As you want to plot indirectmode, thestaggerSizedoesn't have so much impact. It just needs to evenly divide the GRAM to free the graphic card in time to generate the nonces in parallel.
So let's say 8GB GRAM and 2x2GB RAM, for a total of 14GB RAM if you count the paired buffers.
8GB = 32768 plots
2GB = 8192 plots
7.9TB = 33046528 plotsThe
devices.txtfile should contain:<PLATFORM> <DEVICE> 32768 <LOCAL_WORK_SIZE> <HASHES_NUMBER>With:
PLATFORM/DEVICE: The platform/device couple of your GTX1090Ti, as provided by thelistPlatformsandlistDevicescommands, or by using thesetupcommand.LOCAL_WORK_SIZE: A GTX1080Ti posseses 3584 computing units. You can try 2048 for this parameter. If it is rejected by the card, divide by two, and so on (1024, 512, 256).HASHES_NUMBER:4096. If your screens blinks or you experience display driver crashes, use a small number, like4.
The command line will be:
./gpuPlotGenerator generate direct <DRIVE1>:/<ADDRESS>_0_33046528_8192 <DRIVE2>:/<ADDRESS>_33046528_33046528_8192With:
ADDRESS: The numerical value of your Burst address.
As discussed previously, depending on your disks, it may be better to plot on SSDs or to more disks at the same time to enhance the overall throughput.
-
@cryo said in GPU plot generator v4.1.1 (Win/Linux):
The
README.mdfile is available in the [repository].
About your example: ...Cyro - thanks for the link, and your detailed response /example ~ Will give it a shot later today. Your efforts much appreciated. /B.M'Nugs.
-
@BeholdMiNuggets Sorry, I forgot the fact that the GPU buffer will be partially filled the whole time, thus the disks won't be able to write in parallel. It would be best for you to have GRAM=staggerSize.
Thus : 4GB GRAM, 2*4GB RAM, for a total of 12GB RAM if you count the paired buffers.
Just change theglobalWorkSizeto16384and thestaggerSizeto16384.
-
@cryo said in GPU plot generator v4.1.1 (Win/Linux):
... the GPU buffer will be partially filled the whole time, thus the disks won't be able to write in parallel. It would be best for you to have GRAM=staggerSize.
Thus : 4GB GRAM, 2*4GB RAM, for a total of 12GB RAM if you count the paired buffers.
Just change theglobalWorkSizeto16384and thestaggerSizeto16384.Tks.
So, you only need ~2Gb of System /CPU Ram - allocated (per GPU)?
-
@BeholdMiNuggets No, each GPU needs 4GB (x1 in this example), and each plots file needs 4GB too (x2 in this example), for a total of 12GB RAM.
-
@cryo said in GPU plot generator v4.1.1 (Win/Linux):
...
7.9TB = 33046528 plotsSadly, most "8Tb" HDDs only sport about 7.27 /Tb* of useable capacity! Which comes to ~ 30,493,248 Nonces (with a small degree of head-room).
The code GitHub repository (readme) reference states: "Tweaks: When using multiple devices, make sure they have nearly the same performance." Does this mean that 2x GPUs can be used (in combination), to speed up the process? For example, for 2x GTX-1080Ti/1090 GPUs (under Windows), the plot [devices.txt] file might read:
2 0 16384 4096 2048
2 1 16384 4096 2048And the resulting Command Line (administrator) might look like this:
/gpuPlotGenerator generate direct
P:/plots/userburstid_200000000_30493248_16384
Q:/plots/userburstid_300000000_30493248_16384Does that make sense?
Thanks.
-
@BeholdMiNuggets Yes, that's the spirit. But the processing power of your card is far quicker than your IO throughput in direct mode. The bottleneck part is the plots writing and your GPU is already waiting most of the time. So adding another one won't help.
In buffer mode that would help because the writing operation is quick, and the plot generation becomes the bottleneck part. But the resulting files won't be optimized.
-
@cryo said in GPU plot generator v4.1.1 (Win/Linux):
Yes, that's the spirit. But the processing power of your card is far quicker than your IO throughput in direct mode. The bottleneck part is the plots writing and your GPU is already waiting most of the time. So adding another one won't help. In buffer mode that would help because the writing operation is quick, and the plot generation becomes the bottleneck part. But the resulting files won't be optimized.
Tried running the GPU Plot Generator - Two HHDs, one GPU.
[ERROR] Unable to extend output file: 112Have checked the two HDDs. The first has the (new) plot name-file in place, but the second does not. Cannot see any syntax or /\ errors etc in the Command Line, parameters. And do not see this error listed in the GitHub Repository /ReadMe text. Tried removing the second HDD plot, but receiving the same [112] error shown.
Any suggestions?
Thanks.GPU plot generator v4.1.1
Author: Cryo
Bitcoin: 138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
Burst: BURST-YA29-QCEW-QXC3-BKXDLLoading platforms...
Loading devices...
Loading devices configurations...
Initializing generation devices...
[0] Device: GeForce GTX 1080 Ti (OpenCL 1.2 CUDA)
[0] Device memory: 4GB 0MB
[0] CPU memory: 4GB 0MB
Initializing generation contexts...[ERROR] Unable to extend output file: 112
-
This post is deleted!
-
@BeholdMiNuggets Error 112 is
ERROR_DISK_FULL. Sounds like you doesn't have enough space on one of your disks.
-
I downloaded last ver 4.1.1. When I start gpuplotter I saw generating nonces but stuck 0% while HDD 100% working on writing. Is it normal at the beginning?
-
@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 launchBut 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_RESOURCESis 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 (globalWorkSizeandlocalWorkSize). 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
globalWorkSizecan evenly divide yourlocalWorkSize. - Try with lower
localWorkSizevalues. If you run thelistDevicescommand on your GPU platform it'll output some hints from the card (like themaxComputeUnitsandmaxWorkGroupSizesoft 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
setupcommand, my actual strategy is:- for
globalWorkSize, to take the minimum value betweenglobalMemorySize / PLOT_SIZEandmaxMemoryAllocationSize / 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.
- Make sure your
-
@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.

