• 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.

To Raid 0 or not too Raid 0

petersondm

n00b
Joined
Mar 26, 2005
Messages
43
Hi all,

I was trying to setup a bootable Raid 0 on my new system with A8N-SLI Deluxe and had no luck setting it up. So I thought after doing some more research, will I see any increase in performance for what I do with a Raid 0 setup. I use my computer for online and single player gaming and general office work. I dont really do allot of swap or accessing large files.

My question is this: I have been told that if you install your OS on one drive and apps on another drive you will see an increase in performance because the system can access both drives at the same time. I am thinking I would just go with a WD Raptor for the OS boot drive and another WD Raptor for the second app drive. Does this make any sense?
 
Yea it makes sense although I'd put more on the raptor than just the OS since it will only fill up 4GB max or so. Personally, when a HDD costs 2.50$ or somewhere near there per GB, running Raid 0 and doubling that price for nearly no improvement isn't worth it.
 
Generally speaking you'll only see a big boost during intensive HD reads with RAID-0 (natch.) Loading levels in games, booting, and the like.
Two drives is an option, but it'll be nowhere near as fast when booting or gaming. Only in instances where you'd be reading from both drives simultaneously would it be able to compete. How often does that honestly happen? (And if it does, it's probably time to grab some more RAM.)
As far as such things go, no-one using the PC purely as a personal computer is going to benefit from RAID-0 all the time. What does make sense is that 2 cheap hard drives can outperform one expensive one in most cases, though you sacrifice data security in the bargain. One drive dies, you lose both.
 
spend money elsewhere... raid 0 on home systems nets you very little perf benefit...
 
nephilim said:
Generally speaking you'll only see a big boost during intensive HD reads with RAID-0 (natch.) Loading levels in games, booting, and the like.
Two drives is an option, but it'll be nowhere near as fast when booting or gaming. Only in instances where you'd be reading from both drives simultaneously would it be able to compete. How often does that honestly happen? (And if it does, it's probably time to grab some more RAM.)
As far as such things go, no-one using the PC purely as a personal computer is going to benefit from RAID-0 all the time. What does make sense is that 2 cheap hard drives can outperform one expensive one in most cases, though you sacrifice data security in the bargain. One drive dies, you lose both.

RAID0 doesn't impact load times in games at all. The only real main benefit from RAID0 is getting nearly double the read and write speeds and this will only benefit you if your transferring large files back and forth alot.

RAID0 is primarily meant for backup use on servers, not home use on desktops.
 
In testing with my Raptors, my seek times actually increased with a RAID0 setup, compared to a single drive. But the truth is RAID0 has been reduced to the level of myth in terms of performance benefits. Only in extreme rare cases does it show any real improvement. Data loss is increased by a factor of 2, so all in all, it's not worth it.
 
burningrave101 said:
RAID0 is primarily meant for backup use on servers, not home use on desktops.

Wrong, your thinking of Raid1. Raid0 is in fact more risky, not safer.

nephilim said:
Generally speaking you'll only see a big boost during intensive HD reads with RAID-0 (natch.) Loading levels in games, booting, and the like.

Actualy if anything it's been proven that in some games Raid0 makes loads ever so slightly longer :D
 
After reading this thread and others, it appears that Raid0 is pretty much worthless. Doesn't improve performance, is riskier, etc... So why does it even exist? And why would anyone ever use it? For video editing or something like that?

Seriously, are there any benefits at all?
 
Yes, for linear read/write on large files that are frequently changed and backed up. For video editors, user who work with massive high res images, etc, RAID-0 can be a huge performance boost - over 50% in ideal conditions - on large, contiguous (not fragmented) files. On smaller files, such as caching of skins, models, textures, physics data etc when loading a game, the drives have to seek to each individual file, so the drives are back to square one before the RAID-0 can get a good 'bite' on a long sequential transfer. The loss in reliability and minimal to nonexistant performance gain in gamer tasks mean it is not a good idea to use RAID-0 on a gaming system. Get any combination of: faster proc, better mobo, step up to 1GB of RAM, sink $180 more into a video card rather than get a second Raptor. Those will all give you a bigger performance boost than RAID-0 will ever come close to.

However, if you need advice on a workstation or a server, come back and we'll talk about RAID.
 
Thanks for the great info all. I should have done some more research on this one before buyng 2 74 Gig Raptors. Current new system specs are:

AMD 64 FX55
A8N-SLI-Deluxe
Dual BFG OC 6800GT's
2 Gig Mushkin DDR 3200 512x4 Part 991093 Cas 2.5 - 3- 3 - 8
NeoPower 480
SB Audigy 2 ZS Pro
Case Cool Master Praetorian PAC-T01-EK
WD 74 Gig Raptor on NVidia Sata 1

This is the one I was going to run Raid 0 on but not any more.

Thanks again.
 
I don't see a point to Raid 0 at all, it significantly increases the risk of getting rid of all your data... Raid 1 if anything, bro.
 
The point is that the STR goes up and it can handle large I/O counts better...which is cool if you're doing content creation, and helps a little for pagefile. Problem is because it makes some things faster, people think it'll make what they're doing faster...which usually isn't the case.

Edit: RAID 1 is overused too, it protects against drive failure AND NOTHING ELSE. Use single drive for desktop computers, and backup anything you don't want to lose.
 
raid 0 isnt raid at all, raid 0 is usefull for transfering hella large files over a gigabit network IE DVD backups
 
burningrave101 said:
The only real main benefit from RAID0 is getting nearly double the read and write speeds and this will only benefit you if your transferring large files back and forth alot.

I guess it depends on what you mean, exactly, by "transferring large files back and forth alot". But the gist of your statement doesn't match my measurements.
 
Not to dis your program at all, it looks sweet and you have some pretty nice results, but i suspect you may have found different things reading for random sections of a larger file. I mean, 65 megs isnt too huge, even on a 74gb disk, Seek times would come into the equation much more i think if the disk was fragmented, or even if reading from opposite ends of a rather large file or block of continous files (think a big ass wad/3-4GB game install)
 
Herulach said:
I mean, 65 megs isnt too huge, even on a 74gb disk,

65 megs isn't big, no. That's why I used a file that was much bigger; about 65 gigs.

Herulach said:
or even if reading from opposite ends of a rather large file or block of continous files (think a big ass wad/3-4GB game install)

I don't know what an ass wad is. I mean, I do, but I don't know what it could mean in this context.

My program ends up reading from distant sectors within a single large contigious file. It gets a random number between 0 and 32767 (inclusive), then multiplies that by the read size. The resulting value is used to seek within the file before performing the read.

And that's why the file is so large; 32767 times two megabytes is around 65 gigs. I varied slightly from exactly the right amount -- but I can't remember why at the moment.
 
mikeblas said:
65 megs isn't big, no. That's why I used a file that was much bigger; about 65 gigs.
My Apoligies, i misread that.

I don't know what an ass wad is. I mean, I do, but I don't know what it could mean in this context.
A big ass wad, as in a Wad file (what Doom, and i belive quake called the game data files). I worded that rather unfortuantely didnt i?

Like i said, my main criticism was file size, but since thats not an issue feel free to ignore me.

An interesting benchmark would maybe to test the write speeds, as i imagine theyd be significantly slower, especially if youre at full cpu load, as you obviously have to wait for it to compute whatever it computes, assuming youre not on a pci/x/e controller.
 
Herulach said:
Like i said, my main criticism was file size, but since thats not an issue feel free to ignore me.

Yeah; I don't know what those are, either. I'm not much of a gamer.

Even if I was, what I would want to have is the access pattern the program uses over the file. Does it read a sector at a time? One megabyte at a time? Does it read some then process, so some other thread someplace might cause I/O and move the head? Does it allocate memory, which might move the head towards the page file?

And so on.

Maybe I can try adding writes; it shouldn't be hard to add. It's just a matter of finding contigious time in my fragmented life.

People in this thread have cited the "copying large files" benefit to RAID 0, which I have seen often. But I don't understand it as I've never observed the COPY commands (or even the ROBOCOPY program) reading or writing file data in chunks larger than 64 kilobytes. Since the I/O request is fixed at a maximum size of 64k, what constitutes a "large file", specifically? more than 128 kilobytes?
 
Im Not any kind of expert on this kind of stuff, but i was always under the impression that what slows raid 0 down on small files was doing all the checksumming, which isnt a huge problem while youre at idel, but if youre at load, i.e, in a game, the cpu doesnt have the spare cycles, so either its waiting around for the disk, or the disk is waiting for it.

As far as the large file thing goes, i think people mean, one continuos read/write, as opposed to lots of shorter ones, but i dont rightly know.

I think raid is just one of those things people like to have, without having any real reason to have it, when they could spend the same money and see an actual performance increase from scsi. Same with people who SLI 2 6600GTs, i mean, whats the point?
 
Herulach said:
but i was always under the impression that what slows raid 0 down on
small files was doing all the checksumming,

You're thinking of RAID 5. RAID 0 doesn't involve checksumming. And if it did, checksumming varies constantly with the size of the region to be summed.

Herulach said:
which isnt a huge problem while youre at idel, but if youre at load, i.e, in a game, the cpu doesnt have the spare cycles, so either its waiting around for the disk, or the disk is waiting for it.

When games load levels, I would have assumed that the CPU was idle. If the game needs to load the level files, what is it doing if not waiting for the next level to be playable? If gamers are still playing the game and keeping the CPU busy while the load happens in the background, why is load time for levels an issue?

Herulach said:
As far as the large file thing goes, i think people mean, one continuos read/write, as opposed to lots of shorter ones, but i dont rightly know.

My point is that one continuous read operation doesn't happen when copying a file with the COPY command; neither does one continuous write. It's broken into smaller units; from my obsrevation, each unit is always 64k in size.

Herulach said:
I think raid is just one of those things people like to have, without having any real reason to have it, when they could spend the same money and see an actual performance increase from scsi. Same with people who SLI 2 6600GTs, i mean, whats the point?

Not being a gamer, I can't see why anyone needs a framerate faster than 60 fps. I just buy whatever card costs about $150 and I'm done.

There are legitimate reasons to use RAID 0, but I'm not sure the original poster has found one of them. What sometimes worries me is the ill-found negative postings about RAID 0 dissuading those who do have a legitimate use for the technology from actually employing it.
 
Agreed MikeBlas my original post was to help inform and ask a question regarding Raid O. After further research and cutting through the hype put out there but custom PC builders it seemed that for gaming Raid 0 was the way to go but in the long run it would only make a diiference if you was loading levels and files often. For me this wouldn't be the case but it makes all the sense in the world for heavy graphic or sound recording work, large network file transfers and servers.
 
mikeblas said:
Not being a gamer, I can't see why anyone needs a framerate faster than 60 fps. I just buy whatever card costs about $150 and I'm done.

Average framerate of 60 can drop much lower in parts. If the average is higher, the bottom will stay over 60. Also if it's higher you can sac part of it for better quality.

If you don't game, $150 is still probably too much to pay.
 
n64man120 said:
Wrong, your thinking of Raid1. Raid0 is in fact more risky, not safer.

Actualy if anything it's been proven that in some games Raid0 makes loads ever so slightly longer :D

RAID0 is used on specific servers to quickly backup data to the mainframe or other storate utility. The data is constantly being backed up so if a drive fails hardly any data is lost. But as far as a main server goes where the data stays on the server then no you wouldn't want to use RAID0.

We just went over the chapter about RAID arrays in my Windows Server 2003 class a couple of weeks ago :).

petersondm said:
Agreed MikeBlas my original post was to help inform and ask a question regarding Raid O. After further research and cutting through the hype put out there but custom PC builders it seemed that for gaming Raid 0 was the way to go but in the long run it would only make a diiference if you was loading levels and files often. For me this wouldn't be the case but it makes all the sense in the world for heavy graphic or sound recording work, large network file transfers and servers.

I say again, RAID0 has no impact on loading levels in games. Thats nothing more than a myth thats been proven wrong by several sites that did the tests. If anything RAID0 will lower the performance for gaming because the seek time is now lower then it is for a single drive.
 
burningrave101 said:
If anything RAID0 will lower the performance for gaming because the seek time is now lower then it is for a single drive.

My tests don't bear this out. Some of the tests at sotragereview.com don't, either.
 
mikeblas said:
My tests don't bear this out. Some of the tests at sotragereview.com don't, either.
It did for me testing two Raptors, and so did Anandtech's review that started the whole "RAID0 is wortless" fact finding mission. My seek times were slower with RAID0 regardless of sector size. It's one of the contributing factors in the overall consensus that RAID0 is nothing more than a gimmick. It's dead, and buried.
 
Agreed. Mike's results don't show any sort of scalability with RAID-0 until the 131,072 transfer size. Looking in my UT2004 directory, half the files in it are smaller than 256KB. Of the ~2400 files in my UT2004 directory, >1200 of them are less than 256KB, 1400 of them are less than 1MB, and 1800 of them weigh in at less than 4MB. These results are obviously not scientific, but it's pretty reasonable to assume that loading levels in 2K4 is going to involve seeking to quite a few smaller files, which is precisely where RAID-0 falters. Furthermore, I'm not aware of a method to optimize the order of these files on the disk to optimize level loading like Windows XP optimizes its boot times.
 
djnes said:
It's one of the contributing factors in the overall consensus that RAID0 is nothing more than a gimmick. It's dead, and buried.

RAID 0 does very well in appropriate applications. If you don't have those applications, feel free to ignore it -- but for those applications it's very useful.

djnes said:
My seek times were slower with RAID0 regardless of sector size.

How much slower? How was sector size relevant, and how did affect the measured times? What about stripe size or I/O request size? How did you measure seek time? Where can I read more about your test methodology and your results?

I hope you can provide a test I can reproduce, or insight into the issue. I'm just dying to deeply understand why RAID 0 would increase seek times.
 
DougLite said:
Agreed. Mike's results don't show any sort of scalability with RAID-0 until the 131,072 transfer size.

Scalability? Scaling to what? Larger transfer sizes? More users? Concurrent access? More spindles?

I think the charts I provided show that the smallest transfers are also quite fast, and that seek time isn't hampered on those small transfers.

If the rates for RAID at the left side of the graph where there's lots of seeking (seeking just to read 256 bytes!) were lower for RAID 0 than a flat drive, I'd agree that RAID 0 hurts seek time.

But they're not; the rates for RAID 0, including the seeking, are much higher. The storagereivew.com test shows a similar result: the read service time is almost the same.

DougLite said:
Looking in my UT2004 directory, half the files in it are smaller than 256KB. Of the ~2400 files in my UT2004 directory, >1200 of them are less than 256KB, 1400 of them are less than 1MB, and 1800 of them weigh in at less than 4MB. These results are obviously not scientific, but it's pretty reasonable to assume that loading levels in 2K4 is going to involve seeking to quite a few smaller files, which is precisely where RAID-0 falters.

Maybe you've luckily arrived at a correct conclusion, but this is indeed more conjecture than scientific evidence. As it stands, you haven't shown how many seeks are actually happening or that they're the bottleneck in level loading.

To make a good conclusion, a great deal more insight is needed. While loading, is this game I/O bound, or CPU bound? Asynchronous I/O, or synchronous? Is it page faulting at the same time that it's trying to load? Any processing after reading each file? What are the I/O request sizes? How is the file opened? And so on.

DougLite said:
Furthermore, I'm not aware of a method to optimize the order of these files on the disk to optimize level loading like Windows XP optimizes its boot times.

I'm very curious about something. Why are gamers concerned about the time it takes to load a level? It must be that waiting for the load is time spent not playing, so slower load times negatively affect the gaming experience.

Why, then, would game developers create tons of small files instead of trying to guarantee good sequential I/O and with larger transfer sizes by using flocks of small files? 2400 files?! This hinders performance regardless of the disk subsystem.
 
mikeblas said:
I hope you can provide a test I can reproduce, or insight into the issue. I'm just dying to deeply understand why RAID 0 would increase seek times.

I will search my offline archives from my website, where it was posted. YOu must have missed out on all the arguing and debating that went on here. Quite a few of us ran tests to determine if RAID0 was a gimmick or not. Every single one of us, regardless of what side we were on before, agreed it was useless in 99.9% of all desktop systems. I myself was on the pro-RAID0 side before testing. I'm not really sure what your looking for, or if your attempting to start more arguements such as the ones in the page file thread in the OS subforum, but facts are facts. If you don't want to believe the number of us who did testing, start poking around on Anandtech for his review.

If your all for simply learning, then I apologize for the attitude. We've had a rash of people lately who argue to no end simply because they have an opinion differing from proven fact. If I remember correctly, my seek time was 8.4 ms with a single Raptor, and 9.0 ms in RAID0. Hardly an world of difference, but hardly an argument in support. In the end, it came down to very little if any actual performance gain, and a huge increase in risk of data loss.
 
djnes said:
YOu must have missed out on all the arguing and debating that went on here.

Yep, I guess I did.

djnes said:
Quite a few of us ran tests to determine if RAID0 was a gimmick or not. Every single one of us, regardless of what side we were on before, agreed it was useless in 99.9% of all desktop systems.

Then, since you know it's useful for 0.1% of desktop users (and haven't even commented on workstation or server users), you must think it's not a gimmick.

