Raptor vs. RAID zero for games drive

N

Nicepants42

Gawd
2FA
Joined
Aug 30, 2004
Messages
772
Ok, I'm having a brain fart here and cannot remember any decent comparisons on this issue.

Basically, I've got one raptor 150, and 4 identical Seagate 7200.9 SATA drives. For game performance, is it faster to have the OS and games on the raptor, or the OS on the raptor and the games on a RAID 0 (probably a 2-drive RAID 0).

Thanks for the help.
 
If your seagate drives are SATA II compliant, and your SATA controller is as well, with two of them in raid0, you theoretically have twice the possible throughput than the single raptor.

Of course, the raptor probably has a lower access time...

IMO, I would do RAID0 for the 4 drives, install the OS and program on there, and have your games on the raptor.
 
Nicepants42 said:
Ok, I'm having a brain fart here and cannot remember any decent comparisons on this issue.

Basically, I've got one raptor 150, and 4 identical Seagate 7200.9 SATA drives. For game performance, is it faster to have the OS and games on the raptor, or the OS on the raptor and the games on a RAID 0 (probably a 2-drive RAID 0).

Thanks for the help.
Click to expand...
The Raptor will be faster than any combination of the 7200.9 drives in RAID unless you're doing something like copying large files.

We'll be generous and say RAID-0 will give you a 10% increase in performance in both general use and gaming (unlikely) compared to an identical single drive.

Compare that will the beat down the Raptor 150 lays on the Seagate 7200.9
http://www.storagereview.com/php/be...&numDrives=1&devID_0=309&devID_1=295&devCnt=2
 
I'd be extremely surprised if a single raptor beat a Raid0 of 2 .9 drives. Maybe on a software controller.

That is in terms of raw speed. The raptor will probably use less power then a raid0 and 'could' be more reliable,

I prefer hardware Raid0 to Raptor, they are just too pricey for the storage you get.

I don't really agree with EnderW since that link shows a Raptor vs A seagate.... o/c the raptor is faster. Why even make that chart ?

10% increase ? Um, maybe you should look at my setup and tell me thats 10%, I promise you that Raid0 on a good controller is way more then 10%
http://i15.tinypic.com/30m2074.jpg

Edit: Those are my old numbers, I'm getting about 410-420MB/s burst and 142-148MB/s seq read now. And I do realize those are older raptors, but they are also in raid0.
 
este said:
I'd be extremely surprised if a single raptor beat a Raid0 of 2 .9 drives. Maybe on a software controller.

That is in terms of raw speed. The raptor will probably use less power then a raid0 and 'could' be more reliable,

I prefer hardware Raid0 to Raptor, they are just too pricey for the storage you get.

I don't really agree with EnderW since that link shows a Raptor vs A seagate.... o/c the raptor is faster. Why even make that chart ?

10% increase ? Um, maybe you should look at my setup and tell me thats 10%, I promise you that Raid0 on a good controller is way more then 10%
http://i15.tinypic.com/30m2074.jpg

Edit: Those are my old numbers, I'm getting about 410-420MB/s burst and 142-148MB/s seq read now. And I do realize those are older raptors, but they are also in raid0.
Click to expand...
No matter how good the controller is, it will not decrease the physical latency of seeking on two spindles instead of one. Especially not 2x (or 4!) 7200rpm spindles versus 1 10,000rpm spindle.

Any idiot can show high sequential transfers on HDTach. Hell, I can beat a Raptor on HDTach with two 80GB drives from 1999. Doesn't mean they're faster in anything outside of HDTach.
 
este said:
I'd be extremely surprised if a single raptor beat a Raid0 of 2 .9 drives. Maybe on a software controller.

That is in terms of raw speed. The raptor will probably use less power then a raid0 and 'could' be more reliable,

I prefer hardware Raid0 to Raptor, they are just too pricey for the storage you get.

I don't really agree with EnderW since that link shows a Raptor vs A seagate.... o/c the raptor is faster. Why even make that chart ?

10% increase ? Um, maybe you should look at my setup and tell me thats 10%, I promise you that Raid0 on a good controller is way more then 10%
http://i15.tinypic.com/30m2074.jpg

