GPU plot generator v4.1.1 (Win/Linux)



  • @haitch would it be faster to plot direct to a drive that is not SMR? then transfer or no?


  • admin

    @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...


  • admin

    @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.



  • @BeholdMiNuggets i need to play with my devices file but currently
    im using 1792 192 8192
    with a r9 280x
    when i left it earlier it was going at 13k n/min with an estimate of 17 hours on the 4tb drive

    the pc is as follows
    Asrock a88x fata1ty killer+
    amd athlon x4 845
    8gb 2133mhz

    my drives are as follows
    1x 240 gb m500 crucial ssd no plots boot drive
    2x 4tb WD my books
    1x 3tb HGST Ultrastar 7K4000 enterprise
    2x 1tb wd essentials usb 2.0 with wd green warranty is up might shell them
    1x 500gb toshiba pocket size external
    1x 500gb hitachi 2.5" drive laptop salvage
    1x 500gb WD green
    1x 250gb hgst 2.5" laptop salvage
    1x 160gb hgst 2.5" laptop salvage
    1x 1tb WD black only 400gb it has other things on it...
    i also have all my thumb drives and micro sd that were not being used on it too... totaling 352gb
    4x 16gb thumb drives
    1x 32gb pny thumb drive slow and no longer reliable
    1x 32gb san disk
    32gb g.skill micro sd class 10 (10mb/s writes)
    64gb sony micro sd class 10 (best write speeds of the 3 24-40mb/s)
    128 gb pny micro sd class 10 (might be counterfeit has a slow write speed when advertised at much faster)

    Star tech 4 controller usb 3.0 pci-e 4x



  • @Lunas said in GPU plot generator v4.1.1 (Win/Linux):

    @BeholdMiNuggets i need to play with my devices file but currently
    im using 1792 192 8192
    with a r9 280x
    when i left it earlier it was going at 13k n/min with an estimate of 17 hours on the 4tb drive

    I've had 35000n/m with a R9-280x.
    You are most probably chocking on output to disk.
    What is your i/o looking like ?



  • @cryo said in GPU plot generator v4.1.1 (Win/Linux):

    @vaxman The direct mode 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 the libOpenCL.so from 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 the direct mode.

    I'm not using direct mode, as buffer fits my environment much better.
    I have it up+running with 4x Tesla M2090, streaming 47kn/m to a stripe,
    optimizing from there to Seagate Archive SMR (185 MB/s down to 95 MB/s at max capacity). zfs is perfect for large files on SMR disks - no lag.

    devices.txt

    1 0 8192 512 8192
    1 1 8192 512 8192
    1 2 8192 512 8192
    1 3 8192 512 8192
    

    As this is the maximum I can ingest, I'll look into Radeon setup when plotting is finished.
    Didn't plan to use Nvidia/AMD combined in one job, anyway. I was looking into docker containers to have an easy setup for switching between plotting Burst and mining other coins on that box, as it hides so nicely in the racks, 6 GPU in 2 RU; Supermicro 2027-TRTH, cheap (for the build quality you get) on ebay.

    So, one of my first transactions ever (1564546818816845010) was totally worth it.
    Hope you did'nt sell the 10k Burst too soon. 😎

    People, do not forget to give something back! Send this man some Burst !



  • @vaxman Thank you for your support 🙂



  • @luxe said in 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 4096
    

    I 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
    @pause
    

    15257600 for a ~4TB drive
    102400 to use 25GB of RAM (using ~6,25GB RAM reduces my nonces/minute by 25% )

    The result:
    0_1498222271286_Unbenannt.PNG

    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
    @pause
    

    0_1498325964361_2drives.PNG

    So write speed was the bottleneck on using one drive, with two drives i could increase speed by ~25%.

    I just started using the updated plotter in direct mode, it seems rather amazing speed wise compared to those using buffer mode, at least when paired with drives that can handle the write speed as you mentioned... I will have to try writing multiple plots to multiple drives at once as your followup showed... although I think I am roughly near my peak with my 1050 ti at 23000 nonces on the Ironwolf 10TB drive, testing it will give me 230MB/s but I only get 100MB/s when plotting with my current setup, this is a fun use for unused hardware...

    0 0 1024 16 8192

    0_1498508033845_1000GB at 23535 nonces while mining.png

    I can't wait to try out plotting two files at once, is there a command line option to create files in a series rather than parallel, or is it best to just make a batch file to launch each command line in succession, not sure I want to commit to such large files in case something goes wrong, now that I think about it, maybe I want to make smaller 256GB files rather than 1TB files... paranoia has begun...

    there is no realistic performance difference as far as Burstcoin is concerned between smaller and larger plots right? as far as I have read so far a plot is a plot is a plot, since you won't get "better" deadlines due to file size, just overall volume of plots is the way to have more "lottery tickets" as you guys say...



  • @vaxman the 3tb is currently writing 51-71mb/s and plotter is going at 14k nounces the previous attempt the plotter had locked up doing nothing for 8 hours I sat here played with the settings until I got the plotter to run as fast as I think it can.
    The 3tb has 1 hour left then it will do the 4tb and lastly the 1tb
    3072 640 4096 is what I'm running atm
    4096,8192,1024,2048 all work as the first number but the rates drop to between 4000-9000 n/min especially when you run the 8192 I think much of the issue plotting on this machine stems from the ram it has if it had more ram or more vram my numbers would be better.
    For the second number 128-768 work a 280x has 2048 stream processors so technically that should work as well but nothing over 768 worked for me.
    The third number I wanted the plotter to report more responsively so I reduced it by half I read here that it doesn't effect plotting speed very much and can be set to 4 or up to 8192.

    and the 3tb is done average 14333 n/min took 10 hours was done in gpu direct mode


  • admin

    @Darkbane said in GPU plot generator v4.1.1 (Win/Linux):

    I can't wait to try out plotting two files at once, is there a command line option to create files in a series rather than parallel, or is it best to just make a batch file to launch each command line in succession, not sure I want to commit to such large files in case something goes wrong, now that I think about it, maybe I want to make smaller 256GB files rather than 1TB files... paranoia has begun...

    Batch file would be the solution, for me i had no crash at all, plotting multiple files over a week, but sure it depends on how stable you system is in general.

    there is no realistic performance difference as far as Burstcoin is concerned between smaller and larger plots right? as far as I have read so far a plot is a plot is a plot, since you won't get "better" deadlines due to file size, just overall volume of plots is the way to have more "lottery tickets" as you guys say...

    There is a performance difference, best is one big plotfile for one drive, but i would say 4-8 smaller files per drive may also be ok. But with 32x256GB on 8TB drive it will start getting slower while mining.
    For every file the drive has to re-position the read head, what may take a few ms. The idea of a optimized plotfile is, that the drive does not have to re-position head at all, with lot off small optimized files you go against that idea. But however it does not effect the deadline, just the time you may need to be able to commit it.



  • Hi guys,

    Bit of weirdness with this, maybe the latest update fixed it?

    Have an Nvidia Titan X, and using 0 1 4096 128 10 as the device settings.

    The plot being set as _3814592_64

    The first 99% will complete as fast as the drive can write, (Samsung EVO 960 NVMe M.2 1TB) but the last 1% drops down to, Kb/sec. Considering this drive can read/write at 2000/2000Mb/s just wondered what this massive drop in performance is down to at the end?

    Thankyou.



  • So downloaded the latest version, and no different, it writes a massive amount of data very quickly, then, bam, slows down writing the nonces at 4332/minute direct mode on a 2000/2000Mb drive.

    The CPU can write at 4x that, so I have no idea why the performance on this floors out so hard?



  • @XenForoSlavik having the same problem, performance drops and it's not constant @cryo



  • @HiDevin Quite, I have 2 titans now plotting at 70-80k nonces per minute in buffer mode, and the drive is laughing at the "pathetic" 300-400Mb/s write rate, yes, the drive is able to write faster than 2 graphics cards can give it data... so maybe im misunderstanding how the direct mode works, but something is quite drastically wrong when a CPU plotter can do it quicker.


  • admin

    @XenForoSlavik You're writing 3,815,592 values, in chunks of 64 values at a time, so around 59,000 blocks of scoops. When you start mining that,the miner will go seek to the first set of nonces, and read those 64, then seek to the 2nd set of nonces and read them, then seek to the 3rd set of nonces and read them ....... Disk seeks are computationally incredibly bad. Your cpu that can do billions of computations per second, is stuck waiting while the disk drive head moves, and more data can be read. Seek times are measured in milliseconds, to us that incredibly fast, to a CPU it's an eternity, and with your method of plotting, there are almost 60,000 seeks to mine a single plot.



  • @haitch At the moment I am simply trying to work out how to get the GPU writer to write out at a decent rate in direct mode. However, I can not work out why it will write out 99% of the plot at full speed, then on the last 1% it slows down to an absolute crawl.

    I updated to the latest build, and even with the pre-alocated space, it seems incapable of writing faster than 5k nonces a minute in direct mode. At first I suspected the hard drives, but after grabbing this M.2 drive to rule that out today, I can only guess theres an issue with the write out logic of the gpu writer, unless you have suggestions on other configs?

    Device settings: 0 1 4096 512 1024
    Drive size: 1,000,068,808,704 bytes


  • admin

    @XenForoSlavik If you're basically stopping plotting towards the end of your plot, you've set the number of nonces to high.

    The miner will write multiples of your stagger, up to the value of your number of nonces. But if number of nonces is not a multiple of the stagger, the plotter will round up and try to plot 101% of your hard disk.

    To calculate the correct number of nonces to use in your plot: floor((disk size in bytes / 262144) div <stagger>) * stagger