• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Stripping Size?

Warrior

[H]F Junkie
2FA
Joined
Oct 13, 2004
Messages
14,002
ok this is a friend of mine that needs a few answers that cant find a email to use to register.. :rolleyes:

I just had a quick question for everyone here. I just purchased 2x 250GB western digital SATA II drives (WD2500KS operating at 150MB/s SATA I speed) and have them set up in RAID 0. What would be the most appropriate stripe size for the RAID array? I am currently copying my system drive which has 40GB worth of files on it and it has been copying for about an hour now and is only half done and I am a bit concerned that this is a little slow for SATA RAID. The PC I am using these on is used for things such as playback of movies and MP3's, gaming (alot), large file downloads, ripping and burning CD's, things such as compressing and uncompressing of RAR files, and maybe some DVD compression later down the road. I know that the stripping size is different based on the types of activites and sizes of files used, but of all these things on one PC what would be the best option? My SATA controller allows stripping sizes between 16K and 512K and I currently have it set to 32K. Thanks a bunch all.

tho i have no idea what hes saying... try to comprehend and make your best judgment.. thanks !
 
<nevermind>

yeah, Stripping is best done by girls with endless legs and a nice Butt. I could care less about the amount of boobies...
 
Striping. Stripping is what girls named Candy and Crystal do.

RAID 0 has been shown to not increase desktop performance very significantly. That being said, even if it did, I assume you're reading from a non-RAID hard drive, so you'd be limited by that read speed.

-Nate
 
you forgot about Helmut, Chad and Bruce

we are after all an equal opportunity forum :p


http://faq.storagereview.com/tiki-index.php?page=StripeSize

e-dawg said:
Most people have taken to using chunk size, stripe size, and cluster size interchangably as ways to describe the threshold above which the RAID controller will split a file into component "stripes" spanning 2 or more drives. Stripe size is "more correct", so I will use that term. Cluster size should be used in the context of filesystems, not striping parameters.

Smaller stripe sizes improve STR of smaller files at the expense of service times (similar to "access time") for 2 or more randomly positioned/accessed files. The larger the stripe size, the greater the probability that any two files will be on opposite drives in their unstriped form, thus facilitating concurrent access to them. This improves multitasking ability and service times of multiple random I/O requests (even at lower I/O queue depths) at the expense of small file average STR.

While some RAID manuals recommend small stripe sizes for a database server (I am assuming they would be hammered with high I/O queue depths, thus making the request seem more sequential in nature) and large stripe sizes for A/V applications, I would think that one should avoid small stripe sizes for most database applications due to the random I/O nature of typical db requests. Furthermore, I would think that STR dependent applications such as video editing should not use large stripe sizes because you want all your files striped for maximum STR. Indeed, video editing uses and generates large file sizes, so larger stripe sizes are appropriate, but certainly you do not want the stripe size to exceed the size of your smallest video files. Better to be safe and set the stripe size lower.

IMO, default should be 64 KB stripe size for most people. Small stripe sizes improve STR benchmarks, but are not indicative of real world performance. I would also go so far as to say that, for most non-STR dependent, non-sequential I/O applications (i.e., most desktop computing tasks except for A/V editing), "bigger is better", and that 128 KB would be preferable to 16-32 KB. With large stripe sizes, you're going to get STR benchmark results that don't seem much better than single drive results, but you are going to get better real world performance than smaller stripe sizes that give excellent STR benchmark results.

Please see this page from the Reference section for more details.

One of Hard Disk Info's RAID tests shows how performance can vary with stripe size. It seems that 128 KB would be the "jack of all trades" stripe size from their tests.

see link for embedded hyperlinks

STR = Sustained Transfer Rate
 
You can try running a benchmark like HDtach to see if you're getting the expected results - seek times a little higher than a single drive, burst speeds at the bus speed or thereabouts, and STRs about one and a half times a single drive, possibly better or worse depending on configuration.

And as mentioned, raid 0 is mostly pointless for gaming in a desktop (as opposed to a multi-user server) role. You might consider breaking the array and using the disks seperately, or even running raid 1 (with the cost of half as much storage, but faster read speeds).

 
So I made a typo by entering 2 P's instead of 1. So sue me. Thanks to the people who overlooked this and gave a real world response BTW. I just reformatted my RAID array and rebuilt it with a 128K stripe size and a 64K cluster size. Only when I set the bios to boot from SATA and tried starting up it said: "A disk read error has occured. Press Ctrl+Alt+Delete to restart". The strange part is I boot up with my old drive and the array is accessable and I can read the files perfectly fine. Maybe just a glitch. Or maybe something it doesn't like about the cluster size. Gonna try again...
 
Back
Top