Large Scale Burst Mining Operation


  • admin

    @jervis Guess that's not the same, i want to use your solution + using the VGA power supplies. My experience is, that attaching more than ~12 to 15 drives the 'normal' way does not work stable.



  • I wish I could afford to do this.

    I have heard of people running a good voltage regulator off of the 12V line, the problem is that the 5v line rarely has enough current for that many drives.

    Would you be running linux?

    Windows has a maximum 26 drive letter limit, virtual machines maybe?

    Or RAID? that could be really fast and combine multiple drives to one letter.

    a bunch of small cheap proxy miners?
    I am a fan of blagos software with the proxy

    Just some food for thought! sounds like a fun project



  • @Colby3316 OH! In addition, does mining with the GPU + HDD produce more Burst than mining with only the CPU + HDD?

    I know it makes it faster, but I still don't understand the role of the CPU/GPU entirely outside of the inital plotting.



  • @Colby3316 No it doesn't



  • @Gadrah_ Can you or someone explain exactly what deadlines and scoops are? Someone really ought to make a small educational platform for people, lol.


  • admin

    @Colby3316 I Suggest you read 'How it works' in OP of Bitcointalk thread. There is also a flow charts below that, to understand in more detail. Also here in the forum are FAQs answered.

    @crutsy Excactly ... I currently use some quite old PC Power Supply with not much Watt but a big 5V part, nearly double as high as modern 'Gaming' PC Power-Supplies. It can provide 37A on 5V, while most modern/new only reach 15A-25A.



  • @Colby3316 said in Large Scale Burst Mining Operation:

    @Colby3316 OH! In addition, does mining with the GPU + HDD produce more Burst than mining with only the CPU + HDD?

    I know it makes it faster, but I still don't understand the role of the CPU/GPU entirely outside of the inital plotting.

    The overall speed of your response will effect how many Burst you Mine. Yes if you can scan all your plots in 30 Seconds you will be Fine. However..... the faster you submit you deadline on the short blocks the more your reward will be as some people who given time might have found a better deadlines will not have submitted them. :-)

    Rich

    Rich



  • @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?!?!


Log in to reply
 

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