Sign in with
Sign up | Sign in
Your question

RAID 0 with dedicated controllor or just motherboard

Last response: in Storage
Share
November 13, 2006 8:48:23 AM

Hi,
I am considering RAID 0 for max performance. Many of today's motherborards are offering RAID support (SATA). However there are many dedicated controllers - will I get any benefit for RAID 0 (I am not considering 5 or 10) with such? What might be potential gain if any?
Regards,
Andy
November 13, 2006 9:36:36 AM

If you must go for RAID 0 - and bear in mind it doesn't give "max performance", it gives the fastest sequential transfer rate - then try to use a separate controller.

Onboard RAID 0 is basically software RAID. The calculations are done by the host CPU and take CPU cycles away from doing worthwhile work. You want a decent controller card, or any performance gains you recieve will be outweighed by the increase in CPU load.
November 13, 2006 10:13:36 AM

Thanx for the tip.
What gives max performance then if not RAID 0?
We are working with Virtual Machines on MS Virtual server that are usually 10-30 GB in size each, however with multitude of operations performed. Lot's of reads and writes. Usually one user, but many pieces of software: SQL, SharePoint, Project, CRM, BizTalk, Exchange, Office. And all of it on one machine.
Related resources
November 13, 2006 10:15:37 AM

and one more thing:
any suggestions for decent SATA controllers (2 and 4 discs)?
November 13, 2006 1:33:39 PM

>multitude of operations performed

Uh, I suspect you'd be best off with the fastest disks you could get - it'll be the latency that'll be the killer, not the transfer rate.

I would probably recommend testing it with Raptors and with 10k and 15k rpm SAS disks.
November 13, 2006 3:23:44 PM

I thought about SCSI Seagate Cheetah 15K RPM. Do you think RAID 0 would help to improve latency further?
November 14, 2006 8:02:39 AM

RAID 0 will increase the latency, not improve it.

A decent controller card will have cache on it which (depending on the cache algorithm) may make it appear to have less latency.

My strong suspicion is that RAID 0-ing the disks is more trouble than it's worth for your particular set of applications.
November 14, 2006 9:21:50 AM

i sit on the other side of the fence for this one and feel that there is an improvement using the Motherboards sata raid function my mobo is the k8n diamond nf4 which uses a dedicated chip sil3132 for its raid. now correct me if im wrong but surely this is the same as an add on card? my advice would be to try it out and if you like it stick with it. if not ditch it you wont lose anything by trying it out. all i can say tho is that i will always have a raid 0 setup for my future builds
November 14, 2006 9:54:25 AM

Any kind of RAID will increase latency.
For many simultaneous read/writes. Go for 10K RPM or 15K RPM disks.
You have just one choice if you go for SATA: WD RAPTOR.

For SCSI world, you can choose from Seagate, Hitachi or any other.

If speed's your first concern, fastest access time is the best. And it's achieved by more RPM disk can deliver.

We also work with VM's and for best price/performance we are using WD RAPTOR disks without RAID configuration.
November 14, 2006 9:56:54 AM

Yakyb - you're running a desktop machine, this is for servers.

Also, you're wrong, it *does* increase latency - it may feel faster to you but it really isn't (except in a very few tasks, such as booting windows and doing content creation). There are many articles on this topic, the usual ones to look at are from storagereview and anandtech.
November 14, 2006 2:48:00 PM

ok my mistake didnt notice the server stuff first time round i apologise

however mkaibear when did i mention it wouldnt increase latency?
i merely said there is an improvement. i move large files accross hard drives alot and raid 0 is designed for faster writing.

my advice still stands for anyone building a desktop pc (its just completely irrelevant to this topic LOL :oops:  )
November 14, 2006 8:06:28 PM

Could you explain why even RAID 0 would increase latency? Does this mean that working on VM with two or four discs in RAID 0 is slower than on one disc alone?
November 15, 2006 9:42:50 AM

You're right, you never said it would increase latency.

What I *meant* to say is "you're wrong in saying that there's an improvement, the latency will be increased and that will slow things down" - but I didn't say it very well! Sorry!
November 15, 2006 9:45:52 AM

