by FastSite
06/25/2001 | 12:00 AM
As we have already mentioned several times in our reviews, IDE RAID controllers are getting more and more popular. In the first place it has to de with the fact that more and more users appear unsatisfied with the performance provided by IDE HDDs or their reliability (or even both simultaneously).
Recently the mainboard manufacturers have been working on two versions of their mainboards in most cases: one without the integrated RAID controller and one with it. And depending on what the market wants they produce this or that models in mass quantities. However, the today's IDE RAID controllers have a very limited features set. Usually they can implement very few RAID levels: RAID 0 (striping), RAID 1 (mirroring) and any of their possible combinations. In fact, an ordinary user may hardly need anything else. We dare state with a pretty great probability that the majority of home RAID systems are made of two hard disk drives. However, with only two HDDs at our disposal we could create an array, which would either provide an increase in the disk subsystem performance (RAID 0), or ensure higher reliability and protection for the stored data (RAID 1). In order to combine high performance with high reliability we will need two more HDDs, which far not every user can afford. A different thing is the low-cost servers, which also require higher speed and reliability, but do not care that much about the pricing issue. It is exactly the place for RAID 01 and RAID 10 to be used.
If you are unfamiliar with the RAID terminology and want to know a bit more about the differences between the RAID levels, please see our ATA/100 RAID Controllers Roundup for more information.
01 and 10 RAID arrays provide both: high performance and reliability, however, not forever. If any of the 4 HDDs breaks down, RAID 01 will degrade into RAID 1 and RAID 10 - into RAID 0. In other words, the system will keep working but will either slow down considerably or no longer guarantee the data on the drives is as safe and sound as it used to be. Of course, if the server is located not too far away from the operator, then he will be able to eliminate the problem pretty fast (in case he has a spare HDD at hand analogous to those used in the array, of course). And if the server is located quite a while away and the status-quo needs to be restored as soon as possible? In case of a SCSI controller, you can have one more spare hard disk drive in the PC, which simply isn't included into the array (it is called "hot-spare"). Just the same way the drivers usually have a spare wheel in their car trunk :-)
In case the problem is encountered by one of the array members, the controller can disable the damaged HDD and connect the hot-spare one instead, which will allow restoring the array as it was. This way things really do happen in case of the "right" SCSI controllers.
But what about the ordinary IDE RAID controllers? In fact, in case of RAID 01 array by a controller like Promise FastTrak or AMI HyperDisk, or any other one of the kind, all the IDE ports appear occupied. Where should we connect a spare hard drive then? Unfortunately, the simplest IDE RAID controllers do not allow adding a hot-spare HDD in case of RAID 01 or RAID 10 arrays. However, the today's market offers some more modern solutions, which let you forget about this problem. First of all, there is promise SuperTrak capable of working with 6 HDDs simultaneously (4 of them can be united into an array and the other two appointed to be hot-spare ones). Secondly, there are some controllers, which support not only RAID 0, 1, 0+1, but also RAID 5 (see this article for details on RAID 5).
Well, this article is devoted to a comparative testing of three IDE RAID controllers, which can boast a bit more than just RAID 0, 1 and 0+1. They are 3ware Escalade 6400, Adaptec AAA-UDMA and Promise SuperTrak100. From the very beginning we would like to draw your attention to the fact that we do not intend this article to be regarded as a complete investigation, because even after a month's work we didn't manage to check all the modes and combinations of parameters. However, we did our best to give you a really good idea of what these controllers are capable of and where they can be successfully used.
At first, let's take a closer look at the package:

The box is quite big, we should say. However, the card is also not a small one. It is a full-size card with the built-in fastening handle. See the black square handle on the right side? In good cases it fits into a special hole to prevent the card from sagging.

The card looks very simple: you can notice only three large chips on the PCB. The main chip is responsible for the data transfer via PCI bus and manages the functioning of the entire device, while the other two are working with two IDE channels each providing contact with the HDDs in the array. Having removed beautiful stickers, we found out the following:
![]() DiskSwitch | ![]() AccelerATA |
These were the chips by a well-known Xilinx Company. They are also known as PLIC (Programmable Logic Integrated Circuits), i.e. the chips with programmable logic. These chips consist of some simple primary gates, which can be combined differently (just like the LEGO game) to create any kind of architecture. There are only two major restrictions: the number of gates used and the working frequency of the end chip.
The main advantage for the users here is the opportunity to correct or improve the device architecture composed of the chips like that via software. Which we actually had to do in our case, of course. The controller we got hold of, was unable to create RAID 5. To eliminate this drawback we downloaded new firmware for this controller from 3ware web-site (the set included an updated version for DiskSwitch as well as for AccelerATA) and reflashed it into the controller. The whole thing took no more than three minutes and hardly differed from the regular BIOS reflashing. Although if the power got suddenly switched off when the process was in full swing, then… god knows what could have happened.
Besides, the card is also equipped with the memory chips and 4 different IDE connectors. The connectors are located very inconveniently, so that the cables create a great mess inside the PC case.
Well, enough for visual inspection, let's pass over to the main specifications of 3ware Escalade 6400:
| 3ware Escalade 6400 | |
|---|---|
| Supported interfaces | UDMA 100*/66/33 |
| Max. number of HDDs | 4 |
| Supported RAID levels | 0, 1, 10, 5, JBOD |
| Bus type | PCI 32bit 33MHz |
| Remote administration | 3DM Disk Management |
| OS support | Windows: 98, ME, NT 4.0, 2000 Linux: Red Hat 6.1, 6,2, 7,0 SuSE 6.3, 6.4 UNIX: FreeBSD |
| Additional features | SMART support, background rebuild, hotswap, hotspare |
In this controller 3ware implemented two interesting technologies: StorSwitch and TwinStor.
3ware's patented StorSwitch architecture applies the principles of switched networking to servers, workstations and storage subsystems. The StorSwitch architecture employs a packet-switching design to give each disk a dedicated data channel and full drive bandwidth to the host PCI bus through a high-speed non-blocking switch fabric.
TwinStor technology is used in case of Mirror arrays and serves to improve fault tolerance and performance. In case of every new request the controller works with two mirrored drives simultaneously, thus increasing the read rate to its maximum.
Adaptec Company, which is very well-known due to its high-quality SCSI controllers also decided to put in a word in the rapidly developing IDE RAID controller market. And as we actually expected from a serious company like Adaptec, they launched not a Simple RAID 0, 1 controller, but a much more complex model called Adaptec AAA-UDMA.