I certainly understand that RAID 0 doesn't improve everything for every application.

But I don't think that it causes slower seek times. If it does, I'd dearly love to understand why, because it's not at all intuitive to me. These threads spout with generalizations, and I distrust generalizations; particuarly ones that don't have backing evidence that I can observe or reproduce.

"bad for smaller file sizes". Why? Below what specific file size? How does stripe size and request size factor into the equation? How much worse?

"lots of seeks". How many seeks? Seeking to service what read request size? Seeks then go hand-in-hand with smaller files, but is that really true? At what point does the file system's cache of the directory and allocaiton info overtake the inefficiency of seeking?

"only good for large file transfers". I can't catch the COPY command reading or writing in anything larger than 64k blocks. Is 128 kilobytes a "large" file, then?

"only good for gigabit networks". Well more than 0.1% of people have these on their workstations. So that's conflicting.

"random access". How random? To service what read size? After all, if I "randomly" go to some spot on the disk and read 100 megabytes, then "randomly" go to some other spot and read 75 megabytes, I should still be winning, right?

And so on. I want to understand the performance very (very!) deeply. If RAID 0 doesn't provide a performance boost for a particular application, then that's great. I want to understand exactly why. Conversely, I want to understand what situations RAID 0 does provide a clear performance win, and what parameters enable those scenarios.

