Slashdot Mirror
Comparison of Nine SATA RAID 5 Adapters
Robbedoeske writes "Tweakers.net has put online a comparison of nine Serial ATA RAID 5 adapters. Can the establishment counter the attack of the newcomers? Which of the contestants delivers the best performance, offers the best value for money and has the best featureset?"
TFA says nine adapters, but the graphic says eight, whoops.
Go away, or I will replace you with a very small shell script.
3ware Escalade 8506-8 is lagging far behind the competition. Moreover, it misses important features such as online capacity expansion, online RAID level migration and RAID 50 support.
http://www.tweakers.net/reviews/557/6
What they say in the article is almost damning really...
Get a free iPod Nano 4GB!
Because of this perhaps. Occasionally it helps to read an article before making comments that just make you look uninformed.
Get a free iPod Nano 4GB!
Well, cheap+reliable == linux + softraid + Enhanced Network Block Device + Enterprise Volume Management System (or LVM2). It is often faster than non-hw-raid (fake-hw controllers.
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
3ware, It's a waste of /my/ time. So I really don't
care what the tweakers think.
The 3ware cards are reliable, easy to deal
with, have brilliant drivers, good software,
and they WORK!
Always!
I have a 5 of them. I have a friend who has 40,
he agrees.
I use a 2 channel as a backup-to-sata drive, (cheaper than tape), another 2 channel in a
IIS server for payroll stuff, 1 4 channel for
a mail server and 2 8 channels for file/web.
I love'em.
Nuff said.
Moral of this story? You get what you pay for. SCSI should be used for servers.
To be fair, however, I was never able to determine if it was a result of using S-ATA, 3Ware or the linux device driver.
-- Thou hast strayed far from the path of the Avatar.
All I care about is if these are 100% raid, unlike a seemingly increasing number of cards. In windows you might do alright, but anything else, look out.
In linux you will be treating such cards as a software raid array. Kind of defeats the point of buying "hardware" in the first place.
Wankers (the manufacturers).
-- Note: If you don't agree with me, don't bother replying. I won't read it.
Sure everyone buys a few spare drives.. but make sure you buy more than one RAID card. If the RAID card goes, unless you replace it with an identical make and model, you can kiss your data goodbye.
That's what I like about software RAID on Linux - you can mount the array on another linux box if you need to.
Have yet to see a good comparison between low-end hardware RAID and Linux software RAID..
London's finest organic fairtrade coffee
I, personally, would completely avoid any card manufactured by Promise or Highpoint as I've had crap luck with them in the past. They're just not very good cards, imho. And I'm not talking about their performance in Linux. I'm talking their performance in general. They're crap by my estimation regardless of platform. After losing data on my Windows 2000 box becuase of a crappy Highpoint card, I'll never buy another.
Anyway, your assertions are not even germaine. You point to the problem with "trick-BIOS" software RAID cards, which have been around for years and are not exclusive to SATA-RAID. They are shit cards, period...have been from the day they were made. Most of the cards in this review, however, are true hardware based SATA-RAID cards.
And, again, they all are supported on Linux. 3Ware, for example, has been a bastion of Linux support for ages.
As for the whole winmodem issue, who cares? What has it to do with a freaking troll blathering incorrectly about Linux not supporting SATA-RAID cards? Besides, the fact is, winmodems are NOT real modems. They're telecom interfaces, but not modems. You need software to make them modems. And I'm not talking about driver software to give access to the cards' functions. I'm talking software that has to implement the modem functionality itself...because the modem functionality doesn't exist on the "winmodem"...because it's not really a modem. Just because we now have linmodems.org and such to provide that software, it doesn't automagically make them "real" modems.
External enclosures can be had for less than $30 and 250GB drives are under $140 each. Is your data worth $340?
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
I'm sure that me and the few drunks I've managed to hoodwink with this concept are the only market for it, but why not a USB2/1394 hub that's actually a RAID controller?
The hub could present whatever defined logical volumes to the OS as additional mass storage devices on the hub, and a configuation application would be all that was needed since the logical volumes would be presented to the OS as generic mass storage devices.
I think this could have a real market; while the bus would certainly be a limitation in performance (perhaps 1394b would help), it:
* Wouldn't require a massive case with internal bays and power taps for the drives. (S)ATA RAID is cheap, but scaling beyond 3 or 4 drives is a huge challenge in all but the biggest cases. Using external connectors like 1394/USB2 would solve this easily.
* Wouldn't require any drivers beyond existing USB/1394 generic mass storage support. Yes, you would need a special application to configure the hub's logical volumes or to perform stupid RAID tricks, but beyond that you wouldn't.
* Portability to other systems, either in the event of a host failure or, since it doesn't require drivers and once configured, it could be moved to another platform that only supported the generic mass storage device.
* OK, speed would suck, but it's about adding big, reliable mass storage with a trivial interface, not about transfer rates. The hub could actually have distinct USB/1394 channels to individual ports, since it's not really a _real_ hub and the host OS wouldn't see the individual disks, just the defined logical volumes presented as mass storage devices.
I think this would be great for "backup" applications or other small-time/home user data warehousing (keeping your native DV-AVI files, DVD backups, CD backups, MP3 backups, yadda...) Tape is nice, but SDLT or LTO drives are expensive, as are the media. For $600 you can do better than half a terrabyte of RAID-5 disk, but you need almost an entire PC to house internal disks.
Given how cheap RAID cards are, I can't believe that merging RAID into a hub would be all that expensive, especially since you're actually removing a lot of the disk control logic from the controller.
At any given point in time, your system is in one of three states:
- partially idle (there's unused CPU and disk I/O capacity),
- CPU-bound (the CPU is fully utilized but there's disk I/O bandwidth available), or
- I/O bound (the CPU has spare cycles, but the disk can't provide data fast enough to put them to use).
I suppose that a heavily overloaded system could be both CPU and I/O bound, but it would require a mix of CPU- and disk-intensive processes that isn't usually seen in practice.Let's ignore the partially idle case, in which there's ample disk and CPU to go around, as it doesn't really matter in this scenario whether the CPU or disk controller perform the XOR operations.
In the case of a CPU-bound process, you're going to incur the additional CPU overhead of the XOR operation. XOR is almost absurdly fast, particularly if the data is in the CPU's cache. I'm pretty sure that modern CPUs execute XOR on at least one byte per clock cycle. But let's say, for the sake of argument, that it takes three cycles per byte. On a CPU clocked at 3 GHz, you'd be able to perform XORs on one gigabyte of data per second if you ignore memory and cache issues. Given moderate memory bandwidth, you're also able to transfer over a gigabyte of data to or from the CPU per second. Given a more reasonable amount of data (say, one megabyte, to transfer), you'd be looking at a CPU impact of around one millisecond to perform the XOR. That's a 0.1% impact at most in a CPU-bound environment, and that's presuming you're doing a megabyte of disk I/O per second.
Now let's look at the I/O-bound case. Here, the CPU is sitting around waiting for the disk I/O to finish up. In this case, it clearly doesn't matter who's doing the XOR operations, since the CPU isn't fully utilized. PCI bus utilization is going to be increased by up to 100% (in the worst-case scenario involving drive mirroring; the worst-case RAID5 scenario is a 50% increase). A typical server's 66 MHz 64-bit PCI bus has a capacity of around 533 megabytes per second (PCI Express increases this dramatically, but let's stick with pessimistic examples for now). At the moment, a SCSI bus tops out at 320 megabytes per second, and those transfer rates are only achievable with at least four drives on the channel and an almost exclusively sequential I/O mix (the best-case numbers for a 15,000-RPM drive are about 100 megabytes/second). So there's generally bus bandwidth to spare.
You raise a number of other points in your note that are potentially issues (hot swappability, for example). But I've become convinced that the CPU/machine performance argument against software RAID really only made sense when CPUs/memory/bus bandwidth were much more constrained.