Slashdot Mirror
Linux HW and SW RAID Benchmarked
An anonymous reader writes "A Norwegian site has written up an article with various RAID solutions benchmarked using both bonnie++ and dbench. The result shows a lot of surprises, especially when comparing low end sw RAID with high end hw RAID. The text is in Norwegian but the numerous graphs are self explanatory. It does look like a few kernel drivers need a little tweaking."
This is not a very good review, they have used kernel 2.6.8, 2.6.11 has many fixes upon previous releases in regards to RAID and md (software raid) drivers.
Lets get a review that uses 2.6.11, then lets see where we are.
Hey, this is my sig, if you don't like it, STOP READING MY POSTS!
I think the real surprise for me is that SW RAID is 95% as fast as HW RAID without the pricey board, not that SW RAID is slower.
Also, another surprise is that a SATA RAID (speed) performs about as well as a SCSI RAID. Whether SATA drives are as reliable is a different matter, but with the cost savings, it is easier to have more spare drives on hand.
From a system bus bandwidth perspective, it would seem that the chief difference between HW and SW RAID would be that SW RAID requires some more housekeeping bits, the biggest one being the data from the parity drive goes over the system bus for SW, but it stays local to the RAID controller for HW.
From a CPU perspective, for SW, the CPU would have to compute the XORs rather than offloading them to the dedicated hardware, which are compute cycles and pages that could be done for other tasks in a HW setup.
For me, the speed difference is kind of moot though. If I want RAID, it would be for the redundancy and spanning multiple drives, not speed. Also, I have systems with 64/66 PCI and a system with PCI-X, so that bus isn't an issue.
Ok, this comment is uninformed as I count myself among those unable to read the article. Would also consider myself a raid amateur.
I ran some benchmarks a while ago for my own server with four 15k scsi drives softraid5d on a dual channel aic7xxx card against an Adaptec hardware raid controler with write cache and 128mb of ram. Though the hardware did take load off of the cpu, read/write performance was much better with the software raid setup and since the machine was smp, the raid overhead wasn't noticable for our application.
After doing some reading on the subject, I realized this is normal but I was surprised at how much of a speed hit we would have taken if going with a hardware solution.
SiI 3114 did really well and it is cheap.
Never mind all these other posts claiming that SCSI beats the crap out of everything else, it does not!
SCSI is bloody expensive and only marginally faster in these benchmarks. Now, unless fast disk access is the only way to improve your systems performance, you are probably better off using SiI 3114 and having many more of those.
Now that does not cover issues like hotswap support, noise, MTBF, etc...
But still it was an interresting read (albeit in Norwegian..)
TODO: 753) write sig.
A few years back I was responsible for benchmarking potential RAID solutions for a major computer company. We investigated both software based and hardware based solutions.
The conclusion we reached; software RAID gave greatly superior performance than the hardware RAID solutions available at the time, but the hardware RAID solutions had better feature sets and usability.
The superiority in performance that the software raid solutions showed was due to a quirk in what was then state-of-the-art in RAID and systems design.
Most RAID controllers at that time contained embedded Intel i960 processors running at around 100 MHz, and had caches that topped out in the 128 MB range. Meanwhile, systems contained 2-4 CPUs in the 1.2 GHz range, and 2-8 GB of memory. There was simply no way that the embedded processor and cache on the RAID card could manipulate the data as quickly as the primary system resources could, and the benchmarks showed it.
The "exception" to this performance was when RAID-5 was used. Because RAID-5 requires computational resources above and beyond simply moving data back and forth in order to calculate parity, the host-based RAID solutions couldn't always keep up.
It was the fact that RAID-5 required additional computational resources that led fairly directly to the "ROMB" (RAID on motherboard) solutions that some vendors today. The ROMB chip is often nothing more than an XOR engine, to accelerate parity calculations.
The major, major, shortcoming we found with software RAID solutions was that they did not work with our customer's software, if that software ran outside of an operating system that had drivers for the solution. With hardware RAID, the physical disks were completely abstracted away, and you could run in any possible environment and still be able to read/write from your RAID volumes.
All of the above commentary about hardware vs. software performance is meant to apply to a specific point in time. I wouldn't try to extrapolate those results to current technology without rerunning the experiments today.
Low-profile controller, connects to internal or external SCSI devices, has an Intel GC80302 processor, and supports RAID 0, 1, 5, 10, and 50.
Right?
(I'm a non-Norwegian-speaking geek, of course.)
I'm a happy RAID customer.
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
I use md so I can span PCI buses with multiple controllers to get better performance than a single HW raid card. Also, when my controller goes south I don't have to get the same controller. If I was really desperate I could use the onboard. I can upgrade my controller without backing up and restoring the array. I could get a SATA-II controller and slowly move my drives to SATA-II. I feel like I get more control with mdadm, too. At least I can inspect, alter or wipe the drive metadata while I'm up in the OS.