Edit: Those are my old numbers, I'm getting about 410-420MB/s burst and 142-148MB/s seq read now. And I do realize those are older raptors, but they are also in raid0.
Click to expand...
What does HD Tach measure? And how does that correlate to overall increased performance in OS responsiveness or gaming?
(hint: it doesn't)

I'm so tired of responding to bullshit like this. If you want to be ignorant, fine, but educate yourself before posting wrong information in here that is just going to mislead people.
If you want to learn, read through my old posts in this forum and/or spend a few hours at SR.
 
So here's my question.. total Threadjack, but I don't care.

Say you have two spindles. Why doesn't the controller seek both at once instead of doing one at a time?

Is it because the IO operation, as much as we're trying to parallelize it (by having 2 drives), it's still a serial operation?
 
I asked the same question back when I first joined the forum, mwarps. All the "experts" couldn't provide an answer. I got flamed left, right, and sideways.

Finally, a friend of mine at work helped me understand it. I posted the explanation here; I'll see if I can dig it up.

LATER: Feh! The search in the forum only returns results that are less than a year old.

The upshot is that it's about twice as likely that you'll have to wait for the data to come around a whole revolution of the platter. Regardless of you're getting a small transfer (less than the stripe size, from only one drive) or a larger transfer (larger than the strip size, from multiple drives), you still can't finish until the slowest one is done. The slowest one won't be done until the drive rotates 'round, and statistically that's usually going to take longer the more drives you've got.

And that's only considering rotational latency: seek latency is even worse.
 
mikeblas said:
I asked the same question back when I first joined the forum, mwarps. All the "experts" couldn't provide an answer. I got flamed left, right, and sideways.
Click to expand...
Those ""experts"" don't, for the most part, write drive firmware or implement controller hardware. They can't provide a high-level explanation for a low-level behavior without knowing the low-level behavior. For example, to the layman there's no reason not to synchronize the spindles of an array, so the platters are in the same orientation at the same time. But a layman in terms of the actual hardware can write tests that show marginally increased seek times.

And raid 0 is a controversial topic. Some people contend that it is useful for every application, some are more conservative about suggesting its use. Especially over a text-only medium like this forum, people's blanket statements tend to raise emotional responses. Not entirely surprising. Things that you would normally take in stride as a normal part of conversation are interpreted as personal attacks, and human nature takes over.

Last point: try searching for threads started by mikeblas in DS. Here's the thread where you last raised this question, and here's the post you mentioned.
 
unhappy_mage said:
They can't provide a high-level explanation for a low-level behavior without knowing the low-level behavior.
Click to expand...
Whatever their background, I see no excuse for flaming someone when they're asking a question.
 
mikeblas said:
Whatever their background, I see no excuse for flaming someone when they're asking a question.
Click to expand...
Define "flaming", please. Much of that discussion takes place because, to quote post #10, "I'm requiring a very detailed explanation.". People have cited sources that show the high-level behavior (increased latency in reading from raid 0 arrays) and they don't know the low-level behavior, so what you wanted to discover isn't going to be introduced into that thread. Unless someone introduces it from outside. That post suggests that since the spindles aren't aligned, the average rotational latency goes up, and then you dismiss it.

I very much respect your opinions, Mike, but you can be very difficult when you want to.

And, with that, I think it's time that I returned to bed. Today isn't working out for me.
 
unhappy_mage said:
Define "flaming", please.
Click to expand...
Find the threads where I was asking about why RAID 0 would be slower given a well-thought out, asynchronous implementation, and you'll see the specific cases I'm talking about.

unhappy_mage said:
People have cited sources that show the high-level behavior (increased latency in reading from raid 0 arrays) and they don't know the low-level behavior, so what you wanted to discover isn't going to be introduced into that thread.
Click to expand...
Which is fine. When people don't respond, or actively respond and say "Gosh, I don't know", that's no problem. When people flame about how I'm an idiot if I can't figure it out, or that I should get off my ass and research it myself, or that everybody aggrees, why am I so special, and so on ... that's what I'm talking about.

unhappy_mage said:
I very much respect your opinions, Mike, but you can be very difficult when you want to.
Click to expand...
Thanks for your compliment, albiet backhanded. I'm not really sure what I've done that's caused such difficulty for you, though.

unhappy_mage said:
And, with that, I think it's time that I returned to bed. Today isn't working out for me.
Click to expand...
Me, too: you seem to have a real chip on your shoulder today. I hope you'll rejoin us when you're feeling your normal, constructive self!
 
mikeblas said:
The upshot is that it's about twice as likely that you'll have to wait for the data to come around a whole revolution of the platter. Regardless of you're getting a small transfer (less than the stripe size, from only one drive) or a larger transfer (larger than the strip size, from multiple drives), you still can't finish until the slowest one is done. The slowest one won't be done until the drive rotates 'round, and statistically that's usually going to take longer the more drives you've got.
Click to expand...
Since it's waiting for one before it starts the other, then yeah, it's still mostly a 'serial' operation. That's all I wanted to know.

Obviously there could be ways of optimizing the controller to work in parallel, but it would have to re-assemble the data on the fly, adding massive amounts of complexity for a reasonably insignificant gain.
 
I'm not sure why reassembling the data is so complicated.
 
mikeblas said:
I'm not sure why reassembling the data is so complicated.
Click to expand...
Doing it in software is pretty easy. Doing it in hardware is not.
 
And raid 0 is a controversial topic. Some people contend that it is useful for every application, some are more conservative about suggesting its use.
Click to expand...
And it will continue that way because everyone has a different opinion about the risks of data loss, added cost and how much of a performance increase(or decrease) RAID0 will give you in that person's use of their PC. In the 4 years I've used it, I've had nary a problem with RAID0, but I do have an image of it on a storage drive, but not for just the "risk" factor. Cost, well I don't mind spending an extra $100 for another hard drive to hopefully speed up about the slowest sub system of my PC and then there's imaging software if you have to pay for it. And most importantly is performance which is drive, controller and system dependant and is subject to mostly subjective opinion with maybe a little bit of benchmarking done to justify their feelings. My average improvement over a single drive in boot times, heavy game and app loading, and DVD encoding/decoding, etc has been about 15-20%. If I took a hit in opening my browser becasue it's small program and I lost some quickness in RAID0, it isn't noticeable to me and didn't stand out for me to even do a comparsion. So for the OP, the answer is something you'd have to discover for yourself, which with all your drives, you have a lot of options. It'll take time and be a pain, but that's the only way to get your answer I think.
 
http://www.anandtech.com/storage/showdoc.aspx?i=2101&p=10
http://www.anandtech.com/storage/showdoc.aspx?i=2760&p=10
http://www.anandtech.com/storage/showdoc.aspx?i=2682&p=7

Basically RAID 0 does very little to improve game level loading performance.

Yes it can help by a few seconds in some games (and hurt by a few seconds in some game) so you have to determine if for the games you play, if there is a performance increase, and if that performance increase is worth the added risk and complexity of RAID 0. The answer to this is different for every person.
 
Thanks for those links, those level loading tests are very interesting.

I seem to recall seeing some testing during actual gaming though, maybe over at SR, and then there's the whole issue of having the game and OS separated vs. on the same drive.

I think I'll go ahead and install the OS(s) on the raptor and then run a couple tests with games on various drive combinations.
 
I skimmed over those anandtech reviews... I didn't see anything regarding stripe size though.

In general, is smaller or bigger stripe size better for something like game level loading?

When would you use a larger stipe size vs a smaller? I've had two arrays. 128k and 64k. Notice no difference unfortunately between the two. Maybe a 16k next???
 
If I write something that gets data from disk, I try to write it to do as much serial I/O as possible. That's fastest, no matter what controller, disk, or storage architecture is in use. RAID or not, serial I/O is best.

The problem is that game writers don't seem to see it the same way. I did some testing with Far Cry, and found horrible amounts of seeking and rereading going on.

As a result, I think a smaller stripe size is going to be better for level loading -- at least, for the one game that I studied. Thing is, the behaviour of that game is so bad that adjusting the stripe size isn't going to make much of a difference.

When we work on enerprise class software here at the bit factory, we test our assumptions. We get vendors to give us their products and deep performance testing of the product on that hardware. We adjust the software, validate our assumptions, and go from there.

I don't think game vendors are doing that, even with the now common motherboard-integrated RAID controllers. As a reuslt, I don't think it's a reasonable to expect their code to scale well to more advanced I/O subsystems.
 
Nicepants42 said:
Thanks for those links, those level loading tests are very interesting.

I seem to recall seeing some testing during actual gaming though, maybe over at SR, and then there's the whole issue of having the game and OS separated vs. on the same drive.

I think I'll go ahead and install the OS(s) on the raptor and then run a couple tests with games on various drive combinations.
Click to expand...

If your hard drive affects your FPS in game you do not have enough RAM in your system, end of story. You could have a trained pigeon pecking ones and zeros as your hard drive and if it affects FPS in game the solution is not to give the pigeon caffeine but rather to add more RAM to your computer. If you want to improve the dismal load times that a pigeon drive would provide, I recommend either a Raptor or some other modern drive.. Possibly RAID 0 if your favorite game is one that gains from that implementation.
 
mikeblas said:
Why not?
Click to expand...

Since I don't do IC design for a hard drive controller company, I couldn't say with precise certainty.

I actually spent an hour typing a response and doing math.

Instead of actually posting it here, I'm going to work on it and present it to a controller manufacturer.

In short, millions of transistors.

4 Lines of code == millions of transistors.
 
mwraps said:
Since I don't do IC design for a hard drive controller company, I couldn't say with precise certainty.
Click to expand...
Then I'm sure you can understand why I'm skeptical of your assertion that it's hard to do.

I don't work at a drive controller company, either, but I've done plenty of digital electronics design, and I don't see what the stumbling block is. You've got the drive bringing data back to the controller. The controller "glues" the drive to the memory bus of the machine, using DMA to write the result of a request to the drive. PATA or SATA, the data arrives byte-by-byte, which means that the controller is responsible for setting the address bus to reference the memory where the data will land.

If no RAID, then the data is just written. The next sector goes to the next address.

If RAID0, then the data from a drive is just written until the end of the sector. The, the stripe size is added to the address. This skips the region where the other drive(s) will write its/their data. The starting offset is different for each drive.

I think this requires a local buffer on the card, the size of the max stripe and one for each drive that can be connected because DMA can't have multiple writers from the same slot. That puts a layer between the drives and the controller, but that's not such a big deal.

I don't think the gate count is that high: you've got latches for the initial addresses and the stripe size, plus counters for the incrementing target addresses. When the hardware gets tough, the work can be done either in software in the driver or in software in the firmware of the card's controller.
 
mikeblas said:
Then I'm sure you can understand why I'm skeptical of your assertion that it's hard to do.
Click to expand...

Holy crap dude, do you mockingly flame everyone who disagrees with you?

I think this requires a local buffer on the card, the size of the max stripe and one for each drive that can be connected because DMA can't have multiple writers from the same slot. That puts a layer between the drives and the controller, but that's not such a big deal.
Click to expand...

Stripe size = 64K? let's do that, with 4 drives.

64K*8*24 (d-flip flop has 24 IIRC) = 12.8M transistors

so 51.2M transistors for this specific case.

Now that we've got our 4 drives, let's get our "superbuffer" another 51.2M transistors.
Or we could have logic that just changes which buffer it reads from when it's done, that would save the extra 12.8M transistors, the number of gates won't be that much.

I don't think the gate count is that high: you've got latches for the initial addresses and the stripe size, plus counters for the incrementing target addresses.
Click to expand...
Inital addresses? What is that? 1K worth of data at most for the addresses and the counters? Plus the stripesize. You're at .. 13M transistors. Plus controller logic, which I can't imagine being more than 10M transistors since this is purely a raid0 controller.

So basically you massively increase your diesize for .. what?

When the hardware gets tough, the work can be done either in software in the driver or in software in the firmware of the card's controller.
Click to expand...

So you're basically restating my point, that it's easier to do it in software than it is in hardware. If you're not doing it in hardware, then you're doing it in software, right?

EDIT: Nope, there are six NANDs, so 24 transistors. Numbers edited.
 
mwarps said:
Holy crap dude, do you mockingly flame everyone who disagrees with you?
Click to expand...
No mocking is intended. I'm just trying to get a good, solid answer.

mwarps said:
Stripe size = 64K? let's do that, with 4 drives.

64K*8*24 (d-flip flop has 24 IIRC) = 12.8M transistors
Click to expand...
Why do you need 64K flip flops? Are you counting up the memory cells and using a flip flop to implement each one? Sure, you'll need 64K of memory times four drives; 256K-byte memories are very cheap, even if you use static RAM.

mwarps said:
Inital addresses? What is that?
Click to expand...
The starting destination address of the transfer. If the driver requests that data be read to 0x12340000, then that latch holds the address. The address is moved from the latch to the counter. Then, the counter is incremented as each byte is read. The target address is the current value of the counter plus the high bits of the latch. Some of the bits inbetween can be multiplexed to provide the stepping for the four drives, since they'll naturally align to the stripe size (based on the counter width).

Since we know the address is never larger than the stripe size, we need log2(stripe_size) bits in the counter, max. 128K is 2**17, so we only need 17 flip flops in the counter. A 32-bit latch has 32 flip flops, so we've got 49 flip flops.

The cheapest FPGA that Xilinx still manufacturers has 40,000 gates on it. Without checking what macro cells are available on the chip and assuming 4 gates per flip flop, I'm using 0.1% of the available silicon on a part that costs less than ten bucks in single-unit quantities.

I think this counter is necessary even if you don't have RAID, since you've got to find the address for the next byte anyway. Perhaps the counter is built into the DMA controller; that seems perfectly feasible if DMA controllers support block transfer modes.

mwarps said:
So basically you massively increase your diesize for .. what?
Click to expand...
For implementing the RAID0 feature in hardware instead of using the host CPU for it. What was my starting die size?
 
mikeblas said:
No mocking is intended. I'm just trying to get a good, solid answer.

Why do you need 64K flip flops? Are you counting up the memory cells and using a flip flop to implement each one? Sure, you'll need 64K of memory times four drives; 256K-byte memories are very cheap, even if you use static RAM.

The starting destination address of the transfer. If the driver requests that data be read to 0x12340000, then that latch holds the address. The address is moved from the latch to the counter. Then, the counter is incremented as each byte is read. The target address is the current value of the counter plus the high bits of the latch. Some of the bits inbetween can be multiplexed to provide the stepping for the four drives, since they'll naturally align to the stripe size (based on the counter width).

Since we know the address is never larger than the stripe size, we need log2(stripe_size) bits in the counter, max. 128K is 2**17, so we only need 17 flip flops in the counter. A 32-bit latch has 32 flip flops, so we've got 49 flip flops.

The cheapest FPGA that Xilinx still manufacturers has 40,000 gates on it. Without checking what macro cells are available on the chip and assuming 4 gates per flip flop, I'm using 0.1% of the available silicon on a part that costs less than ten bucks in single-unit quantities.

I think this counter is necessary even if you don't have RAID, since you've got to find the address for the next byte anyway. Perhaps the counter is built into the DMA controller; that seems perfectly feasible if DMA controllers support block transfer modes.

For implementing the RAID0 feature in hardware instead of using the host CPU for it. What was my starting die size?
Click to expand...

Edited.

I understood what you meant when you said what the addresses were originally. When I said "what is that", I mean how big is it. My bad.

The methodology in which you are going about this is vastly different from the way that I am talking about.

I am talking about taking the P/SATA controllers, integrating them with a RAID controller and putting them on a piece of silicon, or integrating on the same board, as many manufacturers do presently.

The "simultaneous RAID" I think we'll call it, would be a part of the RAID controller's silicon chip, not some yet another extra chip on the board, it doesn't make sense to do that, as it is an integral part of the controller, and should not be separated by IO, buffers and bus.

... completely irrelevant.

The point that I am trying to make is that re-assembling the data in hardware is far more complicated than in software.

Let's take it from a man-hours perspective:

You have two buffers, or whatever you call them, data1 and data2
You write 3 lines of code in some really simple language that i made up
Code: 
ordereddata[]=findtheorderofthedata(data1,data2)
newsuperbuffer=fillthesuperbufferwith(ordereddata)
transmit(newsuperbuffer)

or if you know what order it's going to be in before hand, you can forget the ordereddata=....

That's what? 30 seconds for the coder if he knows what he's doing?

Since assuming no one's ever done it in hardware, someone has to re-design the chip (add the logic and the buffers), layout and LVS the design, get new masks made. Yes, the real estate is mainly buffers, but the actual logic itself is not just a copy/paste thing.

Now if you want to look at it from a programming/intervention standpoint only, of course it's harder in software. You have to write the 3 lines of code, whereas the hardware would just do it for you.

And really? how is

answer= operand1 + operand2 ;

more complicated than the insane numbers of interactions that have to occur in hardware to make that happen? even a simple binary adder is very complex in hardware. I'm not talking about some silly black box I plug in. I'm talking about on a transistor level. Again, I should have been more clear about that.
 
mwarps said:
SRAMs *are* d-flipflops - giant arrays of them.
D-Flipflips are made of transistors, and there are 24 transistors in each.
Click to expand...
I believe that you may be off by a factor of 4 on the number of transistors:
http://tams-www.informatik.uni-hamburg.de/applets/sram/index.html
Shows a 6-transistor SRAM cell. I understand that there is likely some control logic that is involved in addressing the SRAM cells on a chip (since we don't want 256+K pins on a chip) however, I sincerely doubt that the control logic will increase the average transistor count for each cell by a factor of 4, at least not for SRAM chips of 'appreciable' size.

additional references:
http://www.cedcc.psu.edu/khanjan/vssram.htm

Also, Ungerer et al. suggest that the number of transistors per SRAM bit be:
#ReadPorts + 2 x #WritePorts + 4

So for an SRAM bit to require 24 transistors, it would have to have many ports.
 
mwarps said:
SRAMs *are* d-flipflops - giant arrays of them.
Click to expand...
Right. But they're not going to be on-die.

mwarps said:
I am not talking about getting out an FPGA board and playing EETech.
Click to expand...
What is "EETech"?

My point of bringing up an FPGA was to show that it's not that much silicon. Implemented as an ASIC, it's still not so expensive.

What I'm talking about is: is it hard to reassemble data from a RAID0 array? You've said it is, and I want to learn why you think so.
 
drizzt81 said:
I believe that you may be off by a factor of 4 on the number of transistors:
http://tams-www.informatik.uni-hamburg.de/applets/sram/index.html
Shows a 6-transistor SRAM cell. I understand that there is likely some control logic that is involved in addressing the SRAM cells on a chip (since we don't want 256+K pins on a chip) however, I sincerely doubt that the control logic will increase the average transistor count for each cell by a factor of 4, at least not for SRAM chips of 'appreciable' size.

additional references:
http://www.cedcc.psu.edu/khanjan/vssram.htm

Also, Ungerer et al. suggest that the number of transistors per SRAM bit be:
#ReadPorts + 2 x #WritePorts + 4

So for an SRAM bit to require 24 transistors, it would have to have many ports.
Click to expand...


Gotta love the missing the forest for the trees. :rolleyes: Yeah, I was wrong there, so was Wikipedia.. I don't care, either. http://en.wikipedia.org/wiki/Flip-flop_(electronics)
 
So, being super lazy and only skimming the thread... I have the answer.

Just buy 2 VelociRaptors, Raid 0 and setup for 4 identical drives in some Raid #, to copy and parity your data from the Raptors.


Did that make sense :confused:
Back to lunch!
 
RAID0 offers theoretically double the throughput (but no improvement in seek times), which sounds like a great thing, but recall that for this to help, this really needs independent requests going on which two or more drives can handle separately. There are few situations with single-user loads where this is the case; programs don't issue much asynchronous I/O except when doing file transfer operations. This is why RAID0 gives minimal performance improvement for single-user workloads. What's worse, it can actually be slower than a single drive if there's a lot of seeking, due to overheads.

Of course, it scales really well with multi-user workloads, because then it has multiple independent requests, and this is why RAID is so good for servers. This kind of workload is not normal for most desktop PCs though.

If RAID0 made your disk access blisteringly fast but you took a reliability hit, then that would be acceptable in the right situations, but generally you're only getting small to negligible performance increases for your increased risk of failure.
 
In fact, RAID0 doesn't need multiple independent requests to provide a benefit. Requests that are a multiple of the stripe size of the volume can be serviced by multiple spindles. It usually takes more than two spindles to start overwhelming seek latency, and crummy RAID controllers don't make matters any better.
 
mdameron said:
I skimmed over those anandtech reviews... I didn't see anything regarding stripe size though.

In general, is smaller or bigger stripe size better for something like game level loading?

When would you use a larger stipe size vs a smaller? I've had two arrays. 128k and 64k. Notice no difference unfortunately between the two. Maybe a 16k next???
Click to expand...

Here are a couple helpful tests:

RAID gaming and stripe size
http://www.overclockers.com/articles1063/index02.asp

RAID and game/level loads
http://www.techwarelabs.com/articles/hardware/raid-and-gaming/index_4.shtml

It appears that stripe size can make a small difference, though probably not tangable. It also varies by game, with a stripe of about 64 probably best for most games.

The Anand reviews, and most others focus on RAID 0 arrays of only 2 drives. If you have 4 drives laying around it may be worth making a larger array, dropping load times by about a third. But then you have to live with the additional noise and heat. Also, with a 4 drive array gaming drive there should be plenty of room to short-stroke and keep the game data on the outer tracks (not done in the above review).

I just got a RAID adapter for a server I am building, but put it in my main PC to see how a 4 drive array (Raptor 150s) would effect gaming. Game and level loading is noticably faster, but not strikingly so. I suspect that as with any upgrade I have made, the improvement will be more noticable when I revert back to my original setup. At least equally noticable is the increased noise, heat, and power usage (up 50w at idle). Another consequence of this setup is that using the second PCIe slot in my 975 board downgraded my video slot to 8x. I doubt I will keep the 4 drive array when it comes time to rebuild my PC.
 
I think the problem with game level loads is that the access pattern is to random for RAID to help at all.
 
You must log in or register to reply here.
Back
Top