>Could you explain why even RAID 0 would increase latency

Simply because more work has to be done before the files are read or written. If the file is less than the stripe size it's almost no added latency - it'll just be read - but if the file is more than the stripe size it'll need to be reassembled before being passed to the CPU.

>Does this mean that working on VM with two or four discs in RAID 0 is slower than on one disc alone

It depends what you're doing. In general server applications (single large databases, for example), RAID 0 will be faster. Multiple VMs with many different apps (like you said) will find that the latency increase will make the total performance slower.

Besides, you should never use RAID 0 in a server, anyway - 0+1, maybe or RAID 10, but never RAID 0.
November 18, 2006 1:36:25 PM

On board and dedicated raid is identical in performance(when onboard raid has dedicated chip). Usually the onboard has it on dedicated chip, it's rarely control by CPU. Onboard raid has limits to RAID 0 or 1 only. YES. legency increase due to access time but if you transfer large files then RAID 0 is a benefit over single. Main ppl use raid is due high capacity needs but needs fast transfer time. When using a single drive that is large like 500GB; the transfer time/rate cant beat Raid 0 and it gets worst as larger single are use. Raid 0 on 7200rpm cant beat single 10k or 15 rpm drives on access time.

Large Capacity and better transfer time better on RAID 0

Capacity is limited but better access time is on single 10k/15rpm

BEST setup is raid 0 on 10k/15rpm drives. BEST of both world.

I am srry if i write in fragments. lol
November 20, 2006 8:38:19 AM

Oh, please, you've got no idea what you're talking about.

1) Onboard RAID does not use a dedicated chip - it uses a software RAID chip that does calculations on the CPU and takes CPU cycles. You have to spend quite a bit of money to get a proper dedicated chip - a hundred+ at least (last time I looked).

2) Latency is increased due to the CPU overhead, as well as the access time. Also, if your data is spread across >1 disk you are waiting for the slowest of the 2 disks before you can get the data into the CPU.

3) RAID 0 is a little faster if you are transferring large files, or working on HD content creation. That's about it. Everything else it's the latency which is the bottleneck, not the transfer rate.

4) The faster the drive, the lower the latency. RAID 0'd 7200s will fall a long way behind a single 10k drive.

5) Best setup is not RAID 0 on 10k/15k rpm drives. The best setup is a single fast drive for time-dependant data, coupled with a RAID 0 pair of drives for any content which requires high sequential transfer rate (eg photo processing / HD content creation / certain games).
November 20, 2006 3:35:41 PM

Quote:
Oh, please, you've got no idea what you're talking about.


I'm afraid everyone has a few things to learn here, yourself included.

Quote:
1) Onboard RAID does not use a dedicated chip - it uses a software RAID chip that does calculations on the CPU and takes CPU cycles. You have to spend quite a bit of money to get a proper dedicated chip - a hundred+ at least (last time I looked).


That is not true. Most on-board RAID implementations use a dedicated controller. But controllers vary in power and performance. The typical on-board controller (take for example, the Intel ICR7R or 8R) performs all RAID functions on the dedicated chip, even though the chip has little processing power for this task. But, whether that will slow performance is dependent on several things.

First, the calculations that your speaking of are the parity generation computations, which are intensive. However, those are only done in RAID setups that use parity for redundancy, i.e. RAID-5. RAID-0 and RAID-1 do not need any such calculations, thus a low-powered controller like the ICH7R or 8R works perfectly, with no performance decrease over a stand-alone high-powered controller when used in RAID-0 ot RAID-1.

In fact, sometimes the dedicated controller can come out ahead due to other factors. For instance, the interface. The Intel ICH7R/8R is the south bridge chip, and is connected to the north bridge (MCH) by their dedicated high-speed interconnect. A RAID-0 pair of drives on an ICH7R can easily sustain transfer rates of 150 MB/sec with a 2-drive RAID-0 (this is essentially the speed of each drive added together). A stand-alone controller in a PCI slot is limited by the PCI bus bandwidth, and can only sustain about 90-110 MB/sec in the same setup.