The controller is shipped in a nicely looking box, and according to the package contents we concluded that Adaptec regards its newcomer as a really serious product: the manual in 4 European languages, the drivers for different operation systems, a CD-disk with Adaptec CI/O Management software, and each IDE cable packed into a separate plastic bag. This made a really good impression, guys :-)

Just look at the controller card. Unlike the one from 3ware, which we have just introduced to you, there is hardly any room left for at least a small chip on it. And mostly the chips are not that simple…
![]() | ![]() |
The chip responsible for the bus interface was made by Intel, while the IDE channels are again operated by a programmable chip. In fact, the use of chips like that is quite justified. You know that Adaptec has a huge experience working with SCSI controllers. And who may prevent the guys from integrating a SCSI-to-IDE Bridge chip into their SCSI controller? As far as we understood so far, Adaptec did exactly the thing.
![]() | ![]() |
AIC-7890 stands for high-level SCSI protocol, and AIC -7815G (the so called RAID co-processor) is busy working with the cache and fulfilling XOR-operations in RAID 5.
The cache represents a removable EDO DIMM module.

The controller is shipped with a 2MB module (as default), however it supports up to 64MB modules.
| Adaptec AAA-UDMA | |
|---|---|
| Supported interfaces | UDMA 66/33 |
| Max. number of HDDs | 4 |
| Supported RAID levels | 0, 1, 10, 5, JBOD |
| Bus type | PCI 32bit 33MHz |
| Remote administration | Adaptec CI/O Management |
| OS support | NetWare 4.2, 5.0 Windows 2000, NT 4.0 |
| Additional features | SMART support, background rebuild, hotswap, hotspare |
As for the interesting features typical of this controller we would like to mention the fact that the array should be created and managed not from the controller BIOS but with the help of a special Adaptec ARRAYCONFIG UDMA program, which starts after booting from a floppy disk.
Promise SuperTrak100 controller card is shipped in a traditional orange box:

As you can see, we have all the accompanying stuff lying in front of the box here. The package is pretty traditional: user's manual, diskettes and CD-disks with software. The only missing thing on this picture is the cables. We didn't put them there on purpose. If we did it, you would never see anything else, because there are six cables in the package. Not four, but six, since this controller can work with six HDDs at a time. On the next photo you can see all 6 IDE connectors:

The controller is equipped with three promise PDC20265 chips.

You should be very familiar with these chips already because they are integrated onto a great lot of different mainboards and are also used on Promise Ultra100 UDMA100 IDE card.
The operation of all chips on this controller card is managed by Intel i960 (RD66):

Cache memory in this case is designed as a removable DIMM FPM module.

The controller chip woks at 66MHz and is quite happy with the performance provided by a regular PC66 FPM module.
As default the controller goes with a 16MB cache memory module made of the chips produced by some Tonicom Company, which we haven't heard of before, actually. Officially controller supports up to 128MB memory modules, so there is room for improvement.

Unlike the previously considered controller cards, this one is equipped with the built-in indicators:

When the controller is working, the red lights keep blinking very nicely. However, unfortunately you can enjoy this blinking only if the PC case is open or if you turn it with the rear side to the font.
And here you can see all the cables connected to the card. Now you understand why we didn't want them on the general picture: there is a real lot of them:

The specs of Promise SuperTrak100 look as follows:
| Promise SuperTrak100 | |
|---|---|
| Supported interfaces | UDMA 100/66/33 |
| Max. number of HDDs | 6 |
| Supported RAID levels | 0, 1, 10, 3, 5, JBOD |
| Bus type | PCI 32bit 33MHz |
| Remote administration | Promise SuperCheck |
| OS support | Windows 2000, NT 4.0 |
| Additional features | SMART support, background rebuild, hotswap, hotspare |
Some time ago we assembled a special testbed for HDDs testing and today we are happy to introduce it to you:

When we decided on a PC case for it we were guided mostly by the following two reasons. Firstly, the case had to possess removable HDD holders and secondly, it had to provide easy access to all the insides. SuperMicro 601 was exactly the case that met all our requirements that's why we chose it. Although we didn't leave it as it was but still introduced a couple of changes. First of all we replaced the power supply unit, because the one available had too few power connectors, which were not enough for all our hard disk drives:

We preferred PowerMaster unit with 7 power supply connectors.
Then we had to add a bit more coolers into the system. One cooler was fastened from the inside to the rear panel of the PC case. Then two more coolers were put onto each of the two HDD holders. Unfortunately, only one holder of the two was equipped with a special mechanism for proper cooler fastening. However, we didn't give in and simply resorted to the help of thermal glue. To stick the cooler to the second HDD holder like this:

