One of the major drawbacks of IDE-RAID controllers is a small number of HDD, which could be connected to it. Widely spread solutions based on Promise, HPT and CMD chips featured only two channels, each of which allowed connecting only two hard disk drives. However, two hard drives couldn't work simultaneously if connected to a single cable, because of the limitations imposed by the interface. That is why the performance of a configuration like that has always been lower than the performance of an array, where two drives were connected to two different channels. To design a controller with a single HDD per channel but with the unchanged number of channels at the same time, there can be several chips on the PCB connected via a PCI bridge. Promise with their TX4 took this way, as their TX4 controller is equipped with two chips connected with one another via a PCI bridge.

However, you can not increase endlessly the PCB size so that more IDE chips could fit there. Besides, it is not an easy task to make a multi-chip configuration like that work properly.

3ware Company managed to solve this problem in a very simple and elegant way. How? Let's find it out!

Closer Look: Controller Card

Here it is: 3ware 7810 8-channel IDE RAID controller:

The PCB of this controller card is surprisingly small. This PCI64 card is only 17.5cm long and 10cm wide. Compared with Adaptec 2400a, 3ware 7810 controller seems to be a "halved solution", however, this is a wrong impression. There are two IDE chips, DiskSwitch chip, two memory modules (cache), ST microcontroller chip, BIOS chips, etc. all on a very small area.

The first thing that attracted my attention was the unusual memory chips:

When I took a closer look it turned out that these were 128K x 32bit SRAM chips from Samsung (K7N403601A). As we can calculate the memory size of not that big: 2 chips 576KB each make the total of 1.125MB. However, the speed of this memory makes up for its relatively small size (it is not just an ordinary SRAM but NtRAM, memory with zero array access cycle).

DiskSwitch and AccelerATA chips are no longer marked with "Xilinx", but in fact, they are just the same Field-Programmable Logic ICs:

DiskSwitch	AccelerATA

Just like in 3ware 6xx0 controller, you can reflash not only the BIOS, but also the DiskSwitch and AccelerATA. Though I didn't have to do it, since there were newest versions reflashed in the controller I had at my disposal.

The controller card supports RAID 0, 1, 10, 5 and JBOD and is designed to work in PCI64/33MHz slot and the regular PCI32 slot (unfortunately, it refused to work in a slot like that in our case. When the PC booted, the controller requested all HDDs, found them and then kind of "hung". Maybe I could update the firmware to solve this problem, and maybe the problem is connected with the mainboard BIOS. However, I didn't have a choice: I could test 3Ware 7810 only in PCI64/33 slot). It supports RAID 0, 1, 10, 5 and JBOD.

Yeah, I nearly forgot about the most important thing! :) Eight IDE connectors! This is what this controller card exists for. These eight 40-pin black connectors are ready for 8 120GB hard disk drives. In this case the maximum array capacity will make 960GB, which is almost 1TB (840GB if we create an array with "parity"). And this array will cost much less than a SCSI analogue of the same storage capacity.

Drivers and Utilities

As for the operation systems supported, the exact list is available on the 3ware web-site, however, I would like to say right away that there are drivers developed for this controller to work in any of the major OS's :)

In our case, the drivers and utilities for Win2000 were of particular interest. The drivers got installed without any problems, and afterwards we saw the following in the controller properties:

It is a typical feature of this controller to automatically announce the hard disk drives as JBOD if they are connected to it but not united into an array. As a result, they become available as single drives only. In other words, this controller can be used as an IDE controller as well.

Of course, it costs a bit too much for just an IDE controller, but it occupies only one PCI64 slot, which is a good thing.

And this is what the array status monitoring utility aka 3DM Management Utility looks like:

Unfortunately, this utility can only reflect the array status and write it down into the log-file, but it doesn't create or configure the arrays. This utility can be minimized to hang in the tray:

This way, it doesn't disturb you from work. However, once some problems with the array or a single drive occur, the utility gets automatically maximized and reports the problem. The visual warning is also accompanied by some sound effects, which can be disabled manually.

If you cast a glance at the lower part of the 3DM window you will get all the information about the firmware version of all controller chips, the driver version, etc.

Closer Look: Chassis

In the very beginning of the review I complained about very few IDE channels by most controllers, and the previous section ended up on a very merry note. However, things are far not that simple. I really doubt that you will be able to find mane PC cases, which could have enough room for eight 3.5" HDDs. In one of our previous articles we provided a picture of our testbed with 6 HDD working besides the system drive. Hey were all connected to Promise SuperTrak100 controller. It seems that we will never manage to insert more HDDs into that SuperMicro case. But it nevertheless turned out possible!

  

This wonder happened due to a special 3-drive IDE chassis from 3ware aka MS2231:

It is made of metal that is why it weighs quite a lot. The chassis can be fastened to the PC case either with common screws or with the slides, which is what we used to install the chassis into our SuperMicro (Chieftec) SC-701 case.

The chassis front panel has power and status indicators for all the three drives working in it, which are connected to the drives via a special flexible cable.

In order to provide proper HDD cooling, 3ware equipped one of the chassis sides with two Sunon KD1206PHB1 fans.