djnes said:
I'm not really sure what your looking for, or if your attempting to start more arguements such as the ones in the page file thread in the OS subforum, but facts are facts.

My approach to the page file threads is quite different. I know lots about paging and memory management. There's a lot of posts around here from people who don't are providing half-truths as explanations and that causes other people to reach ill-found conclusions. I'm trying to set the record straight when I know better than what's been presented. I'm sure you've noticed that I've been very responsive with details to questions, and provided specific authorotative references to back up what I'm explaining.

My approach to the RAID issue is quite different. The RAID questions I have are coming from ignorance. I've read as much as I can about how RAID subsystems work, and my expctations of the limitations of the approach don't lead me to anticipate the problems (see above) so often espoused here.

Being the compulsively inquisitve and curious sort, I want to learn exactly why those limitations and shorcomings eixst. What is their cause? What are their characteristics under different parameters? And so on.

djines said:
If you don't want to believe the number of us who did testing, start poking around on Anandtech for his review.

It's not that I'm in a state of disbelief : I haven't been presented with anything that I should or shouldn't believe! I have plenty of questions about the asertions that I've seen here, and they go unanswered -- or, at least, they're not answered to any satisfactory level of detail.

djines said:
I will search my offline archives from my website, where it was posted.

Please let me know what you'd find; I'd be thrilled to have some new information on the subject.
 