The Intel ICH7R/8R will do RAID-5, but the driver uses the CPU to perform the parity calculations. This weakens RAID-5 performance considerably. The dedicated controller in this instance will defintely lose out to a stand-alone, high-powered controller.

Quote:
2) Latency is increased due to the CPU overhead, as well as the access time. Also, if your data is spread across >1 disk you are waiting for the slowest of the 2 disks before you can get the data into the CPU.


In both cases here that you're speaking of (CPU/RAID driver overhead, and waiting for the slowest disc), the additional latency is on the order of microseconds. Since the rotational and seek latency of the drives is on the order of milliseconds (1000 x longer), the additional latency from these two factors is irrelevant.

The "waiting for the slowest disc" additional latency is somewhat of a misnomer anyway. If disc A's latency is 4.5 msec, and disc B's latency is 4.55 msec (due to manufacturing tolerances), then the array runs at 4.55 msec latency, which is the same latency you would have if you used disc B alone. Also, (assuming you have matched drives), the differences in the two drives' latency are going to be very tiny, if even measurable. If the discs have the same sector layout and the same rotational speed (within a few RPM), again that difference in latency is on the order of microseconds.

In another note on latency, there are some dedicated controllers that have a large amount of cache (256MB is becoming common). If the cache algorithms are good, the controller can predictively determine what sectors on the drive will be requested next. Even if the algorithm is only right 20% of the time, getting 20% of the sectors from cache memory rather than the drives decreases overall latency by 20%. Taking latency of the array from 5 msec to 4 msec is very significant. That 256MB of cache far exceeds the 8MB or 16MB in the drives, and allows much better cache hit rates.

Quote:
3) RAID 0 is a little faster if you are transferring large files, or working on HD content creation. That's about it. Everything else it's the latency which is the bottleneck, not the transfer rate.


In terms of transfer rate, RAID-0 is not a little faster, it's twice as fast. If I can normally get a file off the disc at 70 MB/sec, the 2 drive RAID-0 will get the same file off the disc at 140 MB/sec, provided there is no other bottleneck like PCI bus bandwidth. Also, of course, the file has to be a certain size to realize the benefits. Obviously, files smaller than the RAID-0 stripe size are not helped at all, and because of the disk system overhead as a whole, the file needs to be larger than a certain size to realize the transfer rate benefit (generally bigger than 1-2 MB, being read contiguously, will see at least some benefit, provided the file isn't fragmented). The RAID-0 approaches its double-transfer-rate potential when working with extremely large files, like Photoshop cache, video editing applications, and DVD mastering.

RAID-0 does not improve latency as we've already covered except in the case of large caches. Nor does it improve IOP (I/O's per second), which translates into little help for applications and files that do many small transactions like databases. (Exception: if the entire database file is contigous and can fit in cache, then IOPs can go up). Note that when I'm speaking of a database file, that's more that just the classic SQL server. Many Microsoft (and other) programs use the built-in "lite" database of Windows XP called JET. Microsoft Outlook's .pst file uses it, and the .pst file is accessed like a database would be. Many applications fall into this category.

Quote:
4) The faster the drive, the lower the latency. RAID 0'd 7200s will fall a long way behind a single 10k drive.


Definitely true, rotational latency goes down as the RPM goes up. 10K drives are better than 7200, 15K drives are better than 10K. Cost goes up as well, of course.

Quote:
5) Best setup is not RAID 0 on 10k/15k rpm drives. The best setup is a single fast drive for time-dependant data, coupled with a RAID 0 pair of drives for any content which requires high sequential transfer rate (eg photo processing / HD content creation / certain games).


The "best setup" is highly dependent on what you're doing, and what you're going to design the machine around. I have a dedicated workstation at work that does DVD mastering. I set it up with two independent 2-drive RAID-0s. I have the DVD assets (.m2v files, .ac3 files, etc.) on one RAID-0, and compile the DVD to the second RAID-0. I can get a DVD compiled to an .iso file in half the time it takes me on two single drives, and well under 20% of the time it takes on one single drive.