The rear panel of this chassis is equipped with 3 IDE and only two power supply connectors. It is a very clever solution to provide three HDDs working in a chassis with only two power supply connectors. When we tried to install 8 HDDs into SC-701 case, we lacked the power supply connectors for them. Of course, this problem could be solved with the help of power-cable splitters, however any additional mechanical connection like that may turn into an additional cause for concerns once the problems arise. That is why it is definitely a very smart way of reducing the number of power supply connectors.

This is what the chassis looks like with the front panel taken off. We can see three mobile racks with three hard disk drives installed and three power "locks". These "locks" allow us to connect or disconnect the power from the HDDs in the chassis.

This picture shows us how tightly the HDD sits in the mobile rack. This ensures excellent heat dissipation and eliminated operation vibrations, which are absorbed by the massive chassis.

In order to fit three HDDs into an U2 sector, the mobile racks are of the minimum height possible, although the HDDs do not touch one another when installed.

This is what you will see inside the chassis if you remove all the mobile racks. You can clearly see the connectors on the dock-station and numerous capacitors.

And this is a connector of the mobile rack:

48 pins is actually far from 64 pins like by Promise SuperSwap, but it is still more than by standard mobile racks.

OK, did you have fun watching these hardware pieces? Now let's have even more fun with the benchmarks!

Testbed and Methods

Our testbed, the one you saw on the photo above, was configured as follows:

• Intel Pentium III (Coppermine) 600MHz CPU;
• Supermicro 370DLE mainboard;
• 2 x 128MB Registered PC133 SDRAM with ECC by Micron;
• Fujitsu MPG3102AT HDD;
• Matrox Millennium 4MB graphics card;
• Windows 2000 Pro SP2.

When we created arrays, stripe-block size was equal to 64KB. For WinBench tests 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:

• WinBench 99 1.2
• IOMeter 1999.10.20

For Intel IOMeter tests we used the following patterns:

We studied the influence of the stripe-block size on the performance in RAID 0 array of 4 HDDs.

Performance

WinBench99

I will report only the most essential results here. I suppose you understand why :)

DTR: Beginning

Graph

Graph

Graph

Graph

Graph

Graph

Graph

Graph

RAID 0 results show that RAID 0 on 3ware 7810 is at least not in the least worse than the results obtained for the HDD working with a regular IDE controller. The more HDDs are involved in the tests, the higher get the WinBench results. However, the proportion coefficient is so small that I wouldn't say that it makes any sense to use RAID 0 configurations to improve the disk subsystem performance in Windows. But if you work with large files, the whole thing will turn considerably faster. If you take a look at the linear read graphs, you will see that the read speed grows in direct proportion to the number of HDDs in the array. Due to clever controller architecture and high bandwidth of the PCI 6433MHz bus the read rate from the array reaches its top only when the sixth IBM DTLA HDD is connected (the read rate in the beginning equals 37MB/sec), and then keeps growing up just a tiny bit. In other words, the maximum controller bandwidth makes around 200MB/sec, which is twice the bandwidth of the regular PCI 32/33MHz controllers.

DTR: Beginning

Graph

Graph

Graph

Graph

Graph

Please, take a look at the results obtained for RAID 1 array. In WinBench99 RAID 1 array is slower than a single HDD, however, the linear read speed of RAID 1 array is twice as high as that of the single drive. We are already familiar with TwinStor technology, when the read requests alternate for two hard disk drives in RAID 1 array (see our High-End IDE RAID Controllers Roundup). Namely, RAID 1 on 3ware controller is similar to RAID 0 array of 2 hard drives in terms of reads. However, as it comes to writes, RAID 1 array turns noticeably slower than a single HDD, because the controller has to perform the write operations for each of the two HDDs of the array separately and to wait for them to be completed. That is probably why RAID 1 falls behind a single HDD in WinBench99 (we have already proven here that WinBench99 test includes write operations).

And finally come the results for RAID 5 array:

DTR: Beginning

Graph

Graph

Graph

Graph

Graph

Graph

In case of RAID 5 array, the controller performs much more disk operations than in case of RAID 0 or RAID 1. Theoretically, the reads are performed without any performance losses, and each write operation requires reading two stripe-blocks (or parts of stripe-blocks) and writing two blocks. So, don't be surprised with the low results shown by this type of array in those tests, which include write operations.

Well, everything proved up to our expectations: the results in WinBench99 are two-three times worse than those shown by RAID 0 array. Though the linear reading of RAID 5 is quite OK (I mean Disk Transfer rate here).

Intel IOMeter

The tables below contain the Total I/O rates, i.e. the values of the requests processed by the controller.

I really don't know if you need my comments here :)

In order to get a better idea of how the performances of different RAID arrays correlate and how the number of hard drives in an array influences the performance of this particular array, we suggest taking a look at the following diagrams (they contain Total I/O with the maximum workload).

Let's begin with FileServer Access Pattern:

First of all, I would like to point out the fact that the performance of every array depends linearly on the number of HDDs forming this array. As for the performance correlation, things are even simpler here. RAID 0 is the fastest (however, take note that this array is the least reliable of all). Then comes RAID 10, and RAID 5 is the slowest here. I would also like to draw your attention to the fact that RAID 1 results can fit into the imaginary continuation of the RAID 10 graph.