After all these manipulations we assembled the following test system:
Since all the controllers support only one hard disk drive per channel we set all drives as Master-units. Here we would like to point out that all the controller cards were provided with their own UDMA cables, which are the only suitable ones for them. You can't use a standard cable with any controller. Moreover, the cables taken from one controller of the three tested, do not fit for the other one. That is why there should be no problems with the cables.
We ran all the tests under Win2000 Professional. We used FAT32 and NTFS file systems to format each of the hard disk drives as one logical drive of the maximum size with the default cluster. All the tests were run 4 times and then the average results were taken for the diagrams. The HDDs didn't rest for cooling down between the tests.
Here are the benchmarks used:
For the controller cards the following driver versions were taken:
Of course, even for the simplest array there should be at least 2 HDDs involved. However, controller cards can work with a single HDD as well. When we connected one hard disk drive to Promise FastTrak100 and AMI HyperDisk100 controllers, they announced it was a RAID 0 array. That is why we added here the results obtained for a single hard drive.
To begin with, let's take a closer look at the results obtained in Drive 1.0:

We would like to share one interesting observation with you: all the parameters are gradually improving up to 3HDD and get a little bit lower for 4HDD. Note that the max liner read rate made only 40.2MB/sec. Even though there were three IBM DTLA 307015 HDDs connected to the controller, each of which is capable of providing the read rate of 37MB/sec. Well, this is where working via cache tells. But maybe we are wrong, and it is the problem with the benchmark? Let's take a look at the results obtained in HDTach:

| Graphs | Graph | Graph | Graph | Graph |
|---|
Hm, strange things keep happening. The average read rate drops down as the number of HDDs grows, and the write rate, on the contrary, rushes up. Does it mean that reading goes via the cache buffer and writing doesn't? The data transfer rate to and from the cache remains constant and is equal to approximately 45MB/sec. Moreover, it doesn't depend on the number of hard disk drives involved. The average access time however, is a bit lower than in case of a single HDD, which is quite logical.

| Graphs | Graph | Graph | Graph | Graph |
|---|
Yes, finally, no more problems with the linear transfer rate! Just look at the linear read graphs: what a thing! It turns out that Drive and HDTach can't work with this controller properly, that's it. The only parameter, which remains the same for all the three benchmarks, is average access time.
Now let's see how things in NTFS stand:

In NTFS the performance drops a bit when the second HDD is added. Then it takes on, though the results shown by a single hard drive still remain the best. In High-End benchmark, the results also drop down for 2HDDs case but then they grow up pretty rapidly.
A considerable difference between the cluster size (4KB) and stripe-block size (64KB) results into very poor parallel operation of the HDDs forming an array. And if there they don't work in parallel, then using this type of storage subsystem organization doesn't make much sense. At the same time, switching between the HDDs too often also leads to the performance lowering.
Now it's the turn of Intel IOMeter. Let's sum up all the Total I/O for all patterns in one table:

Since in the first place we are interested in checking the controller's performance under heavy workload, we decided to make up a diagram showing the dependence of the Total I/O for each pattern under Heavy load on the number of HDDs involved:

Well, the graphs are pretty typical, we should say. Almost for all patterns you can see some nearly linear dependence on the number of drives in the array. Look at the SequentialWrite graph: we can see two intervals made by 1-2 HDDs and 3-4 HDDs. Between them the tempo slows down noticeably. In other words, when the second AccelerATA chip is activated, the performance of the DiskSwitch chip is no longer enough. Anyway, despite all this criticism, the controller manages to transfer almost 80MB/sec in this mode, which is quite impressive.
Just as in the previous case, let's start from Drive 1.0 benchmark:

And again just as in the previous case the results are very strange. Now let's forget everything except Average Access Time and pass over to HDTach 2.61:

| Graphs | Graph | Graph | Graph | Graph |
|---|
Please, take a look at the average write speed. It doesn't depend on the number of hard drives connected at the moment and is limited only by the controller performance. it is most likely to be caused by the slow cache or slow chip responsible for data transfer to and from the cache.
The average read speed reaches its peak value (is it the maximum for this controller?) in case of 2 HDDs and then starts reducing. Maybe the bus got overloaded with some auxiliary info, which affected the performance so much? Hm… and what kind of bus is that then? There is only one chip on this controller card managing the connection to all hard disk drives. This seems to be the problem actually: the chip is simply unable to handle the hard drives that fast.

| Graphs | Graph | Graph | Graph | Graph |
|---|
Thank goodness, we can now see that the results obtained depend linearly on the number of connected hard disk drives. But the growth is again very low. The linear read graphs illustrate very well the maximum bandwidth of the controller. If we connect 1 HDD to the controller, the graph will look ordinarily. However, as soon as the second HDD appears, we will notice that the read speed doesn't exceed 45/46MB/sec.

The results in Business and High-End reach the top in a three-drive array. Then they start getting lower.
Now we are passing to Intel IOMeter.

The results can hardly be called impressive.

The controller proves scalable only in RandomWrite. In all other patterns adding more hard drives doesn't tell on the performance that much.
Frankly speaking, we have nearly lost all hope now to see something acceptable in Drive 1.0. But let's take another try, anyway:

As far as the linear read speed goes, no comments here. But the average access time has suddenly risen by 1msec. Since we have observed almost similar results in Drive, HDTach and WinBench, we assume that the access time growth in Drive test should be also noticeable in HDTach.

| Graphs | Graph | Graph | Graph | Graph | Graph | Graph |
|---|
The HDTach tests also showed that the average access time for RAID 0 by Promise controller is a bit higher than by 3ware and Adaptec ones.
Again the more hard disk drives are involved in the array, the higher gets the write speed and the lower appears the read speed. Although, in case of a 2-HDD array the average write speed turned out extremely low, you will understand what we are driving at when you take a closer look at the graph.

