Pegasus2 R4 vs R6 speed

Discussion in 'Mac Accessories' started by chfilm, Jan 21, 2014.

  1. chfilm macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #1
    Hi,

    I currently own a Pegasus R6 12TB and a Drobo 5D.

    I'm getting a nMP with TB2 and would like to harness that power for r3d editing.
    Therefore I'm trying to sell my drobo.

    I'm considering though sellung the Pegasus as well and just unifying all on a 18 TB Pegasus2 R6 maybe. Or just get a Pegasus2 R4 instead of the Drobo.

    A promise spokesman told me the R4 could reach speeds around 800mb/s read.
    That would be fine for me, but on another thread I read it only does around 550 mb/s wich is similar to my R6 and does not require Tb2.

    I couldn't find any real benchmarks. Does anybody already have experience with it?
     
  2. mintakax macrumors regular

    Joined:
    Dec 19, 2013
  3. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #3
    I can only find a review of the pegasus2 R8 on cnet? And that one is weird cause they only got super slow results!
     
  4. spaz8, Jan 23, 2014
    Last edited: Jan 23, 2014

    spaz8 macrumors 6502

    Joined:
    Mar 3, 2007
    #4
    The CNET review was bad. Don't know what they are doing, didn't sync the drives or something, probably left the default 128k block size. The speeds he got were slow/mediocre P1 R4 speeds and he was testing a P2 R6!

    Here is a better one http://www.larryjordan.biz/product-review-promise-pegasus2-raid/

    The more drives the faster the I/0 .. R4 < R6 < R8 ..

    And of course the speed of the drives you get is a big factor. R6 and R8 will come with the drives Promise gives you (Toshiba?)

    The block size you configure with is a big factor.. default is 128k.. people seem to recommend 512K, promise test with 1024k blocks.

    One article said to multiply the number of drives by 120 mb/s for a RAID 5 setup and subtract the last drive, RAID 0 will be faster still. I think thats conservative, I think you could go 150, the ES.3's will do 175 mb/s sustained.

    So i think conservatively in RAID 5 ;
    R4 = 360 mb/s .. 525 mb/s in Pegasus 1 review of R4 .. so based on other p1 to p2 jumps 651 mb/s ?
    R6 = 600 mb/s .. macworld got 851 mb/s
    R8 = 840 mb/s .. review got 870 mb/s. .. promise says 1030 mb/s..

    In RAID 0 you could break 1000 mb/s on the R6 or R8. Promise says 1300 mb/s for the R8.

    I'm going to look at the hybrid/fusion drives just for kicks. IN theory they could go in the diskless R4.
     
  5. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #5
    Hm, I want to reformat my P1R6 since it seems to be a bit too slow.

    I have it set to 128kb strip size though that seems to be too small since I primarily use it for video editing. (I also have my aperture library on it though)

    Would you recommend 512 kb ?
     
  6. spaz8 macrumors 6502

    Joined:
    Mar 3, 2007
    #6
    There are other threads on here with promise in the title ... that discuss the strip size.. but I think going to 256 or 512 you would see a performance gain. 512 is probably a better choice for A/V work. I'm not an expert.. my P2 R4 arrives tomorrow but I plan to use a 512 strip size based on what I have read.
    Basically the larger the files you work with the larger the strip size. Like I said, Promise itself seems to market with stats based on 1024 strip size.
     
  7. joema2 macrumors 65816

    joema2

    Joined:
    Sep 3, 2013
    #7
    As mentioned on the other threads, this depends on the benchmark.

    http://forums.macrumors.com/showthread.php?t=1695994

    http://forums.macrumors.com/showpost.php?p=18576138&postcount=1

    My 4x2TB Ver. 1 R4 in RAID 5 gives 858 MB/sec read, 698 MB/sec write in QuickBench 4.0 (large). However the BlackMagic numbers are a little lower, and other benchmarks are all over the map. That's using a 512k stripe size.

    There are many parameters which can cause variable results -- even on the same hardware: test file size, I/O pattern, number of threads, number of overlapped reads/writes, whether the I/O request to the filesystem uses the "force read" and "no cache" flags, whether this is honored, amount, type, and behavior of device-level caching, etc.

    A benchmark is just a proxy for your workflow, and it may not accurately represent that. E.g, no matter how high the benchmark numbers, if your main activities use a different access pattern and are I/O limited, the high benchmark is of little comfort.

    For still images and video, I'd suggest a 512K stripe size. I ran brief tests at 128k, 256k and 512k and couldn't see a huge difference but 512k is the best overall match for the I/O pattern I observed in a blend of Lightroom, FCP X, and large folder copies using Finder.
     
  8. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #8
    thx, I'm reformatting the R6 now with 512 stripe size. I'll report back ob how anything might have changed! I just had 128.. I guess that was too low for my video work!
     
  9. joema2 macrumors 65816

    joema2

    Joined:
    Sep 3, 2013
    #9
    Note to anyone syncing or re-syncing the RAID set on a P4 or P6: for fastest results you need to set Background Synchronization Rate to 'High'. This is in the Promise Utility->Background Activities->Settings.

    I think you may also need to delete and recreate the Disk Array in the utility, not just the Logical Drive. I saw cases where it seemed the faster sync rate wouldn't 'take' unless the disk array was recreated.

    Of course if you're already well into a sync, it's better to just let it finish.

    The sync time is not linear but follows a curve (see my previous thread on that). You can probably measure a few data points, e.g, elapsed time vs % sync, plot those on a curve and compare to the curves I posted. That would reveal the actual remaining time.
     
  10. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #10
    I set the rate to high right after the beginning of the sync process, but obviously I should have done the by you suggested trick of resetting the array... Cause it didn't seem to have any effect on the speed. It will take at least 24hours.
     
  11. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #11
    Actually I get read and write speeds that are between 50-100 mb/s faster now after I changed the stripe size to 512! Nice!
     
  12. krell100 macrumors member

    Joined:
    Jul 7, 2007
    Location:
    Melbourne, Australia
    #12
    I've got an R4 coming soon so this thread has been very helpful as I'm a bit of a RAID novice. I'm thinking of going RAID10 as that sounds like a good combination of speed with security. Anyone use RAID10? The stripe size at 512 is noted, thanks guys!
     
  13. spaz8 macrumors 6502

    Joined:
    Mar 3, 2007
    #13
    I wish people would post their read/write performance and the HDD models they are using.

    My R4 diskless is here, my nMP is still "processing", I have no HDD's in the thing yet. I'm hoping promise updates their compatibility list. I was all set to buy 4 seagate ES.3 drives till I saw the high seagate fail rates. Now toshiba looks good :) but no-one but seagate has 128 MB cache drives at the moment. And part of me dosent want to go off the promise compatibility list, but that list sucks, its tiny and, barely any enterprise drives, and half of whats there is no longer being manufactured.

    I know I want to get enterprise drives since they are meant for RAID setups both in performance and durability. But I'd like to see how the barracuda's and WD's are doing performance wise.
     
  14. mikepj macrumors regular

    Joined:
    Nov 2, 2004
    #14
    Just want to note, that while changing the stripe size to 512KB will often improve sequential benchmark speed with larger blocks of data, it doesn't mean the disk is going to be faster for your everyday tasks.

    In a 4 disk RAID 5 with a 512KB stripe, you are reading/writing 2MB of data every time you change even a single bit in a 1KB file. That's 4 times more disk I/O than you would have with a 128KB stripe.

    Sure, if you are doing video work or something else where most of your file accessing is to large files, a larger stripe is the better option for you. But if you are an average user who accesses big and small files fairly evenly, a 128KB stripe is a good balance. That's why it's the default stripe size on the non diskless Pegasus models.
     
  15. spaz8 macrumors 6502

    Joined:
    Mar 3, 2007
    #15
    Good to know. Thanks for that. With the 4x more disk I/O.. naive question, but what is the downside of that ? slower performance of small files? more wear and tare on the disks?
     
  16. mikepj macrumors regular

    Joined:
    Nov 2, 2004
    #16
    Both. If you write a bunch of small files (copying a big directory full of text files for example), the disks will have to work a lot harder to keep up, which slows things down. And you are putting more wear and tear on the drives in the process.

    Going back to the copying a directory example, for every time you write a file, the following happens:

    • Your Mac sends the file to the Pegasus controller to write it to the volume.
    • Pegasus controller reads the slice of the drive where the file will reside.
    • Pegasus updates the contents of the slice and writes it back to the drive.
    • Pegasus reads the equivalent slice from the other disks in the RAID 5 (all except for the parity slice).
    • Pegasus recalculates the parity.
    • Pegasus writes the parity slice to the disk.

    So in a 4 disk RAID 5, you are reading 3 slices, and writing 2, all as a result of creating a 2KB file on the disk. With a 512KB slice, that's 2.5MB of I/O. With a 128KB slice, it's a more moderate 640KB of I/O.

    This all assumes no cache. I'm sure the Pegasus is smart enough to group small file writes together and do the above process once for several at the same time. But then the specifics would depend on how well their cache handling works and whether or not the files are stored in the same area of the volume.
     
  17. mythos macrumors member

    Joined:
    Jul 16, 2002
    Location:
    Los Angeles
    #17
    Good info here mikepj, appreciated.

    I've configured my R2 so that I have two pair of 2TB as two 4TB RAiD0 (with a4TB 2Big for TimeMachine backup).

    I have the stripes at 1MB for audio and video and have started moving files onto the RAID's. Am I wise to use 1MB in tis instance or should I go with 512k ?

    Thanks.
     
  18. mikepj macrumors regular

    Joined:
    Nov 2, 2004
    #18
    It's a tough call. Audio and video files are certainly big enough to use the bigger slice sizes, and a RAID 0 doesn't suffer as big of a performance hit with bigger slice sizes the same way a RAID 5 does. 512KB might give you a bit more performance on day-to-day tasks, but the difference might not be big enough to go through re-creating the logical volume.

    Try copying a few larger folders to it and see how it performs. If it's good enough, stick with what you have.
     
  19. mythos macrumors member

    Joined:
    Jul 16, 2002
    Location:
    Los Angeles
    #19
    Thanks.

    Seems to be working fine so I'll stick with what I have.
     
  20. joema2 macrumors 65816

    joema2

    Joined:
    Sep 3, 2013
    #20
    This is a tricky area. It depends on what the average I/O size is for your most common I/O-bound task. IOW if a task is slow but it's CPU bound, then I/O optimization is of little use. If a task is I/O bound but infrequently encountered, no need to optimize for that rare case.

    Note it's the I/O size that counts, not the file size.

    Ideally what you'd like is an I/O size histogram of your most common I/O bound task, to show what the distribution of I/O size is. I don't recollect if any commonly-available monitor tools show that.

    However you can very crudely approximate I/O size by running Activity Monitor and dividing data read/sec by read in/sec, likewise for writes. When I do that while running a Lightroom Import, it's 256-512KB. While running a FCP X export, its about 120KB.

    You can also divide "data read" by "reads in", which is cumulative number since last reboot.

    Those might imply a 512KB or smaller stripe size is best, but it really depends on both your software and workflow. If you're frequently moving data around, then you should optimize for the I/O size for (say) a Finder file copy.

    They key is what are the I/O characteristics of the task you most often wait on? Also important are the absolute I/O numbers. In the above FCP X case, the 120KB I/O size might imply a smaller stripe set is optimal, but in that case the total I/O rate was pretty low -- far below the R4's capability. IOW it was CPU limited or the process internally limited due to thread synchronization waits. Further optimizing what isn't an actual bottleneck is of no benefit.

    As a very rough approximation I tend to think 512KB may be better for video and high-res stills, but it's unclear if changing upward from 256KB or down from 1MB is sufficiently beneficial to be worthwhile.
     
  21. mythos macrumors member

    Joined:
    Jul 16, 2002
    Location:
    Los Angeles
    #21
    Well damn... seems I have work to do.. which is a shame as I'm also fighting a delivery deadline.

    Thanks joema2. Trying out 512k now.

    In other news, my BTO nMP is on the truck for deliver. Woo-hoo...
     
  22. Ifti macrumors 68000

    Joined:
    Dec 14, 2010
    Location:
    UK
    #22
    Without derailing this thread - I was wondering why you prefer the Promise system over the Drobo?
    I have the Drobo 5D at the moment, with 3x3TB drives and a 128GB mSATA card for cache etc - mainly used for video editing with FCPX. I have been considering the Promise systems since its claimed their performance is a hell of a lot better?
    Considering you have first hand experience with both systems, was just after you thoughts?

    Many thanks.
     
  23. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #23
    Hey,

    sure, good question!

    Just take a quick look at the actual speeds of both systems. As you can see, the drobo is a hell of a lot slower than the Pegasus!

    In real world, it's just impossible to playback a 1080 exr filesequence from the drobo stutterfree. Editing from the pegasus is suuuper smooth. I can even play back red files at 1/2 debayer setting in real time on my late 2012 imac!

    Lightroom and Aperture lib are both on the pegasus as well, just so much faster scrolling through the images than on drobo.

    The drobo is just hosting my itunes library and old projects and stuff. It's basically my archive. It's like a huge, expandable USB 3 disk with redundancy to me. I wish I could sell both and just get a Pegasus2 R8 for the new mac pro. But no one wants the drobo. And the pegasus is fast enough for most cases.

    Just look at the table in the speedtest. You can clearly see what the drobo will be able to playback and what not.
     

    Attached Files:

  24. mikepj macrumors regular

    Joined:
    Nov 2, 2004
  25. chfilm thread starter macrumors 65816

    chfilm

    Joined:
    Nov 15, 2012
    Location:
    Germany
    #25

Share This Page