You can have more than 2 in a raid 0, i believe though, that the big issues comes in syncing up your reads as you put more drives on teh array, that's where a nice fat cache would help on the controller or the drive. As one drive may complete the read before others because the head was closer to the data. for random reads over the stripe size, i'm not sure, kind of guessing, i think is where you'd lose your speed.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
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.
RAID 0 and performance
- Thread starter 64bit_is_here
- Start date
defakto said:
Why is that a problem? Windows supports scatter-gather.
Are you saying that the issue is a controller might not support scatter-gather, or that it might do so only if the total size of the request is larger than the cache (buffer, really) on the controller?
.B ekiM
The red line is my current setup, the blue line is an example the same drive by itself.
2nd drive in the list is the only one that was comparable to my drives (in single mode), even though I believe it would actually be faster than mine individually.
It is an adaptec 29320a-r with two seagate cheetah 15k u320 drives, I am plugged into regular old pci so it is limited to 160, but with only two drives it shouldn't matter.
I do video editing, transfer video from my cam to the pc via firewire, then edit and compress it. Working with a 10gb raw avi file is quite a chore on a standard ide drive, I can really see a big difference in it.
As far as my pc 'feeling' faster, it does, just like it did when I used to run a dual-cpu system, even though it didn't tend to make individual applications run faster.
I think the reason people overclock their machines, buy really expensive video cards, and occasionally run raid-0, is that they want to reduce or eliminate the bottlenecks that they encounter. Some things help, some things don't, but I am really enjoying my new disk subsystem.
The next thing on my list (after the video card obviously) is gigabit ethernet, whenever I copy files over the lan (videos of course) I max the fd100 available to me now.
2nd drive in the list is the only one that was comparable to my drives (in single mode), even though I believe it would actually be faster than mine individually.
It is an adaptec 29320a-r with two seagate cheetah 15k u320 drives, I am plugged into regular old pci so it is limited to 160, but with only two drives it shouldn't matter.
I do video editing, transfer video from my cam to the pc via firewire, then edit and compress it. Working with a 10gb raw avi file is quite a chore on a standard ide drive, I can really see a big difference in it.
As far as my pc 'feeling' faster, it does, just like it did when I used to run a dual-cpu system, even though it didn't tend to make individual applications run faster.
I think the reason people overclock their machines, buy really expensive video cards, and occasionally run raid-0, is that they want to reduce or eliminate the bottlenecks that they encounter. Some things help, some things don't, but I am really enjoying my new disk subsystem.
The next thing on my list (after the video card obviously) is gigabit ethernet, whenever I copy files over the lan (videos of course) I max the fd100 available to me now.
Smaller files are generally hurt more by the increase in seek times required with RAID 0 (finding something on 2 hard drives takes twice as long as finding it on one). The applications I have referred to before are the standards mentioned in most articles about RAID 0.
Mike, I'd suggest you read the Storage Review article more comprehensively, as they address several of your objections. It would be silly of me to parrot their results and testing here. My null hypothesis is that RAID 0 offers no significant benefit to a typical desktop user. I've seen nothing to disprove it. Show me differently.
Mike, I'd suggest you read the Storage Review article more comprehensively, as they address several of your objections. It would be silly of me to parrot their results and testing here. My null hypothesis is that RAID 0 offers no significant benefit to a typical desktop user. I've seen nothing to disprove it. Show me differently.
L1Trauma said:
This is a vastly different premise than your previous, repeated statement that Raid 0 is only useful for Photoshop and video editing.
L1Trauma said:
I've read the article that I link to quite carefully. It doesn't mention scatter gather, and it doesn't say anything about controller-provided cache or buffer. Is there another article that features more details?
L1Trauma said:
"Finding it" might take twice as long, since that means you're searching and that means you have to read all the data and figure out if it's the thing you're looking for or not. The time this operation takes is related to the amount of data on the drives, which, for two drives, can be twice as large as one.
But I can't imagine why seeking would take twice as long on two drives configured as a RAID 0 array.
When the drives seek, they know where they're going: to a very specific offset. The time this operation takes is loosely related to the size of the drive. If the drive has lots of tracks, it might take longer to plunge the head all the way from the inside to the outside. Modern drives change the number of platters and heads instead of adding more tracks so the effect is minimized.
If the drives two drives you're comparing are in a RAID 0 configuration, the heads on both drives can move concurrently, allowing the operation to take the same amount of time as with one drive. One drive might move while another is reading, which is also an optimization that a single drive can't match.
I'd love to come to understand your assertions. If you don't feel like "parroting", I'd really appreciate a link to the specific article that really does answer the questions I've been posting.
.B ekiM
*shrug* Were we talking about overclocking?Jiffylush said:
I would posit that most [H] users, in typical usagem would benefit from overclocking, but not RAID (RAID 0 assumed throughout),
To rebut your flawed analogy, a few other examples:
Synthetic benchmarks: Improved by OC. RAID improves HD "scores" but not content creation benchmarks, etc.
Word processing: Helped by neither.
Burning/Ripping: Neither
pr0n: Neither
Games: Improved significantly by OC, not by RAID.
Folding, SETI, et al: Improved by OC, not by RAID.
p2p: Neither.
Feel free to add other examples. We all know how the [H] staff feels about synthetic benchmarks (3dmark anyone)?
It's my argument, rephrased. You're not challenging that these users would benefit from RAID, you're challenging who I state would not. The point of all this is to state that most desktop users would not benefit from RAID.mikeblas said:
Since you seem to be unable to go the Storage Review's main page, linkage and quotes:
This article about multiple controllers, etc.
This article about a single controller.
This article about game loading times.
This forum thread.
The Anandtech article, for posterity.
Another article on boot times and level load times.
Not Raid, but why perception distorts reality.
Finis.
http://www.cia.gov/csi/books/19104/art5.html
Perhaps I should have defined "word processing" for you. Typing up a report or a paper for work or school. You could add Powerpoint to the list. Our computers have been too powerful for these applications for quite a while, thus the search for other applications for corporations to justify purchasing new hardware.mikeblas said:
I have been looking around, and one area seems to show a difference.
File transfers (go figure), this is from the article found here
I think users do copy/move files, so that is an area that can be improved by using raid-0.
FYI - I am using a 64k stripe size (if anyone cares)
File transfers (go figure), this is from the article found here
I think users do copy/move files, so that is an area that can be improved by using raid-0.
FYI - I am using a 64k stripe size (if anyone cares)
L1Trauma said:
Yep, I think you should. Since computers have so many uses, vague and general statements are pretty problematic.
When you write that definition, remember to incldue the length of the report or paper you're thinking about. I often work with reports that are hundreds of pages in length, and updating the table of contents or index, adjusting references, or even reformatting to fit a different paper size can take a while.
Maybe other people just dash of letters, or write much smaller reports.
.B ekiM
defakto said:
It's hard to find such a benchmark because nobody really knows what "everyday users would use". Every user is different. People use different applications for the same thing in different ways.
Even the same application causes different access patterns in different scenarios.
To get anywhere, you'll have to hold lots of variables constant: free memory, other running proceses, cache efficacy, and so on. Once you do that, are you sure you're still talking about "everyday users"?
.B ekiM
L1Trauma said:
Oh, I'm sorry! I was reading what you actually posted, not what you meant.
L1Trauma said:
Huh? I've been there many times.
The techreport.com link doesn't work. Is their site down?
The cia.gov link seems orthogonal. Is it your contention that just believe RAID to be faster, and so just use it without measuring?
I've read all of the StorageReview.com articles before, though not the thread. I'll go read it later, but even checking through these links, I haven't found anything that proves RAID's only "significant usage benefit is the transfer of large files, for video editing or a Photoshop scratchdisk."
I'd still be very interested in seeing such a proof. It would be very challenging to write, as it's very hard to have information about every application in the world, in order to be sure the expected benefits for those applications are not, indeed, realized.
Maybe it would be challenging to read, too, so I'm very eager to see it.
.B ekiM
I've been doing my best to answer your questions, but now I think that you'll need to perform your own benchmarks. Make sure you include performance metrics for files of different sizes, from letters to reports to theses.mikeblas said:
I look forward to your conclusions. To my knowledge, no one else has ever attempted so specific a comparison.
L1Trauma said:
You're saying something has been proven. I think the supposition in question is not only completely impossible to prove, but incorrect anyway. So I'm burning with curiosity about how it was proven.
Who's making a decision? About what? I'm looking for this "proof" you say exists.
Since you're taking pot-shots instead of providing anything insightful, then I guess I'll remain unsatisfied in this reguard. It's not surprising, as I didn't expect anything had been proven in the first place.
.B ekiM
unhappy_mage
[H]ard|DCer of the Month - October 2005
- Joined
- Jun 29, 2004
- Messages
- 11,455
Ooh! A flame war _and_ double, no, Triple posting! I can hardly contain myself.
Deep breath.
Raid0 is not my favorite. Having multiple spindles only makes things faster if you do different things with them. Although, as you point out, the drives can seek to any given location in "n" ms, two drives could seek to _two_ locations in "n" ms. This is the advantage of raid1. An intelligent controller of any sort will process two requests from different places of the drive at once. This effectively halves your latency. I tend toward the "lots of small files" approach in many things, so having two drives to seek two places would be nice. As far as I can see, raid0 only helps on sequential reads or writes. Anywhere else it can only hurt. The only real sequential-bound applications I can come up with offhand are - you guessed it - Photoshop and video editing. Video editing, you ask? Isn't the cpu the limiting factor? Well, it depends. I like to get the audio just right, and the video just right, and then mux the two into a nice ogm or avi. That muxing is diskbound, and I'd like to go from "Whew, done editing" to having an avi in less than 5 minutes. On a single ide disk, that's about how long it takes for a 700mb mux. Granted, this is a non-optimal setup, but this is where I'd support raid0. Nowhere else.
As for what uses non-sequential I/O, well dang near anything you name. Starting firefox. Reading your email. booting the computer. clicking on the start menu. _anything_ on a hard drive not recently defragged. you can take your pick, but all I know is I'm moving to hardware raid5 as soon as I can.
oh, and quit DP'ing. if you got two things to say, say both of them or click the edit button. two triple posts in a row is just ridiculous.
Oh, sorry, I thought this was a thread about hard drives. Wouldn't this kind of thing be processor-bound? If you're looking for a place to go really far OT like this, genmay subscriptions are really cheap now. Just $5 a year!
Deep breath.
Raid0 is not my favorite. Having multiple spindles only makes things faster if you do different things with them. Although, as you point out, the drives can seek to any given location in "n" ms, two drives could seek to _two_ locations in "n" ms. This is the advantage of raid1. An intelligent controller of any sort will process two requests from different places of the drive at once. This effectively halves your latency. I tend toward the "lots of small files" approach in many things, so having two drives to seek two places would be nice. As far as I can see, raid0 only helps on sequential reads or writes. Anywhere else it can only hurt. The only real sequential-bound applications I can come up with offhand are - you guessed it - Photoshop and video editing. Video editing, you ask? Isn't the cpu the limiting factor? Well, it depends. I like to get the audio just right, and the video just right, and then mux the two into a nice ogm or avi. That muxing is diskbound, and I'd like to go from "Whew, done editing" to having an avi in less than 5 minutes. On a single ide disk, that's about how long it takes for a 700mb mux. Granted, this is a non-optimal setup, but this is where I'd support raid0. Nowhere else.
As for what uses non-sequential I/O, well dang near anything you name. Starting firefox. Reading your email. booting the computer. clicking on the start menu. _anything_ on a hard drive not recently defragged. you can take your pick, but all I know is I'm moving to hardware raid5 as soon as I can.
oh, and quit DP'ing. if you got two things to say, say both of them or click the edit button. two triple posts in a row is just ridiculous.
Leadman584
Limp Gawd
- Joined
- Jun 10, 2004
- Messages
- 448
Raid of any flavor will benefit, fileserving, video processing, and CAD/CAM modeling. For anyone else, especially gamers, look for native SATA or SCCSI drives. Raptors though nice and fast, only support ATA 133 standard by default. Learned this the hard way, got 5 of em. A single U320 sccsi drive will run circles around my rig, till it comes time to do huge seqential reads, and writes. May still outperform me. Saw a Rig with 10-U320 sccsi drives running Raid 50 on a server board today, and good god was that thing fast. The 66 MHz PCI bus was the key I think. When they get the PCI-X thing widely supported, and prices come down a bit, I'm all over that. Till then, I'll plod along with what I got.
dunno - i for my part noticed a lot of performance increase when handling huge photoshop files and such (which i do quite a lot). other than that i don't really know. still, there's a lot of other reviews out there that tell a different story (here for example - although not the best example, i know). i think there was a lot of hype about going raid/0 some time ago without asking if it suits your needs or not, so maybe ppl are overestimating it. i for my part found it to be quite useful and Anandtech's conclusion seems to be too simple if you ask me - after all: what is a nomal day use anyways?
unhappy_mage said:
Sorry, unappy. I haven't been around here long enough to know that's not that the preferred posting method, and I don't see "DP" mentioned in The Rules.
unhappy_mage said:
Nowhere else at all?
What's surprising me about this thread is that the advice is at once all-encompassing ("the only proven") and overly restrictive ("the only applications"). Photoshop isn't the only application in the world that uses large files. What about other photo editing programs?
unhappy_mage said:
There are plenty of sequential-patterned applications.
Audio editing. There's tons of people doing audio production work on PCs these days. Playing and producing audio files is typically done sequentially.
Lots of database applications. Even within a database file, some queries need to sequentially scan the whole table. Plenty of database data comes from flat files before it hits the structured storage in the server, and that ends up being sequential. Data that moves to another server is sequential while it's in transit. Reports end up being sequentially written, even if the data that produced them came from random access.
Database management sytems endavor to do as much as possible in memory so that I/O is as optimal as possilbe.
And, yeah, many database applications use Raid 0, even if it has reliability issues. For large-scale relational database, and in data warehousing, storage is sometimes not that persistent because it's being loaded from some other source, used, then dropped or dismantled.
Creating a non-clustered index? Sequentially read all the records, then build the index.
Database transaction logs are written to sequentially. They might be re-read sequentially, depending on the recovery model being implemented.
Funny how Raid 0 is contraindicated for some applications because of reliability, but it shines at sequential I/O. And backup programs do sequential I/O over every file they back-up.
Web servers and media servers do plenty of sequential I/O. If you ask for a big page (or a file, or a resource), it's sent to you sequentially. Similarly, the client is reading it and storing it sequentially. These transfers are almost always governed by the network and not disk, so the client won't benefit too much. But the server, if it can't answer the request out of cache, is going to do sequential I/O over the file to transmit it. How did the file get into cache in the first place? Sequential I/O.
XML is a pretty popular scheme for representing data these days. XML is sequentially proessed. It's a byte stream, by definition, and doesn't have an index. B2B applications can produce monstorously large XML files.
Properly applied, Raid 0 can help these applications, and plenty others that I idn't think to mention.
.B ekiM