 Show Posts
|
|
Pages: [1] 2 3
|
Hi everyone, I pre-ordered an Excalibur 5 and, of course, haven't got any product in the end. I contacted the curator a while back (thanks to nam-shub for the contact details) and, at first, they answered me. I provided all the required papers to them and they said they registered my claim, but since 3 weeks I don't have any more answers from them. I tried to contact them by email and by phone over and over again without any success. By phone I'm always redirected to their voicemail, but I can't understand a single word as I don't speak their language. Does anyone here have any news of them? I'm really desperate about all of this. Don't tell me the curator is a scam too... Thanks in advance. Which Email address did you use?? I tried secretariaat@sprekseladvocaten.nl (got answers at first but nothing since 2-3 weeks), info@sprekseladvocaten.nl and the online contact form on their website. |
|
|
|
Hi everyone, I pre-ordered an Excalibur 5 and, of course, haven't got any product in the end. I contacted the curator a while back (thanks to nam-shub for the contact details) and, at first, they answered me. I provided all the required papers to them and they said they registered my claim, but since 3 weeks I don't have any more answers from them. I tried to contact them by email and by phone over and over again without any success. By phone I'm always redirected to their voicemail, but I can't understand a single word as I don't speak their language. Does anyone here have any news of them? I'm really desperate about all of this. Don't tell me the curator is a scam too... Thanks in advance. |
|
|
|
Think the best thing needed,imo, is a GUI plotter and miner for noobs and wide distribution, so anyone can mine with their hds easily and quickly. 3 clicks, 1.plot 2.mine 3.profit Right side of this is a good feel for gui too.  +1000 I'm working on that part  I'm currently working on a distributed web-based plotter/miner (with a nodejs backend). I'll keep you in touch. |
|
|
|
On a side note, cryo's newest GPU plotter creates optimized plots if using the direct writing option. Don't freak out if the progress stays at 0% for a while because it will start updating the progress once the plot file size reaches the output size. Cryo will probably fix this in a future update once he bases the initial progress meter on the size of the file before basing the meter on the number of scoops plotted *hint hint to cryo.
I browsed the source code, but did not find where the file is preallocated. Wouldn't it introduce a huge fragmentation? Could anyone compare with a file plotted sequentially? For ext4 filesystem: e4defrag -c filename shows real & ideal fragmentation values, xfs_io -f -c "fiemap -v" filename shows where exactly blocks are located. Btw, from my experiments with dcct's plotter, calling fallocate or posix_allocate before writing to file sequentially produces worse results than simply writing to file given that the disk was initially empty... Moving the file to another disk and back fixes the fragmentation. ps. I'm using Ubuntu 14 LTS. For those who don't know, new versions of the GPU plotter are announced in this thread: https://burstforum.com/index.php?threads/gpu-plot-generator.45/ Updates are pretty frequent so check it out if you haven't  Hi everyone, Sorry for not anouncing the new releases of the new GPU plot generator versions here, but I belived that no more technical posts were allowed here. Anyway, I will notify you from time to time. @majere Yes you're right, there is no pre-allocation of the output files for now. For the staggered files it doesn't make so much sense (especially with higher ones), also it prevents resuming. As for the direct writing strategy, it's still a beta feature and need some more tests. I'll check the file fragmentation to make sure it's ok. Please don't use the direct writing strategy for production purpose for now as there may be an unsolved issue (see mmmaybe's posts at burstforum.com). Regards. |
|
|
|
Awesome!
Fooling around a bit with it, 2 x 780 Ti went over 60k n/m and I'm fairly certain they could have gone higher if it weren't for the I/O limitation.
The highest stagger I could reach was 16383 which is just below 4GB RAM which is the maximum it could allocate even though I have 16 GB. And that is completely regardless of VRAM amount.
@bathrobehero Wow, impressive performances. Regarding the <staggerSize> it can be because you have a 32bits platform. What command line do you use? What error do you have when trying to allocate more than 4GB? Which OS do you have? Sorry for the late answer: I have win7 x64 with 16 GB memory and it doesn't give me any errors, just quits: CPU memory: 404MB
----
Initializing OpenCL devices...
GPU[0] memory: 1GB 0MB
----
Creating CPU stagger buffer...
Creating CPU plots buffer...
Opening output file...
0.00% (0/4518000 nonces), nan nonces/minutes, ETA: 0s...
m:\>pause
Press any key to continue . . .
This was with 18000 staggersize (gpuplotgenerator.exe generate "m:\plots2" x 32528001 4505600 18000) so the interesting thing is that it says CPU memory is 404 MB which should be 4500 MB. Edit: Is there a miner which doesn't consume ~850MB of memory for every 1 TB plots? GPU plot generator v3.0.0 This version comes with a multi-GPU support and greatly enhance the global memory consumption (on both CPU and GPU side). I hope that it will fix the bad performances of NVidia cards (I need some feedback on that point). This version also add a [verify] command to verify a plotted file against a reference file (a C-plotted file for example). Official link: https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-6#post-1925Getting the following error message some times: Running 5 devices, within their memory limits. Any ideas...? @mmmaybe @bathrobehero I've reproduced the two bugs you reported and I've corrected them. I will release a 3.0.1 this evening. Thank you for your feedback |
|
|
|
Many thanks for explanation. I am generating plot with these parameters: Machine is 4 x R9 280X (but only 2 are generating, no need for more because of HDD speed) + 8Gb ram. devices.txt is : 0 0 8192 128 8192 0 1 8192 128 8192 command line parameters are: gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101000000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101025000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101050000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101075000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101100000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101125000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101150000000 2048000 8192 gpuplotgenerator.exe generate "D:\plots" 30xxxxxxxxxxxxxxx778 10101175000000 2048000 8192 It is 4Tb total per disk (range change for every hdd). GpuPlotGenerator says: ------------------------- GPU plot generator v3.0.0 ------------------------- Author: Cryo Bitcoin: 138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD Burst: BURST-YA29-QCEW-QXC3-BKXDL ---- Checking input parameters... ---- Path: D:\plots Nonces: 10101050000000 to 10101052047999 (500GB 0MB) CPU memory: 2GB 0MB ---- Initializing OpenCL devices... GPU[0] memory: 2GB 0MB GPU[1] memory: 2GB 0MB ---- Creating CPU stagger buffer... Creating CPU plots buffer... Opening output file... ------------------------------------------------------------------------------------------------------------------------------------ Dedicated mining machine will be 8 or 16 Gb ram, 8 hdd (32Tb total). Is there something I should change before plotting all drives, considering equipment and ram size? That would be it, final step before mining, after this I should only wait to be done and start mining. Will not bother more It all seems good to me. Maybe you can use a higher stagger size like 16384 as you have 8GB of memory for plotting. It'll reduce disk stress later for the mining process. |
|
|
|
@bipben I didnt understand something with the new gpuplogegenerator 3.0.0: Since it has devices.txt file where you should put your devices config, what should we put on our config bath file , accound ID for example. What should be the command line order ? EDIT: " - globalWorkSize: The amount of nonces to process at the same time (determine the required amount of GPU memory)." - is this the stagger size? @go6ooo1212 Here is the usage of the [generate] command (obtained with a ./gpuPlotGenerator help generate): Usage: ./gpuPlotGenerator generate <path> <address> <startNonce> <noncesNumber> <staggerSize> Generate plots and write them to the specified directory. Parameters: - path: Path to the plots directory (must exists). - address: Burst numerical address. - startNonce: First nonce of the plot generation. - noncesNumber: Number of nonces to generate (must be a multiple of <staggerSize>). - staggerSize: Stagger size. The [devices.txt] file only contains information about your hardware. The program use it to generate plots files with the provided parameters, as for the C-plotter. |
|
|
|
Hello Bipben and miner friends,
Sorry for taking You time on this topic, but I dare to ask You for advice.
I am in mining for long time, but with GPUs, now, with HDD PoC mining, I am missing something.
I just got 8 pcs of 4Tb HDD WD40PURX sata drives.
And have motherboard for it, A88X chipset.
All drives are going to same mobo. I also got 16Gb of ram (2x8Gb).
And some low end CPU (A4-3700).
It is dedicated PoC miner machine.
I also have 280X graphic cards ans I 3770k CPU on other comp (where I work).
What I am missing, or do not understand is this:
1) Plotting HDDs. Should I use wplotgenerator to plot hdd? Or Gpuplotgenerator? Is result same?
Can You please tell me parametars for gpu plot for configuration on my machine with R9 graphic. Cpu ram size is actually CPU cache size (on 3770k cpu it is 8Mb)? And I have 8Gb RAM DDR3. Radeon is with 3072Mb ram. Platform 0 device 0. I know rule of plotting and done it with earlier version of Gpuplotminer on 1tb spare drive. But it is different.
2) Is 16Gb ok for mining machine, or is also 8Gb ok. On that machine will be 8x4Tb drives? And what miner to use for optimal results?
Thank You.
@Yanakitu Tenatako 1) As you seem to have a great amount of GPU power, it could be a good idea to use the GPU plotter. They both produce the same output files. The only thing that varies is the device used for plot generation. When I speak about CPU RAM size, I mean the available amount of main memory, not CPU cache size. 2) About mining, you most likely should use one of the C ones, as they are faster and more stable in memory. With higher staggerSize values at plot generation, you will reduce the disk stress when mining. @Alex Coventry I've looked at your code. I think that the N CPU buffers are really bottleneck as it will require a lot of RAM to plot N disks at the same time, or will force the user to reduce its <staggerSize> value, thus increasing disk-stress when mining. Maybe a limted amount of rotating buffers would be enough and more RAM efficient. Maybe a stagger-less version (staggerSize = fileSize / PLOT_SIZE) of the plotter could solve this RAM issue (need some tests as it will increase IO operations).
Anyhow I will work on that part with the already implemented multi-GPU support, begining with the ideas behind your version.
What do you mean by "much faster"? Do you speak about a performance difference between the 3.0.0 and the 2.1.1 or between the 2.1.1 and your modded one?
Yes, there is a lot of room for improvement. I only took it as far as I needed for my purposes. You only need as many rotating buffers as it takes to max out transfer bandwidth. By much faster, I mean faster than the same code without asynchronous writes. Thanks for publishing your revision history. @fivebells I totally agree with you The only hard part is to guess at runtime which number of buffers would max out bandwidth. I think that I will make it an input parameter to be as polyvalent as possible. |
|
|
|
Awesome!
Are we able to plot with large stagger sizes in this version?
@twig123 Yes, the correlation between the staggerSize and the GPU RAM has been removed. The staggerSize only depends on the CPU RAM amount now. Would it be more beneficial for hdds to run in RAID arrays now, ie. RAID0? As for ssds, that not a very cost efficient alternative...lol.....I'll send you some burst and thank you for all the efforts, more likely the middle to end of next week.
@SpeedDemon13 Yes I agree with you, the SSD reference is not really cost effective. Moreover, plotting on a SSD and transfering the files to standard HDD later only shift the problem. However, I think that a multi-GPU multi-disks version could be a good idea. And you Cryo, very big thanks!
Version 3.0 came out great and at the moment it has everything you need to begin now to create a lot of plots without problems.
Steps for creating this version taken from the author is not a short time. Respect him for that!
I transferred to Cryo 5000 Burst. Good people, I will always support!
@ Palad1n Thanks for your support =D Thanks alot  Have done some initial testing on nvidia, and I think it's faster but foremost it can handle much larger stagger sizes. And I'm just on tiny 750ti's Donation incmming @mmmaybe Glad to hear from an NVidia user. Thanks for your support =) Awesome!
Fooling around a bit with it, 2 x 780 Ti went over 60k n/m and I'm fairly certain they could have gone higher if it weren't for the I/O limitation.
The highest stagger I could reach was 16383 which is just below 4GB RAM which is the maximum it could allocate even though I have 16 GB. And that is completely regardless of VRAM amount.
@bathrobehero Wow, impressive performances. Regarding the <staggerSize> it can be because you have a 32bits platform. What command line do you use? What error do you have when trying to allocate more than 4GB? Which OS do you have? Getting the following error message some times: Running 5 devices, within their memory limits. Any ideas...? @mmmaybe After wich step do you see this error? There is a problem in the error display here so it'll be difficult to know the real cause. I'll have to correct the displaying problem before. I'll work on it, thanks for your feedback. As the HDD is now bottleneck, there are two options: <snip>
- Write to multiple disks at the same time (I will put this on the roadmap).
I modified an earlier version of your plotter to do this. I've been using it for a couple of weeks or so, it seems to produce valid plots much faster. Only tested on linux. void CommandGenerate::help() const {
std::cerr << "Usage: ./gpuPlotGenerator generate ";
std::cerr << "<platformId> <deviceId> <staggerSize> <threadsNumber> ";
std::cerr << "<hashesNumber> <path> <address> <startNonce> <noncesNumber> ";
std::cerr << "[<path> <address> <startNonce> <noncesNumber> ...]" << std::endl;
std::cerr << " - platformId: Id of the OpenCL platform to use (see [list] command)." << std::endl;
std::cerr << " - deviceId: Id of the OpenCL device to use (see [list] command)." << std::endl;
std::cerr << " - staggerSize: Stagger size." << std::endl;
std::cerr << " - threadsNumber: Number of parallel threads for each work group." << std::endl;
std::cerr << " - hashesNumber: Number of hashes to compute for each step2 kernel calls." << std::endl;
std::cerr << " - path: Path to the plots directory." << std::endl;
std::cerr << " - address: Burst numerical address." << std::endl;
std::cerr << " - startNonce: First nonce of the plot generation." << std::endl;
std::cerr << " - noncesNumber: Number of nonces to generate." << std::endl;
std::cerr << "With multiple [<path> <address> <startNonce> <noncesNumber>] arguments " << std::endl;
std::cerr << "GPU calculation iterates through a stagger for each job and the results are " << std::endl;
std::cerr << "saved asynchronously. This is intended to be used for plotting multiple " << std::endl;
std::cerr << "mechanical drives simultaneously in order to max out GPU bandwidth." << std::endl;
}
@Alex Coventry I've looked at your code. I think that the N CPU buffers are really bottleneck as it will require a lot of RAM to plot N disks at the same time, or will force the user to reduce its <staggerSize> value, thus increasing disk-stress when mining. Maybe a limted amount of rotating buffers would be enough and more RAM efficient. Maybe a stagger-less version (staggerSize = fileSize / PLOT_SIZE) of the plotter could solve this RAM issue (need some tests as it will increase IO operations). Anyhow I will work on that part with the already implemented multi-GPU support, begining with the ideas behind your version. What do you mean by "much faster"? Do you speak about a performance difference between the 3.0.0 and the 2.1.1 or between the 2.1.1 and your modded one? |
|
|
|
GPU plot generator v3.0.0 This version comes with a multi-GPU support and greatly enhance the global memory consumption (on both CPU and GPU side). I hope that it will fix the bad performances of NVidia cards (I need some feedback on that point). This version also add a [verify] command to verify a plotted file against a reference file (a C-plotted file for example). A big thank you to Palad1n for his help on the qualification phase of this version. With this new version, we hit the maximum bandwidth of a standard mechanical HDD (around 20k nonces/minutes ~= 83MB/s). We made a test with a SSD disk too, with only one 280x we touch the 33k nonces/minutes. As the HDD is now bottleneck, there are two options: - Use faster hardware (SSD). It is up to you to test it Feel free to share your experience on the forum (hardware configuration, nonces/minutes obtained). - Write to multiple disks at the same time (I will put this on the roadmap). Changelog: - Multi-GPU support. - [devices.txt] configuration file added. - verify command added. - list command split in two (listPlatforms and listDevices). - More details added in listDevices command. - Correlation between <staggerSize> and <globalWorkSize> removed. - OpenCL error codes displayed for better debugging. - Details added in usages. - README updated and improved. - CHANGELOG file added. - CREDITS file added. - LICENSE file added. Please read the README provided with both the binaries and the sources. As this version introduce new concepts, please read it carefully, especially the [SETUP] part. Here are the binaries and the source code : - Windows x86: https://mega.co.nz/#!vMUWjCZA!IXkIyupOek6t7bOu0qlrYlxvuzVfRS-N4T8sfJ08u-E - Windows x64: https://mega.co.nz/#!bEEmiAyK!IeEzk_TrVpLvFpbWGLvkl5tppmgGXDXI3xBbrh2CfGM - Linux x86: https://mega.co.nz/#!ud8HnboC!wVU9EwfYWU4mnc67QP1Pienqo4JRm_QJuaE3AJPw5J0 - Linux x64: https://mega.co.nz/ #!bZExEDaQ!gygiHlkCVLNNbgIFuruQUnV3yrFz8m5pISXsikHPM_g (remove the space before #, link detected as suspicious...) - Sources: https://mega.co.nz/#!fBUEEJKD!e5KnEEVIGN0FK3aaHriS6YstfiDNO6lhRTGen8Dh8a8 If you like this software, support me Official link: https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-6#post-1925 |
|
|
|
Does the gpuplotgen2.1.0... work properly with 14.*** drivers, because the ver. 2.0.1 generates plots that give huge value deadlines too...
Someone made the test and reported to me that the 14.4 driver is not an issue anymore with the new kernel (2.1.x). |
|
|
|
GPU plot generator v2.1.0 Changelog: - Enhanced kernel. Thanks to "burstcoin" for his great work on that part. Windows x86 binaries: https://mega.co.nz/#!aVNXzIhB!Obq7E_Nob0v6SHn8KheIiTlNwT6G9yN4cEmBXadUQZc Sources: https://mega.co.nz/#!yU8GQAqa!7YG8G8Z1UqudnYIhj79JY-Y8uVpVMiPV4v0lFHYEWEs I made some modifications in the kernel too. Please check that my modifications don't lower the performances (it shouldn't, but let's be cautious). Also, as this is a brand new kernel, the AMD 14.4 issue may be corrected as a side effect. I would really apreciate a feedback on that point. rename shabal.cl to shabal2.cl Erf, sorry for that. I was in the middle of testing it and forgot to change the #include. ------ GPU plot generator v2.1.1 Changelog: - Shabal include corrected. Windows x86 binaries: https://mega.co.nz/#!HMEUHKAL!WQuhun7OlODiV1VvxJv5GHjPo9MsccfyuubQgJEAUYU Sources: https://mega.co.nz/#!7VExxQ7Z!EoUPH_XzXEFQXnQ41XQ6fiHjMfnXpR9HdxUztmPaeH8 |
|
|
|
GPU plot generator v2.1.0 Changelog: - Enhanced kernel. Thanks to "burstcoin" for his great work on that part. Windows x86 binaries: https://mega.co.nz/#!aVNXzIhB!Obq7E_Nob0v6SHn8KheIiTlNwT6G9yN4cEmBXadUQZc Sources: https://mega.co.nz/#!yU8GQAqa!7YG8G8Z1UqudnYIhj79JY-Y8uVpVMiPV4v0lFHYEWEs I made some modifications in the kernel too. Please check that my modifications don't lower the performances (it shouldn't, but let's be cautious). Also, as this is a brand new kernel, the AMD 14.4 issue may be corrected as a side effect. I would really apreciate a feedback on that point. Great work! I've sent you some BURST Thank you for your support |
|
|
|
GPU plot generator v2.1.0 Changelog: - Enhanced kernel. Thanks to "burstcoin" for his great work on that part. Windows x86 binaries: https://mega.co.nz/#!yIsSFByA!A50zN-7X7hLo5d3r5W9R_fwmhca3QC50_G3vG2CFJPM Sources: https://mega.co.nz/#!HUsgQJIC!K-xNcnn3zfFZb9UHX7WokRRzEbLPmZOeAZWoIVArOwQ I made some modifications in the kernel too. Please check that my modifications don't lower the performances (it shouldn't, but let's be cautious). Also, as this is a brand new kernel, the AMD 14.4 issue may be corrected as a side effect. I would really apreciate a feedback on that point. I assume this is still mainly for AMD right? last time I checked even a 750Ti was slower than my CPU. I think it's the same like with scrypt mining in the beginning. Using the OpenCL miner, the performance was just way to low for the power consumption. Without a proper CUDA implementation, nVidia is out of the plotting game I guess ^^ Give it a try, but yes the design hasn't been reviewed yet. The v3.0.0 will be your best chance to make it works with NVidia cards as I will expose two new parameters to tune things up more precisely. It should be more compliant with NVidia cards. If not, I will port the GPU plot generator to Cuda to make everyone happy ^^' |
|
|
|
GPU plot generator v2.1.0 Changelog: - Enhanced kernel. Thanks to "burstcoin" for his great work on that part. Windows x86 binaries: https://mega.co.nz/#!aVNXzIhB!Obq7E_Nob0v6SHn8KheIiTlNwT6G9yN4cEmBXadUQZc Sources: https://mega.co.nz/#!yU8GQAqa!7YG8G8Z1UqudnYIhj79JY-Y8uVpVMiPV4v0lFHYEWEs I made some modifications in the kernel too. Please check that my modifications don't lower the performances (it shouldn't, but let's be cautious). Also, as this is a brand new kernel, the AMD 14.4 issue may be corrected as a side effect. I would really apreciate a feedback on that point. |
|
|
|
One per plot. So, you'd have to start multiple plotters to use multiple GPUs
Thanks. So does this mean that basically the only way to use multiple GPUs in one rig efficiently (= simultaneously) is to build plots on multiple HDDs at the same time with 1 gpu per 1 HDD? Although I suppose it's possible to divide 1 HDD into several partitions and fill each partition of the same disk simultaneously, assigning 1 gpu per partition? If that is possible, then we'll run into maximum disk write speed limit pretty quickly, cause ordinary HDDs won't like it when huge chunks of data are written to different partitions at the same time.. The multi-GPU support is in the roadmap, be patient |
|
|
|
just tested this and confirming same results. what's the solution? how i can check my plots at corrupt?
I noticed the plots generated by GPU plotter with 14.6 drivers produced extremely huge deadlines (13-14 digits) when mining. It's very hard to mine anything with such deadlines. "Warning: to the AMD owners, the 14.4 catalyst driver cause a major bug. The generated files are corrupted. I will investigate on this problem. In the meantime, I recommend you to switch back your driver to the 13.12 version" quote from bipben So should we delete the plots generated with 14.4 , its true that the geadlines are large , but it getting accepted ahares. I'm confused... Good news: it seems that the corruption doesn't occurs systematically. Maybe it's an isolated problem. But if you're in this configuration, it's better to check your GPU generated plots. As posted before, here is a mean to verify your plots: Just generate another plot file with the CPU plotter with the same exact values used on the GPU plotter for the <address>, <startNonce> and <staggerSize> parameters but with a <noncesNumber>=1 (will be expanded to <staggerSize>). Once done, check that the first bytes of the CPU generated file matches the ones from the GPU generated ones. If yes, you can keep your GPU generated file, else the file is corrupted and must be deleted. Sorry for the inconvenience. I'm investigating this problem and will correct it asap. |
|
|
|
head -c `stat -c%s <n-path>` o-path | diff - <n-path> should work. Where o-path is the path to the old output, and n-path is the path to the new. Seriously though, I have no idea what you are requesting. If you're still running a plot on the GPU, could you then try running one of the CPU plotters with the same parameters (address, nonce range, stagger size) for a few minutes and check that they match in the part created by the CPU plotter? Say the directory containing the GPU plotter output (the "plots" directory") is <GPU-path>, and the path to the CPU output is <CPU-path>. Could you then run this command in a terminal and report back its output? If they match, there should be no output. head -c `stat -c%s <GPU-path>` <CPU-path> | diff - <CPU-path> Gotcha. I'll take a look into testing this tomorrow. Once the GPU plot I have going currently finishes. I didn't forget... Plot file just finished. I ran your test with some smaller plot files: cd /media/twig/Burst_Coin_21/~~Linux~~/Plot_Generator
./plot 11111222223333344444 0 2000 1000 4 cd /media/twig/Burst_Coin_21/~~Linux~~/GPU_Plotter_v2.0.0/bin
./gpuPlotGenerator.exe generate 0 0 /media/twig/Burst_Coin_21/test/GPU 11111222223333344444 0 2000 1000 64 1024 head -c `stat -c%s /media/twig/Burst_Coin_21/test/GPU/11111222223333344444_0_2000_1000` /media/twig/Burst_Coin_21/test/CPU/11111222223333344444_0_2000_1000 | diff - /media/twig/Burst_Coin_21/test/CPU/11111222223333344444_0_2000_1000 After issuing the last command, it just returns to a prompt... no additional output. I assume this means the plot files match. (also I am mining and finding shares from the GPU plot as well)
Warning: to the AMD owners, the 14.4 catalyst driver cause a major bug. The generated files are corrupted. I will investigate on this problem. In the meantime, I recommend you to switch back your driver to the 13.12 version.
My plots appear to be fine (on Linux) generated with the 14.4 catalyst driver, as compared to the same plot generated with the CPU I'll test out v2.0.1 and see if there are any changes. [/quote] That's a good news, even if I will have to investigate more on this part ^^ For those who already generated some files with the plotter, to make sure the generation is successful, do the following : Generate a file with the same parameters as your full plot file (address + offset + stagger) but with a noncesNumber of 1. The generated file has to match with the first bytes of your full file. |
|
|
|
That's a really good "getting started" guide. Thank you for your work No problem, I'm glad to help! I you have any input let me know and I will update it. Also, it seems that calculation of nonces/minute may be off... https://bitcointalk.org/index.php?topic=731923.msg8771161#msg8771161It shows me calculating at 121,230 nonces/minute... but actual file growth is more along the lines of only 12,123.0 nonces/minute. (Maybe this is from the message I got when compiling?) ...It might also be nice to have a "ETA" for completion time. But not really needed. Maybe the CLOCKS_PER_SEC value doesn't match the actual clock() values on your platform (function that I use to retrieve the time). I will use the time() function instead. Here is the new version: GPU plot generator v2.0.1 Warning: to the AMD owners, the 14.4 catalyst driver cause a major bug. The generated files are corrupted. I will investigate on this problem. In the meantime, I recommend you to switch back your driver to the 13.12 version.Changelog: - Nonces display corrected (XX/YY nonces). - Using time() function rather than clock() in nonces/minute computation. - Nonces/minutes repeated at the end of the generation process to keep a trace of it after execution. - ETA and elapsed time added. Windows x86 binaries: https://mega.co.nz/#!TVEVjQ5L!Uyd2HuPTZSP9eARwjiChjd1P6BMWHQtYT0SGGHLrnuI Sources: https://mega.co.nz/#!2RUwHAyC!IOxfTZk9PsRdPS7Z3a76MAT4vT3ygvp--r_dVQ5GaD4 So, this is just a cosmetic update? I don't know if it's just me, but my system would use 3GB total in the first 6 hours. Then later on, it would use double at 6~6.5GB and degradation of speed also. Is it possible there is a memory leak in the plotter? I'm running AMD 13.9 driver with 2.9.1 APP SDK. Yes this is a minor update. I'm working on a major update right now: I'm trying to remove the final scoops re-ordering from the kernel to run it in pure CPU mode. This will remove the x2 GPU RAM overhead. I'm also trying to decorrelate the staggerSize and the necessary RAM amount (note that this will increase I/O operations when writting nonces to disk, but I'll give it a try. If it works well, we would be able to go to staggerSize=totalNoncesNumber). I'm also reducing the cost of the step2 kernel to enhance nonces/minute. With all of those improvements, it will be easier to make the multi-gpu aware version of the plotter. |
|
|
|
|