That setup is definitely the "best" setup (within reason) that I can get on that machine. Again, it totally depends on what you're going to do with the machine that dictates the best hardware setup.
November 21, 2006 6:58:51 AM

>whole bunch of stuff claiming onboard RAID is hardware RAID and not software RAID

Onboard RAID *is* software RAID. It doesn't have a proper hardware implementation of the RAID algorithms, it does it in software and hence is substantially slower than a properly developed hardware RAID.

Proper hardware RAID cards are *expensive* for this reason.

>Additional latency is on the order of microseconds

Uh, I think you misunderstood me.

>waiting for the slowest disk additional latency.

I'm not talking about the variance in manufacturing, I'm talking about the fact that if you've got two disks with a latency of 5ms, that's an *average* latency. They could take anything between effectively 0ms (if the data is right under the read head at the time of requesting it) and approximately 10ms.

If you've got two disks you've got double the chance that one of them is going to have a latency closer to 10ms than 0ms.

In a purely simplistic format, consider the following example;

You have 1 disk, it has a 50% chance of having a latency of 0ms and a 50% chance of having a latency of 10ms.

The average latency is 5ms. (I'm sure I don't need to do the maths).

You have 2 disks, each has a 50% chance of having a latency of 0ms and a 50% chance of having a latency of 10ms.

If RAIDed, you have a 25% chance of having a latency of 0ms, and a 75% chance of having a latency of 10ms.