| Graphs | Graph | Graph | Graph | Graph | Graph | Graph |
|---|
Judging by the results obtained in Disk Transfer Rate test, this controller turns out to have even lower bandwidth than Adaptec AAA-UDMA. The maximum linear read rate it showed made only 20.3MB/sec.
In the integral tests the situation appeared really interesting. In Business Disk Winmark the performance peak was detected in a two-drive array. Then the performance dropped a lot, and with every other hard disk drive added grew a little bit. In High-End Disk Winmark we can see that the performance grows gradually little by little.

In NTFS the peak in Business Winmark is again achieved on an array composed of two hard drives and the results in High-End Winmark grow with the every new HDD added.
Now comes Intel IOMeter test:

Well, what could we say here? The results are far from being brilliant. Now let's see how it will all look on a graph:

Terrific! There appeared some limitations even for a RandomWrite pattern this time. And the results for three hard disk drives united into an array appeared better than for four hard disk drives, which means that even a multi-chip solution has its bottlenecks.
The most predictable results were obtained for SequentialWrite pattern: the performance grew up very slowly and got limited by the controller bandwidth (20MB/sec).
In fact, it doesn't make much sense to compare the controllers with each other in low-end tests. As we have discovered, according to the tests the bandwidth of Promise and Adaptec controllers is limited during reads and only 3ware controller shows the increase in performance as the number of the drives connected grows. Therefore, we suggest passing over to WinBench99 right away:

Adaptec and 3ware controllers show similar performance growth depending on the number of HDDs involved, while Promise controller suddenly faced some problems. The maximum performance it managed to achieve was that obtained for dual-drive array. Then the results simply collapse and after that we can notice a slight gradual growth again.

In High-End tests the amount of processed data increases and we see that the performance of Adaptec and Promise controllers is restricted by slower cache memory. 3ware, however, shows a much more rapid performance rise following the increasing number of hard disk drives in the array. But judging by the graph, its results are also very likely to get close to the asymptote when working with 6 HDDs (we could have checked that out if we had had Escalade 6800 at our disposal, which is equipped with 4 AccelerATA chips and is capable of working with 8 HDDs).

Beautiful scenery, don't you think so? The graphs for Adaptec and Promise controllers again go in parallel, except Promise SuperTrak100 for 3 HDDs, where something bad happened to it. Well, let's regard it as a testing error… If it were not for this error, Promise controller (just like Adaptec AAA-UDMA) could reach its maximum for 3 HDDs case. And every other HDD connected to it could only worsen the results. In fact there is nothing to be surprised at or frightened of. Not in every case the controller is requested, the configuration with more HDDs proves faster.
And 3ware controller has suddenly slowed down its pace. Why so? Is it the problem with the drivers or a dislike of small clusters? If every chip uses its own selected part of the memory, the thing may really turn out a problem.

Well, to our great disappointment we have to admit that in WinBench all controllers performed just the same was as a single HDD did. Actually, this fact once again proves that the controllers we are considering here were never intended for work in desktop systems.
And now let see how they managed to cope with server tests:





We can clearly see that in FileServer, WorkStation and DataBase patterns the controllers from Promise and Adaptec appear absolutely helpless… The performance appears comparable to a single IDE drive running, and as for the comparison with some SCSI system, you'd better forget about it once and for all. It seems to be slower cache memory that tells, because in RandomWrite pattern (where the controllers do only write operations) all the testing participants showed fine performance growth. Although Promise SuperTrak100 stopped pleasing us with the growing performance in case of 3 HDDs already, so that for 4, 5 and 6 HDDs the results remained unchanged.
In SequentialWrite pattern only 3ware controller proved dependent on the number of drives connected to it, having reached the top transfer rate of 78MB/sec for 4 HDDs configuration. On the diagram above you can clearly see that the graph consists of two parts: 1-2 HDDs and 3-4 HDDs. The graph changed its angle on the interval for 2-3 HDDs because at that moment the central DiskSwitch chip was shifting from work with one AccelerATA chip to work with two chips like that. DiskSwitch performance is no longer enough to work with each of the two AccelerATA chips with 100% efficiency. That is why the contribution to the overall performance made by each HDD separately appears somewhat lower. But nevertheless, the more HDDs get connected, the higher appears the speed.

Summing up the results for RAID 0 configuration, we can conclude that 3ware appeared an indisputable leader. Now let see if it retains the laurels in other RAID levels as well.
Mirroring seems to be one of the most widely spread type of RAID arrays. Even its software implementation doesn't take a lot of CPU resources. Since everything you need in this case is to duplicate the commands for the second HDD so that to have two absolutely identical hard drives. But as usual, things are not so simple as they might seem at first sight…
In case of software implementation of RAID 1, then there will be twice as many commands and data transferred via IDE bus during writes, which can reduce the average write speed. However, using UDMA66/100 controllers may help to solve this problem.
If there is a special controller used to create RAID 1 array, then it appears possible to send all the commands just once, and the controller will duplicate them. And if the controller has its own cache, it will allow unloading the bus significantly, since the controller will take the data to be written onto the second HDD from its own cache and not from the system memory.
Also there is one more feature, which seems to be implemented by 3ware guys in their controller card. If the data should be written first on the Master drive and only after the process is entirely completed on the Slave drive, then the reading can be carried out from any of them, since the info written on both is identical. In other words, we can request the HDDs in turns when reading, so that the whole thing looks very much like RAID 0 with that only difference that the array doesn't grow bigger.
Now let's see how 3ware's patented TwinStor technology works:

It is worth mentioning that Drive 1.0 didn't detect any difference in performance of RAID 1 array compared with a single HDD (allegedly in RAID 0). The only difference was a bit smaller access time by RAID 1 array. Nothing indicated even a slight increase in the transfer rate.
And what about HDTach?