Here the situation hardly got any different. The only thing is that the results shown by all arrays are somewhat higher than in FileServer pattern.

The increase in write requests by 33% worsens the performance of RAID 10 and RAID 5 arrays. This influence is especially negative in case of RAID 5.

This is the hardest pattern of all for RAID 10 and RAID 5 arrays. Since 3ware controller doesn't have a large cache buffer, it is very difficult for it to arrange lazy writes especially when the array is requested randomly.

In this pattern we test if the controller is capable of passing through large bits of information. Judging by the graphs it copes with this task pretty well. The maximum write speed (in case of RAID 0) made around 130MB/sec. The results shown by RAID 10 are a bit more modest: 61MB/sec for 8 HDDs, i.e. almost twice as slow! No wonder, since the controller has to duplicate the info onto the mirror drives. Even slower performance was shown by RAID 5 array: only 41MB/sec. Note that for all the array types you can clearly see how the controller bus workload increases once there are all the 8 drives involved. In other words, I have every right to say that 8 HDD as fast as IBM DTLA load the controller bus to the full extent during this kind of operation.

In case of Random Reads the controller performs just brilliantly. All arrays work similarly fast and all of them scale equally efficiently.

In case of Sequential Reads we again see the controller getting "sate" when there are a lot of drives included into the array. If you want to find out at what speeds this "sating" arrives, you can take a look at the next graph where the Total I/Os are represented in MB/sec. These values were obtained as follows. The size of the processed block in this pattern makes 256KB. It means that to get MB/sec you will have to divide the controller Total I/O by 4.

After this simple arithmetic calculation we get:

A really exciting view! It you look attentively at RAID 0 and RAID 5 graphs, you will notice that RAID 5 graph repeats RAID 0, but seems moved a bit sideward along the X-axis (by one HDD approximately). Which corresponds to the theory completely! In RAID 5 some blocks of every hard disk drive are used to store the checksum (they are singled out of the effective HDD storage capacity and do not take part in reads).

The IOMeter results showed that 3ware 7810 controller boasts good scaling abilities and a well-balanced architecture.

However, since the controller tests carried out only for a stripe-block of one certain size can't reveal all the controller highs, we decided to carry out one more investigation.

Stripe Block Size and Its Influence on the Performance

In the previous IDE RAID controller review we found out that the stripe-block size does have a really tangible influence on the controller performance in some patterns. But now we are testing a totally different controller with a different supported range of stripe-block sizes. I wonder if the discovered tendency will repeat here…

Just in case, let me remind you that these tests were run with RAID 0 array of 4 HDDs.

Well, it seems that the story repeats. The rule "the larger is the stripe-block, the better" seems to work for this controller, too.

Of course, I could start explaining that in this pattern the array works faster with 128KB stripe block, and in that pattern - with 1024KB stripe-block, but you see everything yourselves…

As a rule, the array works faster with 1024KB stripe-block.

The only exception here is the SequentialRead pattern with linear workload. The diagram shows that large stripe-block has a negative influence on the array read speed in case of linear workload. Why? Look here: the data block size read from the array upon every new request makes 256KB. If the stripe-block is 64KB big, then each of the four HDDs of the array reads 256 / 4 = 64KB when processing a request. In other words, the hard disk drives work simultaneously or "in parallel". The larger gets the stripe-block, the fewer HDDs take part in the request processing (128KB - 2 HDDs, 256KB - 1HDD). As a result, the array read speed gets lower proportionally.

When the requests queue gets longer, the controller changes the order of commands processing and finds some work for each hard drive of the array. The read speed under heavy workload doesn't any more depend on the stripe-block size, but only on the controller or hard disk drives throughput.

Reliability

To check how well the controller can dehose the array once one of the hard drives fails, I modeled some emergency situations in RAID 10 and RAID 5 arrays of 4 drives.

RAID 10 and RAID 5 arrays got rebuilt in about 10 minutes, which is a record for IDE RAID controllers so far.

Conclusion

3ware 7810 controller proved very functional and beautifully scaleable depending on the number of hard disk drives connected to it. Since this controller boasts 8 IDE channels it suits just ideally for disk subsystems of large storage capacity. Bearing in mind that the IDE-drives storage capacity keeps growing day by day and the price of 1GB of info on them gets lower, IDE disk subsystem looks more and more attractive from the pricing point of view. I would also like to point out that 3ware offers not only controllers but also high-quality 2U HS-chassises, which are just perfect for 2U NAS-devices.

Highs:

• High performance;
• Perfect scalability;
• Many IDE channels;
• High controller throughput (PCI64);
• Low dimensions;
• HotSwap and HotSpare support.

Lows:

• No way to create/modify arrays from the OS.

Now I would only like to add that 3ware 7810 controller is unique because it not only knows to work with 8 IDE drives, but also does it simply excellently! Its well-balanced architecture helps it cope successfully with server workload as well as with streaming reads and writes. All in all, this is a professional choice! :)