(draw the truth table if you don't believe me :) )

The average latency thus increases to 7.5ms.


As I say, it's a very simplistic example, but that's one of the reasons that RAID subsystems tend to have a higher latency than single disks. They have other advantages, such as content creation (like the stuff you are talking about at the end of the post), but for general desktop use they will slow the machine down.


I think that basically we're arguing the same point, which is that RAID is good in some applications, fast single disks are better in others.

You're also missing the point that when I made the comment about the "best setup", I was referring to what the OP wanted - which is a system running multiple VMs doing a whole range of different things. A fast single disk for boot and general application stuff with a decent RAID 0 array for the databases is probably his best option.
November 21, 2006 5:25:56 PM

OK, well we have several items here, I'll discuss them one at a time.

Quote:
Onboard RAID *is* software RAID. It doesn't have a proper hardware implementation of the RAID algorithms, it does it in software and hence is substantially slower than a properly developed hardware RAID.


OK, first I want to define what makes something a "RAID". i.e. what operation is it that gets performed that makes a RAID array? The primary thing that a RAID does is it takes physical disks and groups them together into a logical disk. For example, if you have a 4-drive RAID-0, there are 4 physical disks connected to the machine, but the end user will see only one logical disk. To me, the place where the physical->logical translation is done defines whether that RAID array has been implemented in software or hardware. (For the RAID-0 or RAID-1 case).

In both add-on RAID cards and dedicated on-board RAID controllers, the chip (be it a Silicon Image, an Intel ICHxR, or an nVidia nForce) is what does the physical->logical mapping. The chip is responsible for receiving a read/write command from the driver that wants to read/write a block of data to the single logical disk and splits it into multiple reads/writes to multiple physical disks. To me, since the chip is performing this operation, this is hardware RAID in the RAID-0 or RAID-1 case.

In the RAID-5 case, it is much different. For RAID-5 I define the difference as the location where the XOR computation gets performed, since that is highly important in terms of performance. If the XOR operation (for computing the parity information) gets performed on the RAID controller chip, then it's hardware RAID. If the driver performs the XOR computation on the main CPU, then it's software RAID.

One of the things you keep referring to is that "onboard RAID doesn't have the proper hardware implementation of the RAID algorithms." That's generally true for RAID-5. But there is no algorithm that has to be run for RAID-0 or RAID-1. The only operation required is to split up the reads/writes to the physical drives, which is a trivial operation, requiring virtually no processing power at all. This is why you see no difference in performance for RAID-0 and RAID-1 when comparing an onboard RAID chip and a stand-alone RAID card.

Quote:
I'm not talking about the variance in manufacturing, I'm talking about the fact that if you've got two disks with a latency of 5ms, that's an *average* latency. They could take anything between effectively 0ms (if the data is right under the read head at the time of requesting it) and approximately 10ms. If you've got two disks you've got double the chance that one of them is going to have a latency closer to 10ms than 0ms.


This is an interesting subtopic. I'll admit, I did misunderstand what you were referring to. But let's look at this closer and I think you'll see that the conclusion is not so simple.

Remember that we want to attempt to characterize the difference in latency for the comparison of a single drive and a RAID-0.

First, there are two different types of latency encountered in the hard drive. The first is seek latency, which is the time to move the head from the current cylinder to the desired cylinder. This is about half of the total latency in modern drives, and can be anywhere from 0 msec to around 8 msec.

The RAID controller's operation ensures that no additional latency will come from this source during operation when compared to a single drive. The way it does this is because the virtual mapping of the logical disk's sectors to the physical disks' sectors ensures that all read/write heads on all drives are always at the same cylinder. For example, on a 2-drive RAID-0, if the operating system has requested a read of sectors 1000-1001 on the logical disk, the RAID controller translates this into a read of sector 500 from disk A and a read of sector 500 from disk B. Those sectors are on the same cylinder of each drive. This will be the case for all reads and writes to the array. Thus, the heads on all drives will always be at the same cylinder position. If drive A is going to take 3 msec to seek to the desired cylinder, so will drive B, because their heads started out at the same position and will end at the same position. Thus, seek latency will never cause one drive to lag behind the other.

The second latency encountered is rotational latency. This is the time that, once the head is positioned at the correct cylinder, it takes for the desired sector to rotate under the read/write head. This is a function of the rotational spin of the hard drive. 7200 RPM = 8.33 msec per rotation, 10000 RPM = 6 msec per rotation, 15000 RPM = 4 msec per rotation. In any instance, the sector could take between 0 msec and the full rotational time period to arrive under the read/write head.

This is where the RAID controller has to be creative. Since most RAID controllers do not synchronize the hard drive spindles, there can definitely be a difference in rotational latency between the two drives. Drive A may get to it's sector before drive B, or drive B may get to it's sector before drive A.

But no one says that the sectors must be read from the drives in order. Any modern RAID controller will read whatever sector becomes available first from any drive in the array, cache it, and wait on the other sectors from the other drives, assemble them together in the RAID chip's memory, and send them back to the driver.

Now, if sector reads/writes were perfectly interleaved like that, we would indeed have a problem, as the controller would always be waiting for the disk with the longest latency, which would increase the overall average latency, as your explanation shows. (And this is why RAID-3, which interleaves data at the byte or bit level, requires spindle-synchronized drives). However, the RAID-0 has a stripe size associated with it (generally 64K for modern controllers). That means that any request for less than 64K of data will only go to one drive. Thus reads/writes <64K incur no additional latency penalty over a single drive.

For reads/writes larger than 64K, where both drives in a 2-drive RAID-0 would be used, you can actually save time. Let's do a worst-case 128K read from a 2-drive RAID-0 and a best-case 128K read from a single drive and compare the (ideal) required times. In both cases we will ignore seek latency since it will average to be the same for both the single-drive and RAID case.

For the best-case 128K read from a single 7200RPM drive: 0 msec rotational latency. 128K = 256 sectors. At 63 sectors per track, this is 256/63 = 4 whole tracks + 4 sectors on a 5th track. Assuming a 2-platter/4 head hard drive, this requires 4.06 rotations of the platters, plus a 1-cylinder seek. Rotation time = 8.33 msec, seek for 1 cyl ~ 0.5 msec. 4.06 * 8.33 + 0.5 = 34.3 msec to read the data.

For the worst-case 128K read from 2x 7200 RPM RAID-0: any rotational latency on disk A (doesn't matter), 8.33 msec rotational latency on disk B. I only need to read 64K from each drive however. For drive A: need to read 128 sectors = 2.03 rotations of the platters, and while it's possible that won't require a 1-cylinder seek, I'll assume it does. 2.03 * 8.33 + 0.5 = 17.4 msec. Drive B is the same time to read it's 64K of data plus it's aforementioned 8.33 msec rotational latency = 17.4 + 8.33 = 25.7 msec. Since the interleave of the read data in the controller is almost instantaneous by comparison, the controller will have all the data ready to send back to the computer when disk B completes it's read, and that only took 25.7 msec, a full 8.6 msec faster than the single-disk case.

Now, somewhere between 64K reads and this example of 128K reads is a range of read sizes where the RAID does take longer due to the rotational latency. To compute how much that affects the overall speed, we would have to know the histogram of the distribution of read sizes that the operating system is calling for, which is variable and unpredictable. But suffice to say that for <64K reads, we have no latency penalty over a single drive, and for >=128K reads we actually have a latency advantage over a single drive with a 2-drive RAID-0.

(Note: The previous example was assuming 63 sectors per track. I believe that modern hard drives don't correspond to this older geometry figure, and probably have a higher number of sectors per track. This doesn't invalidate the analysis, but it makes the window of read sizes where the RAID-0 is at a disadvantage larger).

Quote:
You're also missing the point that when I made the comment about the "best setup", I was referring to what the OP wanted - which is a system running multiple VMs doing a whole range of different things. A fast single disk for boot and general application stuff with a decent RAID 0 array for the databases is probably his best option.


There are a variety of ways to set up that system depending on how much money is available and how important any achieved speed-up is. A fast single drive for boot and a RAID-0 for the databases as you have stated is indeed a compelling option. However, there are other possibilities. A RAID-10 could work even faster and gives actual redundancy as well. Moving from SATA to an SAS RAID card with 15K RPM drives would obviously increase the speed even more. Any RAID card used that has larger cache would also improve things, especially since the onboard RAID solution probably has no cache.

I agree I think we're hashing some of the same opinions here - in that RAID is not always what it's cracked up to be, it's not the end-all-be-all, and has to be carefully selected to increase the performance of the system, which is dependent on what the system is doing.
a b V Motherboard
a b G Storage
November 21, 2006 6:49:28 PM

Quote:
and one more thing:
any suggestions for decent SATA controllers (2 and 4 discs)?


Check these out:
Areca ARC-1210
Promise Supertrack EX8350
3Ware 9590SE

Out of these three, I would recommend the Areca or the 3Ware. I've have used 3Ware, excellent controllers. Areca is also good and more reasonably priced.

Good luck!
November 21, 2006 7:21:30 PM

Quote:
... in that RAID is not always what it's cracked up to be, it's not the end-all-be-all, and has to be carefully selected to increase the performance of the system, which is dependent on what the system is doing.

How come no one every mentions the reasons that ultimately convinced me that RAID 0 is the "less special" way (for me) to go on a general purpose desktop? My reasons are not nearly so technical as the previous posts.

With RAID 0 you can easily end up with a really big logical drive. So big, in fact, that you have no way to back it up. And then one day you realize one of the RAID drives is going to fail because you can hear it doing the "click of death", so you've got to back it up. Now!

I think of it as the "between a rock and hard place" RAID-0 dilemma. :wink:

On a side note, it would have been nice to be able to look at the SMART info for the drives to determine which one was near death. But of course when you go RAID you can't look at SMART info any longer. Another aspect of RAID I hated.

Thanks to advances in hard drive capacity I eventually was able to buy a hard drive big enough to let me migrate the data and dismantle the RAID. But for a while there I definitely felt "trapped". I can assure you I'm not thinking about going to that place again any time soon.

-john
November 23, 2006 6:29:06 AM

Lots of good information here...

However, let us not forget what RAID is or what its ultimate purpose is for and that is redundancy.

Sure there is RAID 0, but should it really be considered RAID?

The "big cracked up" part of RAID is that it can offer far more protection against lost data then any single drive. Wasn't that it's purpose to begin with?
!