| Graphs | Graph | Graph | Graph |
|---|
Here the tests also didn't show anything special about RAID 1 implementation on 3ware Escalade 6400…
But let's not give way to despair. We still have two more testing sets, WinBench99 and Intel IOMeter ahead:

| Graphs | Graph | Graph | Graph |
|---|
We would like to draw your attention to the transfer rate shown by RAID 1: it is much higher than in case of a single HDD, but lower than in case of RAID 0 for 2 HDDs.

The way this linear read graph looks signals that both HDDs do work in parallel, though not so efficient as in RAID 0 array, anyway. :-)
The same conclusion can be drawn from the table below. As you see, RAID 1 almost always appears between RAID 0 for 1 HDD (if you remember we decided to regard a single HDD working with a controller card as a kind of RAID 0 array) and RAID 0 for 2 HDDs.

And in NTFS the results turned out even more intriguing. The single HDD dashed forward, so that its leadership is beyond all doubts, while RAID 1 showed the worst performance here.
As we have already found out when testing the controllers in RAID 0 arrays, they are not suitable for good results in WinBench. That's why you shouldn't be surprised with what you see here now.
Well, we wonder if TwinStor technology will have any effect on Intel IOMeter results:

We decided to simplify our investigation by offering you some graphs, which are a bit easier to perceive than numbers and tables. First let's compare the controller's performance in RAID 1 with that shown in RAID 0 for 1 and 2 HDDs:

Hm… RAID 1 seems to be brave enough to compete with RAID 0 for 2 drives, having left the single drive far behind.

Well, almost the same picture as in the previous case. The difference between these patterns lies only with the requests size, which doesn't tell at all on the overall performance, as we can see.

In DataBase pattern, RAID 1 results appeared a bit closer to those of a single HDD. Everything corresponds completely to the theory, because this pattern includes more writes (33%) than Fileserver and WorkStation (20%) and the advantages of TwinStor appear evident only for reads. Going on with the idea, we can state that in RandomWrite pattern with 100% of write operations RAID 1 will show absolutely the same performance as a single hard disk drive:

However, there is nothing even close to what we expected to see! RAID 1 graph is always above RAID 0 for 1 HDD, which means that there is one more factor, which we haven't taken into consideration… As for a sharp increase, which you can see on the interval between 64 and 256 I/Os, you should bear in mind that our scale along the x-axis is a bit incorrect and in reality the increase is not so severe.

Well, these results seem quite logical: the bus gets slightly overloaded in case of too many requests submitted simultaneously.
Summing up we would like to make a very brief conclusion: TwinStor technology is worth it!
Adaptec didn't implement any specific technologies for RAID 1, however, we will do our best to find something out:

Well, nothing special so far. Let's pass over to HDTach:

| Graphs | Graph | Graph | Graph |
|---|
Again, there isn't anything extraordinary here. The average access time got a bit lower and the CPU utilization got a bit higher. Moreover, we could also point out the slowing down of all write speeds (min, max and average).

| Graphs | Graph | Graph | Graph |
|---|
Here RAID 1 is always slower than a single hard drive (except High-End FrontPage only). However, the linear read graphs are just impeccable.

The situation didn't change in a different file system: everything is just as in the previous case.
Now goes Intel IOMeter:

Let's compare RAID 1 and RAID 0 the same way we have just done it:

Well, we can't help asking here:" what's the advantage of RAID 0?" To tell the truth, the controller seems not to care at all how many HDDs are connected to it and what kind of RAID configuration it is working in…

See above for comments :-)

Only a growing number of writes managed to make RAID 0 for 2 hard drives prove faster.

This graph gives a perfect idea of a classical approach to RAID-building. A little advantage of a single HDD over RAID 1 configuration during high workloads is probably connected with the fact the controller itself gets less loaded in this case.

And here the picture looks really interesting: any configuration other than that with a single hard disk drive appears slower than the latter.
All in all, mirroring on Adaptec AAA-UDMA is none other but simple mirroring.
As usual, the first thing to come is Drive 1.0:

The results here are absolutely inadequate… We think it is the last time we resorted to this test for RAID controllers testing.

| Graphs | Graph | Graph | Graph |
|---|

| Graphs | Graph | Graph | Graph |
|---|
Judging by the Winbench 99, we can say that RAID 1 by Promise SuperTrak100 turned out very diverse. In some cases, it appears faster than a single drive, in other cases it appears faster than RAID 0 even. But still there are situations when it is an absolute failure.



Well, three different controllers bore three different graphs. We would like to draw your attention to the fact that RAID 1 graph starts far above all the others and the higher gets the workload, the closer it moves to the single HDD graph. It seems to us that Promise controller doesn't single out the Master and Slave drives in the Mirroring configuration, but simply duplicated the commands for both of them. And since the average access time is lower in RAID 1, the graph starts higher that the others.

The graph here is similar to the previous one reflecting the patterns similarity.

The more writes the pattern includes, the smaller gets the gap between RAID 1 and RAID 0 in the lower workload area.

In RandomWrite pattern the fact that HDDs in RAID 0 work in parallel tells on the performance and allows RAID 0 to surpass RAID 1 configuration quite tangibly.

Unfortunately, the controller bus is unable to get wider that's why duplicating all commands cuts down its practical width. And the writing on two hard disk drives appears faster than on a single hard disk drive only if the disk drive is that particular bottleneck that slows down the whole process.
Well, let's begin with WinBench 99. Fortunately, there were only two HDDs involved in this test that is why we managed to slightly reduce the number of graphs here.