mikeblas said:
Scalability? Scaling to what? Larger transfer sizes? More users? Concurrent access? More spindles?
My reference to scalability refers to being able to scale throughput. RAID-0 does not show noticeably increased transfer speed/throughput over single drive until the 131072 transfer size.
mikeblas said:
Maybe you've luckily arrived at a correct conclusion, but this is indeed more conjecture than scientific evidence. As it stands, you haven't shown how many seeks are actually happening or that they're the bottleneck in level loading.

To make a good conclusion, a great deal more insight is needed. While loading, is this game I/O bound, or CPU bound? Asynchronous I/O, or synchronous? Is it page faulting at the same time that it's trying to load? Any processing after reading each file? What are the I/O request sizes? How is the file opened? And so on.
I have never contended that RAID-0 made seeks slower or lowered performance - my contention all along was that it did not deliver double digit percentage increases in performance, and that RAID-0 increased cost and the likelihood of data loss. Others have asserted the increased seek time, not I. Once again, I couldn't care less about all of the numbers except for time - how long it takes to complete a given real world task.
mikeblas said:
I'm very curious about something. Why are gamers concerned about the time it takes to load a level? It must be that waiting for the load is time spent not playing, so slower load times negatively affect the gaming experience.
Precisely. If I'm sitting looking at a loading screen, I'm not playing. I (and most every other [H]'er) could care less about IO/sec, seek time, transfer rate, etc. If a given storage system gets us into the game faster, then it's, well, faster.
mikeblas said:
Why, then, would game developers create tons of small files instead of trying to guarantee good sequential I/O and with larger transfer sizes by using flocks of small files? 2400 files?! This hinders performance regardless of the disk subsystem.
As for lots of small files - only a small portion of them are loaded at any one time. It's only going to load one map, a fraction of the of static meshes/textures/etc, at most 32 models/skins, etc.
 
DougLite said:
RAID-0 does not show noticeably increased transfer speed/throughput over single drive until the 131072 transfer size.
[/QUOET]

You don't notice the lines for the RAID 0 system being higher than the lines for the flat drive at 512 and 1024 byte transfer sizes?

DougLite said:
I have never contended that RAID-0 made seeks slower

Sorry! I must've crossed-up my thoughts while posting. Indeed, you're the "bad for smaller file sizes" guy.

DougLite said:
As for lots of small files - only a small portion of them are loaded at any one time. It's only going to load one map, a fraction of the of static meshes/textures/etc, at most 32 models/skins, etc.

Then why not only load a smaller contigious part of the larger file at one time? The read for this could be entirely sequential (or be done in one shot after a seek from the index to find the beginning of the needed data).
 
I got have nothing left on my server. I guess this was my lesson on why I shouldn't have given my fiancee access to my webspace (although she needed it for her portfolio). Hopefully some of the others who did the testing will have their results left. I can't test anymore, because after the disappointing results of the tests, I split my array, and gave her one for her web dev machine.
 
mikeblas said:
My tests don't bear this out. Some of the tests at sotragereview.com don't, either.

Well i dont know what your tests bear dude but without any testing you should realize that accessing two drives is going to be slower then accessing just one in response time. It wont be a big difference but RAID0 is definitely not faster for gaming. Its the same speed or slightly slower then running a single drive.
 
burningrave101 said:
Well i dont know what your tests bear dude but without any testing you should realize that accessing two drives is going to be slower then accessing just one in response time.

That's not intuitive at all. If I implemented RAID 0 in software (or firmware), I'd take a seek request and send it to the first drive. While that was processing, I'd send the required seek request to the second drive.

Then, I'd wait until one drive or the other answered. When either drive was ready after the seek, I'd initiate an asychronous read request and return to waiting for command completion. When the other seek finishes, issue the read to that drive. When a read finishes, I'm done with that drive.

If the drive supports queuing, I obviously don't need to wait for the seek to finish. I can issue the read command as another outstanding I/O operation and let it be queued so that it will execute as soon as the seek completes.

At this level, I know the stripe size of my array. I also know the size of the request that I was reqeuested to process. If the request is less than the strip size, I know I need only one seek-read request pair.

I'm never slower than a single drive, then. Even when I'm issuing two commands, the commands are overlapped with another command, and therefore I'm never longer than the work a single drive has to do. Graphing the algorithm on a timeline shows that one drive or another will finish second, but only by the duration it takes to issue one of the commands. Issuing a command is very inexpensive; waiting for it to complete is what actually takes time. The concurrency is actually a savings.

Because both the seeks and the reads can happen concurrently, and don't need to happen in order, I see no reason for there to by any substantial latency.

Why is that conclusion incorrect? What makes it so apparent to you that there must be additional latency?
 
single drive performance 40-60MB/s

Raid0 performance 80-88MB/s

most people that say raid0 is a wast of time and money dont know what they are doing and if they have tied it have failed at geting anyperformance out if it

My reson being found is that if you dont use 16k block size on most controllers (for the home owners budget controlers) is the only block size that will grant any perfomance gain.

the 80-88MB/s is actualy limited by the controler chipset and i dont care how much money you spend for a pci thats about it..

i have yet to try out the onboard raid from intel the ICH5R / ICH6R

However the Nvidia Nforce3 chipset has acheave fargeater perfomance of up to 115MB/s on 2 250GB SATA Western Digital drives

I'm awaiting the release of the new Nvidia chipset for the intel P4 so that i also can have some faster raid from Nvidia

(currently the only way to get Nvidia raid is to buy a Nforce 3-4 mobo at least that i know of)
 
petersondm said:
Agreed MikeBlas my original post was to help inform and ask a question regarding Raid O. After further research and cutting through the hype put out there but custom PC builders it seemed that for gaming Raid 0 was the way to go but in the long run it would only make a diiference if you was loading levels and files often. For me this wouldn't be the case but it makes all the sense in the world for heavy graphic or sound recording work, large network file transfers and servers.

Poster already had his question answered, LET IT DIE, there are enough RAID 0 threads open.

Please?
 
NO MWAAHA HAHAH A H!! okay last post then lock it

SeagateDual80GBSATA.jpg


Maxtor80GB.jpg


Raid 0 is FASTER at transfering and is bigger, that is ALL
 
Still no response? I guess it's not so obvious or easy to explain why seeks are slower in RAID 0, after all.

Aren't those runs showing that the access time on the RAID 0 array is actually lower? 12.7 mS compared to 12.9 mS? Is that an average?
 
Back
Top