Plotting Very Slow - 5TB Seagate Drive



  • 0_1494858577416_upload-8611087a-4aab-4f33-bc93-1c2896281d54



  • I am now plotting with my pc on my SSD drive, writing takes just few seconds to complete. I am doing it in chunks of 100 GB and I have available like 500 GB only for the plotting space, then it's just a matter to copy them to the other drives I am going to be using for mining while keep plotting.. Otherwhise with an SMR drive will take forever to complete!



  • @vExact that's better than a PMR for sure and I have a 500GB SSD as well. I did what you did but now I don't like the tremendous amount of 100GB files (OCD). In fact, I'm now replotting all my drives from 100GB to 1 TB files. I think 1TB is the sweet spot, for me anyway.



  • I've CPU-plotted 8 SMR drives two weeks ago with 1 TiB files.
    Plot target was a PMR drive array (~6 hours/TB on 6 cores, then merge/optimize to SMR, 45 Minutes). When the SMR drives were writing, they NEVER were slower than 110 MB/s each, usually 150 MB/s.

    They're all organized in stripes (SMR: 4x 8 TB == 32 TB) and redundant Raidsets (PMR: 4+1x 4 TB == 16 TB) to not hinder data flow, but the SMR's never slowed down.

    So, it comes down to writing these SMR's strictly sequentially. That avoids the architectural speed penalty on random writes.
    Any Filesystem with frequently updated metadata areas (NTFS: $MFT — Master File Table, $Bitmap, $LogFile) is doomed here.



  • @haitch said in Plotting Very Slow - 5TB Seagate Drive:

    @rds Copying from PMR to a freshly formatted SMR, I never exceeded 10MB/s. Plotting two drives concurrently was going to be faster than plotting the PMR then copying it over. It's not a controller issue - when mining I get 400-500MB/sec throughput. I know they will mine just fine, but the plotting of them frustrates the hell out of me.

    what is the organization of these SMRs - single ?
    What filesystem ?

    I use zfs, copy-on-write it is the perfect match for SMRs.



  • @haitch Make sure disk write caching is turned on in device manager on those external drives. All of mine default to 'quick removal', which will get you deplorably slow write speeds.



  • @sevencardz ,

    I just started replotting an SMR. I decided to go back to plotting .2TB files on a 500GB SSD. I was getting 7700 nonce/min which plotted the file in 100 minutes. After the first was done and the second is plotting concurrently writing from the SSD to the SMR at 200 MB/sec.

    0_1494893711306_upload-f18f2dea-bbc8-4132-bdd3-b99a19e1ea33



  • @rds I considered using the extra 400GB of my SSD as a plot cache, but it wouldn't really be faster in my situation. It takes my system about 3 days to fill up two 8TB PMR drives with optimized plots. Then it's a little less than a day to transfer that 16TB over to two Seagate SMR drives. However, if disk write caching is OFF then I immediately notice awfully low transfer speeds of 10 - 20 MB/s. As other have stated, the SMR drives are on par with PMR drives if you limit them to large sequential writes with plenty of cache involved.

    With the GTX 1070 and the GPU plotter, I can write optimized plots to two 7200 RPM PMR drives at 25,000 nonces/minute. Two 5400 RPM PMR drives at 20,000 nonces/minute. I lose about 5,000 nonces/minute off those numbers near the end of the disks.


  • admin

    @haitch Just added 3 * 6TB SAS Drives as a RAID-0 array. It's writing as fast as the plotter can generate, hitting 250-300MB/sec. ETA for 18TB? 33 Hours. Pennywise should be over 100TB tomorrow.



  • Good to know, just saw a video on this today actually.

    No wonder my first drive took so long to plot xD will definitely be looking into alternatives.



  • plotting to a seagate wont work something is wrong with their design for this application. but you can plot to other drives and then copy over to the seagate. it reads fine it just can't be plotted on



  • @PeterSkrzyniarz

    Well I am currently mining on a 5tb seagate. So it does actually work, it's just not quite as efficient...

    And yes, the plots were written directly to the drive.



  • i am mining on seagate too and it works just fine, but i didnt want to wait 10 day to plot on it, so i plotted to my pc and then coped the plot to the seagate. only way to make it work unless, like i said, you want to plot at 10% the normal speed



  • @PeterSkrzyniarz It's not the design of the application. It's the Write speed of the Seagate drive.
    Seagates are extremely cheap. This is because the drive is SMR.
    SMR is quite bad AFAIK. The Read speed is incredible (165~200 MB/s). The Write speed is hell (5~25 MB/s). Which is why plotting takes forever. But when mining, it has to Read the plot files. So mining will be smooth.

    Plotting will be hell-like.
    Mining will be great.

    I suggest just plotting on another HDD that is not SMR and put the plot file on the SMR drive.



  • Write speed only sucks on SMR drives if you are doing random writes due to how the data is shingled on top of other data. Large sequential writes are not a problem and you can get well over 100 MB/s with disk write caching on. When creating an optimized plot, the algorithm first maps out the plot file, then goes back and fills it in with nonces which equates to a ton of random writes. If you plot to a PMR drive first and then copy over, then you end up with just a few large sequential writes to the SMR drive which avoids the architectural bottleneck.



  • @p0int_scale
    This is so true
    I'm currently on day 5 of plotting an 8TB SMR and only 58% right now
    I have been going back and forth, using xplotter, between 8 cores and 1 core due to the need of my laptop during work hours
    But I've found that even at 8 cores, the 10Knonces/min goes fast, but the HDD writing scoops is the hold up.
    Somewhere between 2-3cores and the the nonces/min finishes around the same time as the HDD writing scoops



  • @mrgoldy Just use like 6 cores if you need your laptop all the time. 2 cores to spare for multitasking, the rest for plotting.



  • @p0int_scale
    Thanks for the 6 core suggestion, it made me think about why I haven't been able to work while running 6 cores and actually just found that reducing my mem to 3G has helped immensely!
    -sn 800000001 -n 29722128 -t 6 -path H:\Burst\plots -mem 3G

    how important is this mem setting? should I just change it to 1G?



  • @mrgoldy Depends on how much RAM you have.



  • @p0int_scale right, I have 8G, but setting this to 3G seems to have little impact to nonces/min or writing scoops.
    what is the purpose of the mem setting? because reducing it seems to be more beneficial to running 6 cores and not affecting my performance.


Log in to reply
 

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