SSD Raid 0 optimal stripe sizes (for Crucial M4 128mb) .. anyone?

Discussion in 'Storage & Backup' started by SyKRyD, Sep 29, 2011.

  1. SyKRyD

    SyKRyD Member

    Joined:
    Feb 13, 2009
    Messages:
    193
    my two crucials (m4 128gb) have landed in my hot little hands.

    i was hoping to raid them but want to know what is best stripe size to use? there seems to be varying opinions around that state between 16kb and 64kb. has anyone here benched on different sizes?

    also, i wouldn't mind benching a single ssd to have a comparison for later. any suggestions on benchmarking tools? i've found..

    - pcmark vantage
    - atto
    - as ssd
    - hdtune
    - crystal disk

    which are the better ones to use?
     
  2. rainwulf

    rainwulf Member

    Joined:
    Jan 20, 2002
    Messages:
    4,275
    Location:
    bris.qld.aus
    Doesnt really matter, you wont find much percentage difference between the sizes of raid stripe, as striping was more of a solution to a problem posed by spinning platters, and moving heads.

    Depending on your raid controller you may not even get a choice, but most of them go for 64 or 128k.
     
  3. rowan194

    rowan194 Member

    Joined:
    Jan 5, 2009
    Messages:
    2,046
    Wouldn't a stripe size that matches the flash block size be the best fit, to reduce the number of read-erase-write cycles?
     
  4. sub.mesa

    sub.mesa Member

    Joined:
    Jun 23, 2010
    Messages:
    271
    Location:
    Europe
    That's just nonesense, for several reasons:

    1) SSDs use striping or interleaving themselves. Each channel is about 25MB/s and it only achieves higher performance by interleaving multiple channels. Most SSDs use 8 to 10 channels, which pretty much works like RAID0 does in terms of performance gains. That's also the reason you see 4K qd=1 performance sticks to ~25MB/s while multiqueue performance can be about 10 times as high. The same restrictions apply to RAID0.

    2) SSDs due to low access time has the most benefit of striping/interleaving. This is because stripe overflows do not have such a diminishing effect on performance. A too low stripesize or misalignment issue will not affect performance that badly as mechanical storage would. Mechanical storage is seek-capped, while NAND storage is transfer-capped.

    3) Striping used to have very little gains for mechanical storage because in the early days, three problems prevented random access performance scaling with RAID0: a) misaligned partitions common on XP and earlier windows; b) too low stripesize and dirty optimizations such as transferring full stripe blocks even if a fraction of the stripe was requested; c) too low read-ahead optimizations in the filesystem, providing not enough queue depth; d) limited bandwidth due to the PCI controllers not providing dedicated bandwidth for each disk. In modern age, striping is more logical than the early days of storage.

    Answer to the OP: 64KiB is probably a safe bet, though in some cases it would make sense to consider 16KiB or 32KiB as that would speed up smaller request sizes as well, at the cost of extra overhead and extra fragmentation. Some argue 128KiB being the erase block size is a better stripesize, causing less performance degradation.

    Due to the loss of TRIM when using RAID0 on Windows platforms, you may consider overprovisioning to reduce the performance degradation over time. A healthy 20-30% overprovisioning is recommended. This is done by underpartitioning your RAID array, and requires brand new SSDs. If you've written to the SSD before, this trick may not work until you perform a secure erase procedure on the SSD(s).
     
  5. OP
    OP
    SyKRyD

    SyKRyD Member

    Joined:
    Feb 13, 2009
    Messages:
    193
    That's a very in depth response. Thanks for taking the time to write it.

    It sounds as if it may be worthwhile benching different stripe sizes and posting the results here.

    Perhaps I should install the os on a separate hdd first and set up the ssds as secondary drives to bench?

    Edit:
    This looks promising...
    http://www.overclock.net/ssd/1121692-crucial-m4-raid-0-guide.html
     
    Last edited: Sep 30, 2011
  6. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    45,072
    Location:
    Brisbane
    I don't see the point in tweaking a system for synthetic benchmark results.

    Tweak it instead for whatever real-world task you are doing.
     
  7. toopy28

    toopy28 Member

    Joined:
    Dec 30, 2002
    Messages:
    926
    Location:
    Gammanville

    If your using Intel controllers you still have TRIM support
     
  8. mtma

    mtma Member

    Joined:
    Aug 12, 2009
    Messages:
    5,906
    Just FYI these Crucial M4 drives can really get bad without TRIM (anandtech did tests on this) because their internal controllers are very conservative at self garbage collection.

    So this may not be the best venture if you're using it for tasks that would cause the slowdown problems to occur.
     
  9. OP
    OP
    SyKRyD

    SyKRyD Member

    Joined:
    Feb 13, 2009
    Messages:
    193
    how do i know what to tweak without using some sort of benchmark?

    are you suggesting testing each configuration for real-world tasks? that could take months. i don't see the point of doing that.


    ..link?

    what firmware were they using?
     
  10. sub.mesa

    sub.mesa Member

    Joined:
    Jun 23, 2010
    Messages:
    271
    Location:
    Europe
    No, that's a common misconception. If you use Windows platform and you have two or more SSDs in a RAID-configuration, then you DO NOT have TRIM support.

    The confusion is to be blamed on Intel as well, which touted TRIM support in their Intel drivers when "RAID mode" is activated. Many people thought this meant that they could RAID0 their SSDs and still gain TRIM, however, this is not true.

    Previously, if you had a RAID0 of two HDDs, that meant setting the Intel controller to RAID mode in your system BIOS. That also meant you could NOT use the standard Microsoft AHCI driver for any SSD connected to the Intel controller. So if you have HDD RAID0 + a single SSD connected to Intel controller, the SSD would NOT have TRIM support, even though it was not part of any RAID array. This was because you had to use the Intel drivers and the Intel drivers did not support TRIM at all.

    This limitation has been gone since the Intel 9.6 RST drivers, so now you can still have TRIM enabled on a single SSD if your controller is set in RAID mode. So you can combine RAID0 HDD array with a single SSD without losing TRIM support on the SSD. What you CAN NOT DO is put two or more SSDs in RAID0 and still gain TRIM support. This is not a limitation of the Intel drivers, but of the Microsoft Windows operating system.

    After Intel, it didn't took long for AMD to implement the same level of support. But there simply is no way to have TRIM support on Windows platform currently, because Windows has an outdated storage backend where RAID is considered to be a SCSI disk. With TRIM being an ATA command, it simply cannot be sent to a SCSI controller. Thus, Windows has a design limitation where RAID is considered to be SCSI and SCSI does not support TRIM. That simply means, RAID = NO TRIM. But if your controller is in RAID mode and your SSD is not part of any RAID array, that single SSD can still be connected as AHCI/ATA disk instead of RAID/SCSI. The recent Intel/AMD drivers did exactly that, which made TRIM possible on such configurations.

    Hope this clears up any confusion.
     
  11. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    45,072
    Location:
    Brisbane
    How about using the actual application that matters the most to you? Do you need a thousand synthetic benchmarks to show you you're getting a few KB/s more out of your array? It all sounds like technical masturbation to me.

    Exactly how many tasks are you talking about here? Or are you just getting all excited about your Steam games loading 3 seconds faster?

    What do actually you do with your machine in the real world? That will answer your question as to how to test your hardware.
     
  12. OP
    OP
    SyKRyD

    SyKRyD Member

    Joined:
    Feb 13, 2009
    Messages:
    193
    that sounds, uh, messy

    using the machine mainly to run vm images for development - dc, web server, database server. basically, trying to simulate a multi-tier environment. any suggestions? or are you just going to sit there and be mr negative-pants?

    understand where you're coming from. maybe squeezing an extra 1% performance doesn't matter at the end of the day. but it's a free extra 1% if you can jump on a forum and ask someone who's done it and has some actual advice.


    @sub.mesa - do you design ssds for a living? :)
     
  13. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    45,072
    Location:
    Brisbane
    Now we're getting somewhere!

    I'm going to go out on a limb and guess that you're using VMWare ESXi with VMFS, and have disk images inside files. In that case, you're going to kill your I/O performance anyway, but I digress...

    What's going to be your limiting factor is the DB. Directory servers, web servers, etc are going to have bugger all disk I/O. The database is the one doing all the hard work, and causing all of the problems for your disk. You can literally disregard the other stuff, as it's most stressful I/O will be bootup, and tweaking your disk stripes will gain you all of a few seconds at boot, which is a pointless tweak.

    What are your DB read/write patterns going to look like? If you're going to do majority read, I'd be going with larger stripe sizes - 64K to 128K. If you're going to be doing majority writes, I'd be shrinking them down.

    Either way, it's pretty simple for you to test. Knock up a DB VM with 32KB stripes, and run yourself a couple of torture scripts that mirror your real-world workloads, and wallclock it. When done, copy the VM image off somewhere, rebuild your array with 64KB (and later 128KB) stripes, and re-test. You should knock all of this over in about an hour or two max, and have your answer.

    I do this sort of stuff day in, day out for some very big companies. Piece of cake to and get some real-world results from.

    Your synthetic benchmarks aren't going to help. All they'll do is show you how well your synthetic benchmarks run. Run real world apps with real world code (for you, that means just the DB app of choice), and be done with it. You'll have a real answer that will give you real results better than any bullshit you read on a forum or blog, and you know they're valid for your use case.
     
  14. mtma

    mtma Member

    Joined:
    Aug 12, 2009
    Messages:
    5,906
    http://www.anandtech.com/show/4253/the-crucial-m4-micron-c400-ssd-review/2

    They didn't mention which firmware they tested on so I would say that it would have been one of the earlier firmwares.

    One thing that they did note is that between the Crucial C300 and M4, the effect was the same, and micron have already said that the C400 (used in the M4) and C300 are fundamentally the same controller, the C400 only has minor updates to it.

    Not sure if retesting has been done on FW 0009, but I haven't read anything to suggest that Micron have made 0009 to improve on this issue.
     
  15. issa2006

    issa2006 Member

    Joined:
    Feb 4, 2006
    Messages:
    3,215
    Location:
    AUSTRALIA (ADL)
    max it out(unlike hdds) 128k+
     
  16. OP
    OP
    SyKRyD

    SyKRyD Member

    Joined:
    Feb 13, 2009
    Messages:
    193
    thanks for the responses guys (especially for your recommendation @elvis)

    i haven't had an opportunity to get onto this other than upgrade firmwares and install windows. will get into it soon.
     
  17. rainwulf

    rainwulf Member

    Joined:
    Jan 20, 2002
    Messages:
    4,275
    Location:
    bris.qld.aus
    I stand by my opinion that you wont notice an ounce of difference between the difference in stripe sizes apart from artificial benchmarks.
     
  18. OP
    OP
    SyKRyD

    SyKRyD Member

    Joined:
    Feb 13, 2009
    Messages:
    193
    i look forward to proving you right :thumbup:
     

Share This Page

Advertisement: