@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.
Posts made by cryo
-
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
-
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@BeholdMiNuggets
For yourdevice.txtfile, you can try :2 0 8192 1024 8192
In depth:globalWorkSize:8192= 2GB GPU RAMlocalWorkSize:1024= 1024 CUDA coreshashesNumber:8192if your card is tied to your display, else4.
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.
-
RE: What's the deal with these NOT confirmed deadlines?posted in Mining & Plotting
@sevencardz Sounds like it's not only affecting the last scoop. I'll run some tests on my side to try to reproduce this.
-
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@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
-
RE: What's the deal with these NOT confirmed deadlines?posted in Mining & Plotting
@sevencardz Can you test around the nonce reported in the miner output (
320348789from your example output):./gpuPlotGenerator generate buffer C:/13668371040637458609_320348689_200_200 ./gpuPlotGenerator verify A:/13668371040637458609_318883840_1525760_1525760 C:/13668371040637458609_320348689_200_200 -
RE: What's the deal with these NOT confirmed deadlines?posted in Mining & Plotting
@sevencardz It may be related to this issue.
The GPU plot generator comes with a
verifycommand to verify plots files based on freshly computed nonces.
As you have a large mining power, the fact you experience it from time to time could help to debug this.
Can you try to verify one file reported by the miner? If it's the same problem as the linked issue, the missing/faultly scoop should be located at the end of the file. So a call like the following should suffice:# We generate a test file located at the end of the faultly file ./gpuPlotGenerator generate buffer Z:/13668371040637458609_100699660_800_800 # We verify it against the actual file ./gpuPlotGenerator verify O:/13668371040637458609_99174400_1525760_1525760 Z:/13668371040637458609_100699660_800_800If it's confirmed, I'll track down this bug and help you restore the missing scoops (maybe by adding a
repaircommand). -
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@BeholdMiNuggets Error 112 is
ERROR_DISK_FULL. Sounds like you doesn't have enough space on one of your disks. -
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@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. -
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@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.
-
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@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. -
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@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.
-
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
@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 -
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
I changed the build system, so the only files required are the .exe and the [kernel] folder.
If it doesn't launch due to missing DLLs, install the Microsoft C++ 2015 redistribuables. -
RE: xplotter and gpu plot generator - different filesizeposted in Mining & Plotting
@horego Is the bug persistent across launches or is it random? Also, thanks for your tests, it'll help a lot to find the cause.
@Blago Same question for you as you experienced it.I'll do my best to correct this issue.
-
RE: GpuPlotGenerator, direct , Plotting Stuck at .04-0.11%posted in Mining & Plotting
I updated the GPU plot generator (v4.1.1). It now comes with file pre-allocation when launched with admin rights, which greatly speed things up in terms of IO operations when using direct writing strategy.
-
RE: GPU plotting stuckposted in Mining & Plotting
I updated the GPU plot generator (v4.1.1). It now comes with file pre-allocation when launched with admin rights, which greatly speed things up in terms of IO operations for direct writing strategy.
-
RE: GPU plot generator v4.1.1 (Win/Linux)posted in Plotter
I updated the GPU plot generator (v4.1.1). It now comes with file pre-allocation when launched with admin rights, which greatly speed things up in terms of IO operations.
I'm searching for Linux and MacOS owners to test it. I'll provide pre-built binaries soon for these OSes to ease things up.
-
RE: GPU Plotting (Direct mode) - Why does it suck so bad?posted in Mining & Plotting
I updated the GPU plot generator (v4.1.1) with fast pre-allocation feature (same as XPlotter, with cross OS port, though not tested for now as I lack beta testers).
The huge lag was due to the system that was zero-filling the whole file step by step for the first plot writing.
-
RE: Is GPU plotting useful?posted in Mining & Plotting
I updated the GPU plot generator (v4.1.1). It now comes with file pre-allocation when launched with admin rights, which greatly speed things up in terms of IO operations.