by Nikita Nikolaichev
07/27/2003 | 11:16 PM
SerialATA Interface stalks along as if it were the second-year soldier. The time of press-releases has come to an end and real controller cards from numerous manufacturers have already got to the stores. In order to help you find your way in this diverse variety of SATA RAID controllers, we decided to undertake a brief express-testing.
<%BANNER[article]%>Of course, among our testing participants will be the solutions from Promise and HighPoint. Could you imagine a roundup without them? Of course not!
However, now there are quite many newcomers in this market. Take Intel Company, for instance. They integrated a RAID controller into their chipset South Bridge. This innocent prank at first glance, can change the situation in the low-cost RAID controllers market really drastically. First, since RAID controller is integrated into the chipset, the necessity to buy an external RAID solution will not be evident for the user: he already has one controller, why buy another one?
Secondly, Intel is not going to remain the only developer and manufacturer of chipsets equipped with an integrated RAID controller. Very soon all chipset guys will be ready to boast the same cool feature. As a result, the prices of external add-on RAID controller cards will crash and the products will either disappear or will be pushed to a more expensive market segment, which is currently occupied SCSI RAID controllers for workstations. All in all, hard times are coming...
The only thing that makes me happy, is that I will still have a lot to work on :)
Well, let me list all SATA RAID controllers, which are going to participate in our today’s test session. If we do it in alphabetical order, the first one will be a solution from 3ware.
Although this is formally a four-channel controller, I considered it possible to include it in this roundup, to express my deepest respect towards the company, which does know how to make RAID controllers.
The controller is designed as a PCI64/33 card of half-length. The PCB is equipped with quite many chips, which makes it stand out among our today’s testing participants. To tell the truth, it doesn’t make much sense to go into details about this card, because it is none other but a slightly revised card from 3ware 7500 product family. The only innovation it boasts compared with the predecessors is ATA-to-SATA converters (Marvel 88i8030). If you are looking for more detailed coverage on 3ware 7850 controller and its performance please check our 3ware Escalade 7850 Controller Review.
I managed to get a retail version of 3ware controller (in other words, a boxed version):
Inside this box I found everything necessary: drivers, a set of SATA-cables, and the most important thing – the controller card.
Adaptec 1210SA controller card is designed as a low-profile PCI 32/66MHz card:
As you see, the PCB carries a Silicon Image 3112 chip, which we all know very well since the times we tested Seagate Barracuda SATA V (see our Seagate Barracuda Serial ATA V Hard Disk Drive Review) and WD Raptor (see our article called WD Raptor: First ATA Hard Disk Drive with 10,000rpm Speed). Since Sil3112 chip is a PCI-to-SATA controller, the RAID function on this chip is a typical firmware RAID, i.e. is implemented on the software level.
The next controller on our list represents a new word in RAID-designs. It is the first time that a RAID controller is integrated into the chipset South Bridge. Intel was the one who appeared brave enough to undertake this attempt and we have to admit that this company really deserves its title of the PC-industry leader. Although it took our flagman quite a bit of time, before they finally implemented SATA-HDDs support in their chipsets. When we asked the hard disk drives manufacturers when they were going to start producing mass quantities of SerialATA HDDs, the answer was the same for all of them: when Intel introduces a chipset with SATA support. Of course, only if there were a chipset for the most widely spread processor (read: Socket478 Pentium 4), the HDD makers could hope to have the SATA HDDs sales grow up to the level that would make them happy.
It is interesting that unlike other controller we are going to review today, the SATA RAID controller implemented in ICH5-R used to support only one RAID array type until recently: RAID 0! The RAID 1 support has been introduced only recently, however, it happened exactly after I finished writing two passages about Intel and their inability to understand the users’ needs. Even though now all my above described complaints about Intel are not worth a penny, I couldn’t kill the freshly written text with my own hands :)
It is really hard to say why there is no RAID 1 support. The importance of this RAID array type support is so evident, that I really don’t think I should talk more about it. But I have to!
The growing demand for hard disk drives aroused really cut-throat competition among the manufacturers. And the growing competition resulted into lowering of HDD prices. Lower prices imply that each hard disk drive sold brings in less profit. Trying to keep the profits norm up, the manufacturers started looking for possible ways of reducing the production costs: simpler HDD construction, moving the production lines to the countries with cheap (read: less qualified) labor, reducing the warranty period. Unfortunately, the increased HDD production volumes together with the measures aimed at lowering the production costs couldn’t help telling on the HDDs quality. And in these hard days the only remedy, which can ensure that you don’t lose all your dear data one day is the use of RAID 1 arrays. Keeping in mind everything I have just said, I consider the introduction of an integrated RAID controller (no matter if it is a software solution or not) without RAID 1 support to be a clear mockery. I am not that naïve to believe that RAID 1 support is much harder to implement than RAID 0. But even if we assume that this supposition makes sense, we will have to admit that Intel’s engineers and software developers are less competent than the employees of other RAID controller-making companies. Hard to believe...
Well, all’s well that ends well. The ICH5-R South Bridge now supports RAID 1, however, we are not going to dwell on the performance of this array type in this particular article :)
Returning back to the distinguishing features of the RAID controller integrated into the ICH5-R South Bridge we can’t help mentioning one very important detail. Intel’s engineers took advantage of their position and connected the controller directly to the chipset South Bridge, instead of the PCI bus. This way, the maximum data transfer rate of the controller doesn’t depend at all on the PCI 32/33MHz bus, which theoretical bandwidth is equal to only 133MB/sec. the North and South Bridges of the chipset are connected with one another via the Hub-Link bus with the bandwidth of 266MB/sec. And even though there are other devices implemented in the South Bridge besides the RAID controller, which also tend to use some of this bandwidth, the RAID controller should feel much better, than incase it were connected to the PCI bus. In fact, we are going to connect all other RAID controllers to the PCI bus today :)
The controller card from Promise can be easily recognized even without any marking: the PCB color is distinguishing:
However, what do we see between the two SATA connectors? This is the good old Parallel ATA connector!
Yes, Promise offers such a hybrid, which should become a handy solution for easier transition from PATA to SATA drives. In fact, this seems to be a great idea: you can keep your old drives with Parallel ATA interface and even unite them into a RAID 0 array (unfortunately, you will not be able to build a RAID 1 array).
We received the HighPoint RocketRAID 1520 controller thanks to our sponsor ATACOM Company. The controller was packed in a nice-looking colorful box:
Inside the box we found a set of pretty standard things: a user’s manual, a disk with the drivers and two SATA-cables.
Just like 3ware controller, HighPoint RocketRAID 1520 is not a native SATA controller. As you can clearly see from the picture above (especially if you click to view a large picture), it is based on HPT372 chip all of you are already familiar with (see our HighPoint RocketRAID133 Controller Review). As you can also notice the work with SATA hard disk drives is carried out via the Marvel 88i8030 bridges. It is hard to say whether this is good or not, whether the converters have had any negative effect on the performance. As we will see later in this article, the major problem of this controller is connected not with the converters…
The second controller-on-a-chip, which will participate in our test session, is Sil3112 – a reference controller from SiliconImage!
If you looked at the pictures attentively enough, you have already recognized the controller, which participated in all our tests of SerialATA hard disk drives. It is SiI CP3112SATA150. Although CP3112SATA150 is just a SATA controller, but not a RAID controller, it is not a problem. It appeared very easy to change into a RAID controller :)
As I have already mentioned in the beginning, the RAID function on SiliconImage controller is implemented via software that is why if you want to convert the controller type, all you need to do is to reflash the BIOS and install the appropriate drivers.
Since we are going to compare mostly dual-channel SATA-RAID controllers (i.e. the simplest ones, or “desktop” ones, if we can say so), we selected workstation hard disk drives: two SATA drives from Seagate – Seagate Barracuda SATA V 120GB (ST3120023AS). The second secret motive guiding our decision to take these particular drives was my vital desire to check if SATA drives from Seagate could work well in RAID 0 arrays. As you remember, we have already had a confusing situation with Seagate HDDs (see our article called Seagate Barracuda ATA IV in RAID 0: Truth and Fiction).
Well, it’s high time we introduced our testing methodology to you.
Since there is a “chipset” SATA-RAID controller from Intel among our testing participants, and it can be only tested if there is an i865.i875 based mainboard, we had to completely change our testbed configuration, so that all controllers could be tested in equal conditions.
As a result, our testbed looked as follows:
We used the following benchmarking software:
* - we had to shift to a new Intel IOMeter test version, because version 1999.10.20, which we have been using all this time doesn’t work correctly with the CPUs supporting more than 2GHz core clock rate. At first glance, the use of newer benchmark version didn’t push the HDDs to work faster, but the CPU utilization measured by the test got considerably lower.
Before the tests the AAM register of all HDDs was set to OFF position (FAST mode) with the help of Hitachi Feature Tool Utility (the AAM register of the drives was switched with HighPoint controller installed, because with all other controllers the utility didn’t see the drives at all.
For WinBench tests all the drives were formatted in FAT32 and NTFS as one logical drive with the default cluster (to format the drives in FAT32 we used Paragon Partition Manager utility). For FC-Test the arrays was split into two logical drives of the same size.
The tests were run seven times each, the maximum result was taken for the diagrams. The drives didn't cool down between the tests. The tests in Intel IOMeter were run in SequentialRead, SequentialWrite, DataBase, WorkStation, FileServer and WebServer patterns. If you are looking for the detailed description of these patterns, please, see our previous articles.
For some controllers we took the results twice: promise controller was tested with two variants of possible caching settings: Write Back/Write Through (see the details in our Seagate Barracuda Serial ATA V Hard Disk Drive Review). And as for HighPoint controller, we had to test it twice for a totally unusual reason. The thing is that this controller performed really slowly with the 2.34s driver, and I decided to return to the previous driver version 2.33s. You will see what has come out of it very soon.
The controllers were tested with the following BIOS/driver versions:
The IOMeter program sends to the array a stream of read/write requests 4-requests deep. Once a minute the data block size in this test changes, so that in the end we get the dependence of the linear read and write speeds on the data block size.
For easier results analysis I split the controllers into two groups. The first group includes the controllers from 3ware, SiliconImage, Intel and Adaptec:
As you see, the controller performed very closely to one another. It is hard to single out a leader in this group, however, SiliconImage controller proved much more impressive than the rivals when working with small data blocks.
In the second group we will witness the battle between two eternal rivals: Promise and HighPoint. As I have already mentioned above, Promise controller was tested in two modes (WT and WB), and HighPoint controller - with two different driver versions.
What a curious picture, don’t you think so? If the graphs corresponding to the Promise controller performance hardly look surprising to us (as you remember, we have already discussed the performance of these controller with various caching driver settings in three previous articles), then the HighPoint controller really stood out. With 2.34s driver the controller was awfully slow, however, with the 2.33s driver the situation luckily came to back to norm and the controller performed more or less OK.
Note that the drivers of these two controllers sometimes cause significant drops of the linear read speed for data blocks of a certain size. These “bad” data blocks equal 8KB for Promise controller and 32KB for HighPoint.
I wonder what will happen during writes.
And during writes the testing participants no longer march neck and neck :)
Two controller based on SiliconImage Sil3112 chips fell out, because they lose speed when working with 8KB data blocks. It looks as if the controller drivers were trying to undertake something to optimize the controller work with 8KB data blocks. However, in case of sequential write there is nothing to optimize, as the data flows in a stream anyway...
The controller integrated into Intel ICH5-R proved pretty successful in this test: its performance with 8KB data blocks is really impressive. However, the performance of Promise controller in WB mode is beyond any competition: impressive!
Promise controller drivers in WB mode enlarge the write requests size, which has a definite positive effect on the performance. However, we shouldn’t forget that enormous CPU utilization is the price we have to pay back for the high speed.
So, in Sequential Read and Write patterns the best result belongs to Promise controller, and the most disappointing result unfortunately was shown by HighPoint RocketRAID 1520 with the latest 2.34s driver.
In this pattern we are going to test the controllers’ ability to work with a mixed stream of: read and write requests for 8KB data blocks with random address. By varying the reads-to-writes share in this data stream we can figure out how efficiently the controller driver can sort out different types of requests for more optimal further processing.
Hm.. What a big table. For your convenience I provide the selected results on the diagrams. Have a look:
To tell the truth, it is pretty hard to understand something in this rainbow :) I can only say that Adaptec controller falls quite noticeably behind the competitors when working with a big share of writes. It is remarkable that two controllers based on the same chip showed the best (SiliconImage) and the worst (Adaptec) results under linear workload in this test.
Now let’s increase the queue depth and see if it gives the controllers a chance to stand out somehow.
Well, this seems to have worked: now we can name the three leaders. They are SiliconImage, which proved the best, 3ware, which yields a little bit to the leader in RandomRead and RandomWrite modes, and Adaptec, which performance is very sensitive to the writes share.
As for the diagram with 256 requests queue depth, I decided not to give it here, because it is very hard to read, even harder than the diagram for queue=16.
Instead, I suggest that you take a look at the three tables (click to open), where the best and worst results for all three types of workload are marked in color:
Summing up the performance of our testing participants in DataBase pattern we can single our 3ware and SiliconImage controllers, which managed to defeat all the other competitors.
Now let’s check how successful these controllers will prove in applications emulating the work of the server disk subsystem.
We will use a rating system to compare the controllers with one another. The total score will be calculated as average controller performance under all types of workload.
Well, SiliconImage controller coped best of all with the server workload. The second fastest is 3ware controller. In fact, these results almost exactly repeat the picture we have just seen in DataBase pattern, with that only difference that the third position is occupied by Intel controller, which was not among the best in DataBase pattern.
And in WebServer pattern the integrated Intel’s controller managed to become the No.1 having outpaced both: SiliconImage and 3ware. And that’s the chipset controller for desktop PCs, can you believe it?!
Of course, Intel’s controller is in a bit more advantageous situation here, because it can communicate with the chipset North Bridge (read: with the memory) directly, while all other controllers have to use the PCI bus. However, since we haven’t revealed any evident advantage of the Intel controller over the competitors in Sequential Read tests, we assume that its success under server workload is most likely to be connected with the driver peculiarities, and not with the way this controller works with the memory.
Well, the argument in favor of the above mentioned supposition is right here, in the WorkStation pattern results. This typical distinguishing feature of this pattern id a big share of write requests, which has affected the situation among the racers a lot.
The rating for the WorkStation pattern can be calculated with the following formula:
Performance = Total I/O (queue=1)/1 + Total I/O (queue=2)/2 + Total I/O (queue=4)/4 + Total I/O (queue=8)/8 + Total I/O (queue=16)/16 + Total I/O (queue=32)/32
Note that Intel’s controller, which was ahead of all in WebServer pattern and showed the third best result in FileServer pattern occupied the very last position in WorkStation pattern. To tell the truth, I was slightly puzzled with this result: Intel’s controller for desktop PCs works excellently well in server applications, but is shamefully behind in a pattern emulating the work of a desktop disk subsystem :)
At the same time, the two most successful controllers, which have already shown the bets results in all previous tests, namely 3ware 8500-4 and SiliconImage proved impeccable here, too.
As usual, we use the WinBench test to see how efficient the hard disk drives and HDD arrays are for desktop needs (this is not the only test we use, anyway).
Just in case, I would like to remind you that we used two Seagate ST3120023AS HDDs with the total storage capacity of 240GB to create a single logical drive of this size. Then we formatted it for NTFS with the help of the operation system utilities with the 4KB default cluster, and for FAT32 formatting we used Paragon Partition Manager Utility.
Let’s start with NTFS:
You have just seen all the results. For easier analysis we would like to pay special attention to two integral tests: Business Disk WinMark and High-End Disk WinMark.
As you see, HighPoint (2.33s) and Promise (WB) controllers boast a pretty big advantage over the other testing participants in High-End Disk WinMark, and in Business Disk WinMark the leading position is occupied by HighPoint controller with different driver versions.
At the same time, the solution from 3ware, which has proven very successful in all low-level tests, is surprisingly slow...
According to the linear read speed in the beginning and in the end of the logical drive our controllers got positioned as follows:
You can see the graphs if you click on the corresponding link below:
I strongly recommend taking a look at the linear read graph for HPT RR1520 controller tested with 2.34s driver version.
The Average Access Time results are given in a separate diagram for your convenience:
Of course, those controllers, which drives have to do some additional things to each request before processing it during random reads, do a lot of useless work. In other words, they fail to speed up the work of the array (because the requests go to sectors with random address), and at the same time spend time on requests processing anyway.
Now we will take a look at FAT32 file system and the performance of our testing participants there:
As we see, nothing has changed: the first one is still HighPoint with 2.33s driver and the other controllers perform almost equally fast.
Attention: today we are going to try our FC-Test not for HDDs testing but for the performance check of RAID controllers. The most interesting thing here is that our colleagues from tech-report.com web-site have already used our test for RAID-controllers comparison (you can check their article here).
But back to our roundup. So, we tried to use the standard FC-Test methodology. We created two logical drives of the same storage capacity on a hard disk drive (in our case on a HDD array). These logical drives were formatted for FAT32 and for NTFS. Then we created a set of files on one disk, read it from the disk, copied into a directory created on the first logical drive (i.e. we performed a copy operation within one partition), and in conclusion, we copied this set of files onto the second logical drive. The new 0.5.3 version of our FC-Test is a little different from the previous 0.3 one. The new build has archiving emulation; for each operation it reports not only the time spent, but also the average speed (as we know the size of all pattern files). All in all, it has now become much more interesting and convenient to work with this test :)
The obtained results turned out really exciting:
In each line the red color indicates the worst results, while the blue color – the best. We can clearly see that the optimization of the lazy write performed by the Promise controller in WB mode speeds up file creation so greatly, that Promise becomes an indisputable leader. However, during reads Promise driver in WB mode slows down the controller performance: in WT mode it performs much better.
Note that SiliconImage controller reached 88MB/sec when reading the files from the ISO pattern, which is the double read speed from the single Seagate Barracuda ATA V HDD! This way, I believe there are no more questions about the work of Seagate hard disk drives in RAID arrays: they do work.
There is one more very curious fact: Intel’s controller three times outperformed all the others in MP3 pattern. Either Intel software developers like this music format very much, or the slogan about Intel CPUs being the center of your digital universe has now been introduced into chipsets too.
Not very high performance of the 3ware controller during files creation is probably caused by the fact that this controlelr, as well as Promise, works in WB mode. Here, however, the WB mode is implemented on the hardware level, and not via software, because 3ware controller is the only one among all testing participants, which can boast onboard cache-memory.
In FAT32 we see almost the same situation: Promise controller in WB mode was faster than the rivals in most cases, and HighPoint with 2.34s drivers was very often the last one.
I hope that there are no optimizations yet for FC-test that is why when you decide on a controller for your home system, you could surely use the results we have just discussed. Anyway, there is no more real test yet.
Well, the results we obtained during our comparison of SATA-RAID controllers performance, I can conclude that there is no indisputable leader among them. SiliconImage controller proved very fast in synthetic benchmarks, HighPoint controller showed its best in WinBench (with 2.33s drivers) and Promise (WB) controller performed excellently well in copy tests.
3ware controller was very rarely among the leaders, however, it stayed among the three fastest almost all the time. Of course, we have to reward this stability with the “most balanced drivers award”. By the way, 3ware controller could theoretically perform even better, if the new 7.6 drivers could have come out a bit earlier. Since the tests of RAID controller usually take a lot of time, it always happens that some controller suddenly acquires new drivers. However, unfortunately, we can’t afford to retest the controller in this case, otherwise this process could become eternal...
The confusion with HighPoint controller drivers also caused me a lot of problems, however, now we know with all certainty that 2.33s driver ensures much faster performance of the RocketRAID 1520. And what is the point of 2.34s driver? We are going to find it out later.
I was very pleased with the performance of Intel’s RAID controller. Even though I used a beta version of Intel Application Accelerator, the controller performed very well. The only upsetting thing is that this controller performed best in the tasks that are not supposed to be its major.
Adaptec controller proved quire average, which is probably because of the raw drivers and controller BIOS. I assume that SiliconImage, which chip is used in this controller, didn’t provide Adaptec with proper drivers and BIOS versions in time. And maybe the fast driver simply hasn’t yet passed Adaptec’s validation.
However, there is one thing about Adaptec controller, which we would like to mention separately. It is the BIOS, which boasts the richest set of features and is highly convenient to work with. It is a very rare thing when a low-cost controller features the fully-fledged BIOS of the SCSI RAID product.
And the last thing. Since most controllers of those discussed today were tested on the so-called “first build drivers”, the results should be regarded as preliminary.