Raid controller confusion, Seeking advice

[CMetaphor]

As some know, i have a Dell Perc 6i (finally with the latest firmware installed).

I also just got 4x Crucial C300 64Gb SSDs to put in Raid-0.

Now, I find myself scratching my head on which settings to use on the Perc to get the fastest possible array. I'm also on some medication which makes me feel like i have a constant hangover (yarg, it sucks) which isn't helping me think/research.

Read ahead, Adaptive Read Ahead, No Read Ahead.
Write Back, Write Through.
Stripe size: Between 8k and 1,024k (I believe)

Lots to research, hoping someone here with more experience than me can point me at the best settings.

Thanks HwC! (Yet again)

[CMetaphor]

May have found some info here: About PERC 6 and CERC 6i Controllers: Dell PERC 6/i, PERC 6/E and <br>CERC 6/i User's Guide

For Write-Back/Write-Through (Underlined some pertient info, bolded the "conclusion"):

Write-Back and Write-Through

In Write-Through caching, the controller sends a data transfer completion signal to the host system when the disk subsystem has received all the data in a transaction.
In Write-Back caching, the controller sends a data transfer completion signal to the host when the controller cache has received all the data in a transaction. The controller then writes the cached data to the storage device in the background.
The risk of using Write-Backcache is that the cached data can be lost if there is a power failure before it is written to the storage device. This risk is mitigated by using a BBU on selected PERC 6 controllers. For information on which controllers support a BBU, see
Write-Back caching has a performance advantage over Write-Through caching.

My Perc 6i has the BBU. So looks like Write-back will be the setting ill use.


For Read-Ahead/Adaptive Read-Ahead/No Read-Ahead:

Always Read Ahead - Read-Ahead capability allows the controller to read sequentially ahead of requested data and to store the additional data in cache memory, anticipating that the data is required soon. This speeds up reads for sequential data, but there is little improvement when accessing random data.
No Read Ahead - Disables the Read-Ahead capability.Adaptive Read Ahead - When selected, the controller begins using Read-Ahead if the two most recent disk accesses occurred in sequential sectors. If the read requests are random, the controller reverts to No read ahead.

If I assume that sequential reads of the SSD array will be faster using Adaptive Read-Ahead, and that random reads will not be affected (or slowed at all) with this setting, then it looks to be the best option in my situation.


Now I just need to figure out which stripe size is best, although I've always used 64k for my 2-disk Raid 0 arrays (using regular HDDs), perhaps a different approach would be better for these SSDs?

[3.0charlie]

I did trial-and-error for the stripe size on my Raid 50 array and tested using Atto. I think 64k was the fastest.

[CMetaphor]

Originally Posted by 3.0charlie

I did trial-and-error for the stripe size on my Raid 50 array and tested using Atto. I think 64k was the fastest.

Interesting.

From what I've been reading on various other forums on the subject, the stripe size for an SSD array is dependant on three factors:

1 - OS drive vs. Non-OS drive - Smaller stripe sizes will help for OS usage, but will slow down larger file transfers on a Non-OS drive. In my case, ill be using my Raid-0 as my OS/Games drive. So perhaps smaller rather than larger would be best.

2 - The "erase block" size (which seems to be 64k for most SSDs) - This one interested me the most. It seems that no matter what amount of data is written to an SSD, 64k of space will actually be written. I.E. = if you write 8k to an SSD, 64k will actually be written. This would explain the decrease in performance in SSD Raid-0s that I've seen when using stripe sizes smaller than 64k. (Note: I don't actually know what the "erase block" size is on my C300s, but I'll try to figure it out)

3 - The number of drives in the array - Also interesting: According to some, a stripe size that is too small for an array containing many disks will also adversely affect the performance.


Here's an example chart I'll quickly make, based off some of these assumptions listed above (all 3):
Stripe size:
Number of SSDs \ OS Drive \ Non-OS Drive
1 \ 64k \ 128k
2 \ 128k \ 256k
4 \ 256k \ 512k
8 \ 512k \ 1024k

Of course I'd have to test each and every configuration to verify if the above is true, but I don't exactly have the time for that.

[CMetaphor]

I just love replying to my own threads At least the info will be here and easier for any member to find with a search function, lol.

A member at XS uses this formula for determining stripe size:
[/Quote] Stripe Size = SSD Erase Block Size x Stripe Width (aka number of disks).[/quote]

The only problem now is, how do i find the erase block size of the C300s? The crucial size doesn't have that info anywhere. Nor can I find it googling around...

Is there an SSD tool that would provide this information?

[gingerbee]

I found 64k and write back cache on was the fastest. but i only ran 3 x ssd. have fun and see what happens oh your doing that ha ha

[CMetaphor]

Originally Posted by gingerbee

I found 64k and write back cache on was the fastest. but i only ran 3 x ssd. have fun and see what happens oh your doing that ha ha

64k is the "Default" that everyone just assumes will always be the best. But has anyone ever tested different stripe sizes on a 4-disk raid-0? Thats what im interested in the most now. Its between 64k, 128k or 256k stripe sizes (at least i think it is).

I'd also appreciate more opinions on this, thanks all.

[gingerbee]

like i said i test when i was running 3 and 2 raid0 ssd's and found that 64 was the fastest but i never raided more then 3 x ssd so you could give it a shot and let us no what you find out?

[JimboToronto]

Originally Posted by CMetaphor

has anyone ever tested different stripe sizes on a 4-disk raid-0?

Yeah, back when I first put four Vertex1s in RAID-0 when they first came out.

I tried numerous partition offsets and stripe sizes and found it to work best (large and small, random and sequential transfers and IOs/sec) with a 1024KB offset and a 64KB stripe. This testing was all done on an ICH9R in WinXP.

I was not surprised when they used 1024 as default offset for the Win7 partitioning tool.

I'm pretty sure my RevoX2 has its four Sandforces on a 64KB stripe.

[gingerbee]

you better hope so cause that's another way to help kill cells if it's not. i have never looked into it offset.