In all the tests except High-End Disk Winmark for FAT32, the lead belongs to Adaptec AAA-UDMA controller.
And as for IOMeter, we will have to consider each pattern separately, since each of them models a possible application field for the controller and features its particular specifics.

Well, once again we start thinking that TwinStor technology definitely makes sense.

Well, it definitely makes much more sense than we have initially though.

Here again a bit more sense can be added. Just look what performance gain shows 3ware controller at the maximum load. Very simple architecture and such an impressive result! Maybe the engineers should think about it…

Here the leadership was taken by Promise SuperTrak100.

In the last test, all the controllers could have shown better results if it were not for their limited bandwidth.
Summing up this time we will based our verdict mostly on IOMeter results. And judging by them, 3ware controller deserves all the praise.
In the very beginning of the article we have already said a few words about the major differences between RAID 10 and RAID 01 arrays. Namely we said that 01 and 10 RAID arrays provide both: high performance and reliability, however, not forever. If any of the 4 HDDs breaks down, RAID 01 will degrade into RAID 1 and RAID 10 - into RAID 0. In other words, the system will keep working but will either slow down considerably or no longer guarantee the data on the drives is as safe and sound as it used to be.
In other words, RAID 01 is none other but RAID 1 though applied not to separate hard disk drives but to groups of hard disk drives (2-3 units in our case), which are united in RAID 0 arrays in their turn. And RAID 10 does just the opposite, i.e. it applies Striping to RAID 1 arrays. In this review we won't touch on the practical differences between these two array types, because Adaptec and Promise controllers tested can do only RAID 01 while 3ware controller can do only RAID 10. And since all these controllers show different performance, it is hardly possible to conclude which array type is better for this or that particular application field.
Of course, it was not for nothing that 3ware Company selected RAID 10 configuration to be implemented in its controller. This mode allows using TwinStor technology. As we have just seen, this technology proved very efficient in case of RAID 1 array. Now let's see if TwinStor Technology will work for RAID 10.

| Graphs | Graph |
|---|
Really, average access time was almost the same ad in case of RAID 1 array, but the read and write speeds have increased. Now we will try to figure out if it will tell on the results in WinBench 99.

| Graphs | Graph |
|---|
The outcome in WinBench appeared a little bit worse than by 2 HDD RAID 0 array. So, it appears that TwinStor technology showed its best only in Disk Trasnfer Rate test.

Now we would like to compare the performance of the controller for RAID 10 with the results obtained for RAID 0 array composed of 2 and 4 drives.

If the requests are not too numerous, RAID 10 proves as fast as RAID 0 for 4 hard disk drives. And if the workload rises, RAID 0 for 4 drives turns a bit faster. Note that RAID 10 appears closer to RAID 0 for 4 HDDs rather than to RAID 0 for 2 HDDs independent of the workload.

The picture repeats here in general.

Everything is absolutely correct, the more write requests turn up, the closer appear RAID 10 results to RAID 0 for 2 HDDs, because TwinStor doesn't work for writing operations.

Again everything is quite logical: in case of RAID 10 the controller has to transfer twice as much data via the controller bus.

And with a block size of 256KB, the picture turns out even more exciting. While there are few requests, RAID 10 is twice as slow as RAID 0 for 4 HDDs. However, as soon as the number of requests grows up to 16, its performance drops down to almost a half of that by RAID 0 for 2 HDDs. It is probably the controller bus that gets overloaded by duplicating commands sets inside the mirror arrays.
Adaptec AAA-UDMA controller supports RAID 01 array only. Although the end user may see no great difference between RAID 10 and RAID 01, it still exists. And it's a pity we won't be able to dwell on it here. Anyway, let's return to our tests.

| Graphs | Graph |
|---|

| Graphs | Graph |
|---|

Now that you've seen all the numbers, let's make some comparative analysis. We will compare RAID 01 with RAID 0.

Adaptec AAA-UDMA controller still doesn't give a damn about the type of supported RAID array…

The only remarkable thing here is the fact that RAID 01 and RAID 0 for 2 HDDs prove faster in case of 16 I/Os than RAID 0 for 4 HDDs. Other than that the picture is really aggrieving. Only when the workload is relatively low the requests are processed a bit faster than by a single HDD with an ordinary UDMA controller. But as soon as the workload starts growing, RAID 01 on Adaptec AAA-UDMA appears comparable with the performance of a single hard drive.

Yes! RAID 0 for 4 drives managed to get a bit ahead of the competitors…

In the SequentialWrite pattern, RAID 01 needs just a very little bit to catch up with RAID 0 array of 2 hard drives.

Additional workload falling on the controller during RAID 01 implementation resulted into the general lowering of the performance compared with RAID 0 for 2 HDDs.
So, RAID 01 on Adaptec AAA-UDMA controller does work and sometimes its performance is pretty predictable even. However, what we saw in FileServer, WorkStation and DataBase patterns makes further use of four-drive configurations hardly reasonable, since the performance gain provided by RAID 01 array doesn't make up for the expenses.
Adaptec and Promise controllers proved very close to one another in terms of performance, according to the previous benchmarks. Now we'll check how good RAID 01 is on FastTrak100 controller from Promise.

| Graphs | Graph | Graph | Graph | Graph |
|---|
The read speed provided by the controller is limited by relatively slow cache. However, the write speed looks not bad at all.

| Graphs | Graph | Graph |
|---|
In fact, we didn't notice any performance gain when the number of the HDDs connected to the controller increased. Supposedly, it doesn't tell on the performance at all.
No doubt, this controller will never suit for work with Windows applications.



As we can see, the performance of RAID 01 array with any number of HDDs is limited by the performance of the Stripe-group this array is based on. In case of higher workload, RAID 0 for 3 HDDs turns faster than RAID 01.

