GPU plot generator v4.1.1 (Win/Linux)
-
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?
-
@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...
-
@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.



