GPU plot generator v4.1.1 (Win/Linux)
-
@cryo said in GPU plot generator v4.1.1 (Win/Linux):
@BeholdMiNuggets
For yourdevice.txtfile, you can enter...Thanks, I'll try your suggested parameters tomorrow.
hashesNumber:8192if your card is tied to your display, else4.
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
hashesNumbershould be renamed asintensity. Performances are almost the same between8192and4. 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.53Config 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 4096It 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 000GPU TDP jumping from 5% to 41%
Temperature of GPU chip rised to 67CTried 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.53Config 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.
-
-
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 4096I 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 @pause15257600 for a ~4TB drive
102400 to use 25GB of RAM (using ~6,25GB RAM reduces my nonces/minute by 25% )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.Edit: Update result of using two drives instead of one
@setlocal @cd /d %~dp0 gpuPlotGenerator.exe generate direct F:/temp/12760599261465029898_7300000000_7628800_51200 E:/temp/12760599261465029898_7310000000_7628800_51200 @pauseSo write speed was the bottleneck on using one drive, with two drives i could increase speed by ~25%.
-
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
directmode 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 thelibOpenCL.sofrom 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 thedirectmode.
-
@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.1Recommended 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 laggingWhat 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 of4096won'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
4for 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
globalWorkSizeshould be near themaxAllocationSize. For thelocalWorkSize, 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!
-
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!
-
@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.
-
@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?