And in this pattern, RAID 0 for 3 drives can't boast the advantage over other testing participants as big as in the previous case.

The remarkable thing about this pattern is the failure of RAID 0 in case of lower workload. RAID 01 takes the lead then.

Please, pay attention to some really strange behavior of RAID 01 array for 6 hard disk drives. This array is made of two groups, each including 3 HDDs. Each group is an ordinary RAID 0 array. So two of them are united into RAID 1. Theoretically, the results obtained for RAID 01 made of 6 HDDs were expected to be much worse than those for 3 HDD RAID 0 array (since extra time is required to duplicate the commands for the second stripe group. However, under large workloads RAID 01 performs close to RAID 0 for 2 hard drives and RAID 01 for 4 hard drives. It seems to be the controller bandwidth that limits the performance then.

Well, we have already commented on graphs of the kind. Nothing new to say here.
We have to admit that Promise controller didn't show very high results. Moreover, its performance doesn't at all depend on the number of hard disk drives connected to it at all.
To tell the truth, comparing the performance of RAID 01 - 10 configurations in WinBench tests doesn't make too much sense to us. That is why we dare omit them here, as simple as that. All the results are available in tables, so if you like you may make the graphs yourself :-)
But Intel IOMeter results may be quite worth considering.

Of course! This is exactly what we have expected!

The gap gets even larger due to the increased size of the data block used. 3ware controller appears far ahead of its competitors.

The growing number of writes slightly slows down Escalade 6400 with its TwinStor technology and the gap gets a bit smaller.

The interesting thing about it is that RAID 10 by 3ware appears slower in RandomWrite pattern than RAID 01 by Promise and Adaptec. The leadership of Promise with a 6 hard disk drive array is quite logical, since it has the largest stripe group of all (made of 3 HDDs) and the write requests do not get into its slow cache.

In SequentialWrite pattern where we test the controllers' bandwidth 3ware is again in the leading position. Some of you may think that we forgot to add the graph for RAID 01 by Promise SuperTrak100. However, believe us, it is there. You simply don't' see it :-)
All in all, 3ware deserves the laurels on this stage, having been the fastest in the four patterns out of five.
Well, finally, we got to the most interesting RAID levels: RAID 3 and RAID 5. They attracted our attention because no IDE RAID controller had supported them before. Besides, these RAID levels, just like RAID 10 and 01, allow combining high speed and reliability and at the same time do not require too many HDDs to be included into the RAID array. Just think, in case of RAID 10 and RAID 01 arrays we sacrifice half of our hard disk drives for the sake of higher reliability. As for the RAID 3 and RAID 5 arrays, they require only one single hard drive extra. It will serve to store the XOR sum for each block of all the HDDs included into the array. And no matter how many drives the array includes: reliability issue will not require anything other than a single HDD.
There is a very important difference between these two arrays. In RAID 3 the parity info is always saved on one and the same drive, while in RAID 5 it is distributed over a series of drives. This way RAID 5 should be faster in case of many smaller requests coming.
RAID 3 also implies that the data is flaking down to bytes or groups of bytes. However, since the smallest information bit a HDD can provide is a sector, it doesn't make much sense arranging blocks smaller than 512Bytes. But we didn't stop there. Only Promise controller out of the three controllers tested can handle RAID 3. However, it also allows changing the stripe block size within a really large interval. In order to study carefully the limitations imposed by a separate parity drive onto the entire RAID 3 array, we set the stripe block size equal to 64KB, i.e. we simply transformed RAID 3 into RAID 4. That's why for Promise controller we decided to assume that what we tested was not RAID 3 (64KB stripe block) but RAID 4 (64KB stripe block).
Anyway, Promise controller tests are still a little bit ahead. And now we are tackling 3ware piece, as usual.
In the very beginning when we got our hands on this controller, it couldn't support RAID 5. However after we reflashed new firmware, which doesn't only update the BIOS but also changes some of the chips internal logic, RAID 5 support appeared. Now let's try to figure out if the controller, which has been the leader in all the previous tests, manages to implement RAID 5 accordingly.

| Graphs | Graph | Graph |
|---|
Note that the write speed is quite low. When testing the average read and write speed, HDTach works with 1MB data blocks. So, in order to write one 64KB block into RAID 5, the following action should be undertaken: 2 block reads from different hard drives (one block where we write the data and the other one where the XOR sum is saved), 2 XOR operations over 64KB blocks and two writes. The same thing should be repeated 16 times altogether…

| Graphs | Graph | Graph |
|---|
Hm, the results are far not high… what is pleasing here it's the linear read graphs and at least some kind of scalability of the controller.
Here come the results for Intel IOMeter.


Now let's compare the RAID 5 performance with that of RAID 0 for 2 HDDs.

Wow, it is not just good, it is simply excellent! Of course, a bit slower than RAID 0, but not too much. Note that RAID 5 for 4 HDD array working under really heavy workload manages to beat RAID 0 for 2 HDDs.

Larger blocks increase the load on the XOR-operations thus worsening the results a bit.

More writes move the graphs for RAID 5 slightly down, but do not affect their shape.

In case of 100% writing operations, RAID 5 gets three times worse than RAID 0 for 2 drives.

Writing large data blocks all the time makes the performance of RAID 5 array nearly dramatic. In this case it doesn't matter really how many HDDs are connected to the controller, because most of the precious time is spent on XOR-operations.
So, the controller, which has just learned to support RAID 5 appeared quite OK, we should say. Low results on writing can be explained by some RAID 5 general drawbacks rather than by problems with the controller. However, let's first check the other controllers in the same conditions.
Adaptec AAA-UDMA controller is equipped with a special RAID co-processor aka AIC-7815G, which will be dealing with XOR-operations. Now let's see how it is going to tell on the performance.

| Graphs | Graph | Graph |
|---|
The write speed appeared really somewhat higher than by 3ware Escalade 6400.

| Graphs | Graph | Graph |
|---|
Note that the results get worse as soon as the fourth HDD is connected.
The last test is Intel IOMeter.


Now let's compare RAID 5 with RAID 0 for 2 HDDs.

Well, no attempt to compete with RAID 0 has been undertaken so far. Moreover, the performance doesn't at all depend on the number of hard disk drives in the RAID 5 array.

The same picture as in the previous case. the higher gets the workload, the larger grows the gap between RAID 5 and RAID 0.

The more writes occur, the worse is the state of things for RAID 5.

Again, our worst predictions came true…

Just as by 3ware, Adaptec baby proved over three times slower in SequentialWrite pattern than RAID 0. Besides, Adaptec looks even a bit better sometimes…
As we have warned you, we will be considering two types of RAID arrays for this controller, that's why get ready for more tables :-)

| Graphs | Graph | Graph | Graph | Graph |
|---|
Well, the write speed appeared quite acceptable. Moreover, it is even much higher than that shown by other controllers. And as for the read speed, it turned out very low…

| Graphs | Graph | Graph | Graph | Graph |
|---|
The results in this test are very similar to those obtained for RAID 4: the more HDDs you add to the array, the higher grows the write speed and the lower falls the read speed.

| Graphs | Graph | Graph | Graph | Graph |
|---|

| Graphs | Graph | Graph | Graph | Graph |
|---|


In order to better understand what is the practical difference between RAID 4 and RAID 5, we suggest comparing the Total I/Os for arrays made of 3 and 6 HDDs.

However, despite all the theory, RAID 4 appears the fastest in the FileServer pattern.

Here the situation is just the same.

A combination of a plenty of writes and high workload help RAID 5 to win the leadership.

We wonder why RAID 4 for 6 HDDs appeared so awfully slow here? If worst came to worst it was supposed to show at least the same result as RAID 4 for 3 hard disk drives (if the limiting factor was the parity drive).

As we see nothing depends on the type of RAID array.
As a general observation, we would like to mention that the performance of Promise SuperTrak100 doesn't seem to be depending a lot on the number of HDDs connected to it.
Now let's compare the controllers' performance in Intel IOMeter:

All controllers except 3ware Escalade 6400 have some constructive limitations. They performance doesn't improve when the number of supported hard disk drives grows.

Just the same situation here. 3ware, however, can boast a slight performance improvement. All the rest can't boast anything here.

Now Promise controller expressed some intention to start running faster. :-)

