Large Scale Burst Mining Operation



  • @luxe said in Large Scale Burst Mining Operation:

    @botan The Seagate Archive 8TB drive is like made for Burst mining, SMR is perfect in this case. As you only write once. Also the other technical specifications fit with the needs of burst mining.

    Yes SMR seems perfect! But sequential write speed on (Win/ntfs) is horrible! I`ve tried many different ways, in the enclosure with USB3, out of the Box on an SATA3 Port.... what it comes down to is that write speed always drops significantly after the first few GB of writing!

    I'm currently trying to plot 4pcs 5TB Seagate Drives in parallel with gpuplotter and I`m going crazy!! Write speed is something like 150MB/s at start and then it drops to 6-8MB/s. It took 23h to do a 588GB Plotfile on each of these Drives in parallel!

    I`ve been searchin all day if there is a better solution or filesystem to write large files to SMR. There are Linux filesystems which at least support the physical restrictions you have on SMR Drives. But if they are faster I don't know. If I feel adventurous enough I'll trie!

    If somebody has another suggestion you are very welcome!

    p.s. No, RAID 0 does not really help!-(
    p.p.s. Yes, gpuplotter in direct mode


  • admin

    @nixxda I plotted some 8TB on win/ntfs, you are right it is dropping but not that low for me, i always got more than 80MB as far as i can remember. Using 'buffer' mode of gpuPlotter not 'direct'! (Not sure how direct is implemented, but for my understanding it has to create/move/delete data on creating plot ... so thats the weakness of SMR, best for write once and after that only read ... from what i heard.)
    If you need 'direct' maybe plot to another fast drive (maybe ssd) and copy it after plotting ... but, if you want to do it that way, you can also plot in 'buffer' mode and not copy, but copy via optimizer. And you get the same optimized plot like in direct mode.



  • @nixxda You have a driver error for your USB3.0 I have seen this before. Also make sure you use GPT for the partition type too over 2TB. The transfer speed can dip down normally too for larger files. If you are using Direct mode this may be part of the problem. You can use Buffer mode and write from memory and it may help speed up the process.

    Some chipsets on mainboards have a firmware problem and it may take a BIOS update to get it sorted out. If you are familiar with this process it might be a simple solution.

    Oh wait SMR may be a different beast. Use the above if it helps any. You could also just take it out of the enclosure to write to it on a SATA cable, then reinsert it into the enclosure to read from it.



  • thanks for the answers! And I did all of them!
    Yes direct mode seems to be an bad Idea. Buffer and writing in parallel works perfect. I'm currently doing two Drives in parallel with 12GB RAM on each and I get about 150MB/s write speed for each "chunk" on both. Which is very nice!
    But optimizing is going to be a B....! Cant remember what the optimizer does. Is it also writing the "layout" first and then filling it? (or whatever it does!-)

    @CryptoNick USB3 controller on my rig seems to work fine. But I got these drives very cheap! like half...! so first I thought that they probably put the worst USB3 controller ever in these boxes! But i have not confirmed that with all the new "enlightenments" I had lately.
    Right now I have three of them connected to SATA and I get 150 to 165ish MB/s write speed and one I have in an USB3 Dock. From these one I get up to 189MB/s! when the first two Drives are done I'll try to confirm my "crappy Seagate USB3 controller in a Box" theory!

    btw. copying from one these Drives to another is not affected by this slowdown!



  • @nixxda Also you can try using the Janror CPU Plotter with the /async option: the output will be an unoptimized plot, but the nonces/minute could be higher...



  • @Dario's-wallet CPU has to do constant mining!-)


  • admin

    @nixxda Check to understand optimize: https://forums.burst-team.us/topic/288/plots-101/4
    If you optimize after plotting, the target drive will just be written to, while the data get collected from source drive with a lot of drive seeks.



  • @luxe just writing the whole drive sequentially would be perfect. I'll read up on that.......



  • @nixxda Good to hear that! If it doesn't slow down with large files then yeah it may be the drive. The SMR drives are only meant for backups but all Plots should write sequentially. I just don't know how the SMR tracks work. The main thing would be to make sure the drive is completely empty and that you don't write 2 or more plots to one drive. Just fill it once! What happens is the data needs to get reorganized sequentially. There will be 20TB versions of these too since it uses the same head.

    I also wonder if Sector Size may help too? 64K for large files not sure on this one.

    I just saw other posts of people having a fast start and then the data goes to 30mbps in Linux too. It is most likely a re-org of data that the controller is confused about writing. Since it is Write Once it should not write and rewrite.



  • a few days (plots) later....

    It all worked out!

    @CryptoNick in short: http://searchstorage.techtarget.com/definition/shingled-magnetic-recording-SMR
    formating with 64k cluster size seems to slow them down. I guess the controller does not like that. The 4096 Bytes Standard works fine.

    what worked best for me is:
    1.Plotting in buffer mode to an SMR Disk
    2.optimizing from one to another
    or
    1.Plotting in direct mode to an PMR Disk and

    1. just moving the whole stuff to the SMR Disk

    but I guess you already knew that, didn't you!-)

    Read speed is not as good as an WD Red but very close!



  • @nixxda Excellent! Thanks for the confirmation. Yep that is what i thought. PlotOptimizer will also optimize as it copies so very good option even if you want to use Direct mode to a standard drive and then Optimize over to SMR.



  • What about the Samsung PM1633a 16TB SSD drives? Okay they're not yet out, but could be a game changer. Have 60 of those rigged up and you have 960 TB in one of those pods.



  • @Baron Sounds like a expensive piece of Hardware?! Maybe around $10,000?!?!



  • @luxe
    I'm no expert, but maybe those with the resources should consider other industry solutions (such as broadcast). There's a limit to what can be done with even the most powerful "enthusiast" systems. Fortunately, HHDs use a lot less juice than GPUs.

    Like the "Storinator", mentioned by others.
    http://www.45drives.com/products/cluster/

    Or, some simpler setups ~ Rack-mount-9U 50-Bay HHD Storage Center Chasis.
    http://www.rackmountnet.com/images/products/rm91250/rm91250.pdf
    0_1493063449169_50-HHD-Solution.jpeg


  • admin

    @BeholdMiNuggets Well, that picture looks awesome ... but will there ever be a ROI ... big price difference from e.g. custom USB3 setup compared to 'professional' server hardware ... also the requirements of burst mining may be different to normal storage solutions ... all drives get accessed at same time on start next round. Wouldn't say that e.g. Storinator could not handle that, but is is maybe not optimized for that case. However everyone has to make own decisions ...



  • @luxe @BeholdMiNuggets I saw a 'cheap' four bay NAS storage solution the other day for $500. I don't understand why anyone would pay more for a glorified hard drive enclosure when you could just build a whole PC for the same price.


Log in to reply
 

Looks like your connection to Burst - Efficient HDD Mining was lost, please wait while we try to reconnect.