These results are really interesting. Promise SuperTrak100 leaves all its rivals behind and shows the increase in performance in case of RAID 5 configuration. In RAID 4 array the performance on the contrary drops down and then stabilizes more or less. Maybe it was caused by the third PDC20265 chip being set into operation at that time.
It's a pity that we didn't have 3ware Escalade 6800 controller at hand. We wish we could continue this graph a bit more.

Well, again Promise proved the fastest. It seems to be a tendency already ;-)
All the controllers tested have proven very stable and capable of recognizing errors and devices failures. For all of them we tested the ability to quickly restore the failed array and we have to admit that there nothing we could complain about.
Certainly, the results were all very different. You can see it yourself if you look through the "Controllers Comparison" paragraphs. What we are going to say now is which controller we liked most of all. :-)
As you may have already guessed, we gave our preferences to 3ware Escalade 6400 controller. Simple architecture combined with a couple of original technologies, excellent performance and scalability.
Promise and Adaptec controllers have some architectural drawbacks, since both companies tried to use the already developed solutions rather than work on a totally new product from the very beginning. We wouldn't deny that they did manage to save some money and trouble, but it negatively told on the controllers performance. You can clearly see that slower central chip and memory on both of them perform as a tangible bottleneck. Their advantage over 3ware Escalade 6400, however, is the ability to support larger cache memory. In fact, we haven't dwelled on this potential advantage that much this time, that's why we wouldn't state that with a 100% certainty.
Also we would like to say that all the tests were run for the stripe blocks of only 64KB, and we suspect that in case of stripe blocks of a different size the situation could appear a it different as well. But you can't cover everything in one article, so maybe next time…
In conclusion we would like to point out that despite relative low results (compared with those shown by SCSI systems), all controllers cope with their task successfully: they create fault tolerant storage subsystems with large storage capacity and of relatively low cost. Now the market offers really good HDDs with perfect price-to-capacity ratio, which will suit ideally for a storage subsystem capable of competing with a SCSI one at least in terms of pricing. For instance, RAID 5 configuration built of three IBM DTLA 307075 HDDs, one IBM DTLA 307075 as a hot spare drive and an IDE RAID 5 controller will cost around $1600 altogether. A system of two Seagate Barracuda 180 HDDs and a controller will cost at least twice as much. Therefore, these controllers really offer us a great opportunity to save. Which can't remain unnoticed.
In fact, we are about to very soon see a new generation of IDE RAID controllers. Adaptec announced the launching of their new ATA RAID 2400A (for 4 HDDs, supporting RAID 0, 1, 01, 5), which will be equipped with a faster I/O chip - i960RS. Promise announced the upcoming external IDE RAID UltraTX4 and TX8 systems for 4 and 8 HDDs respectively equipped with a SCSI-to-ATA Bridge, by the way, which will allow connecting them to any Ultra2 LVD SCSI controller with an ordinary 68-pin LVD cable. We believe there will be also an internal version some day.
So, there seems to be the whole lot of cool info and interesting test coming, so stay tuned!