As we remember, the first step Adaptec Company made towards the IDE RAID controller market was far from success. AAA-UDMA controller was much weaker than its competitors, such as 3ware Escalade 6400 and Promise SuperTrak100 (see our High-End IDE RAID Controllers Roundup). It could be partially explained by the fact that Adaptec created this controller from what they had at their disposal at that time. They simple designed an IDE controller and then added an IDE-to-SCSI bridge to it. The end-system was pretty slow and cost a considerably sum of money. So, the only thing Adaptec could do was to give up the thing.

However, Adaptec wasn't ready to give in so quickly. So, they launched their second IDE RAID controller aka Adaptec 2400A. Well, let's see if Adaptec's engineers managed to improve since then :)

Closer Look

Well, our acquaintance with the controller started from the beautiful box:

The box is designed in standard Adaptec colors, and the picture says that 2400A controller is positioned for Low-End 1U-2U servers. Now let's open the box:

Well, here we see a full length PCI 32/33MHz card.

But, as you can notice, there are not so many chips on it (not 7-8 chips as on AAA-UDMA, but only 4!). The largest chip is Intel i960 RS100 RISC processor:

For IDE controllers Adaptec selected widely spread HighPoint HPT370 chips:

I can't say that I trusted RAID controllers on these chips a lot, but here they seem to be fulfilling very limited functions of IDE-controllers only. Nothing more.

The cache memory modules of Adaptec 2400A controller is designed as a removable (i.e. also replaceable) PC100 SDRAM DIMM. The controller is shipped with a 32MB module by default, however, they are claimed to support up to 128MB (inclusive).

The controller is equipped with LED indicators, which is unfortunately located on the inner part of the controller, hidden from the user.

The controller installation didn't arouse any problems. The drivers and utilities also installed easily.

The controller firmware allows replacing very easily as well. I also liked a lot the fact that it was possible to create and reconfigure the arrays directly from the controller BIOS on the system booting or with the help of a special utility running from the OS.

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;
• WD200BB HDD;
• Matrox Millennium 4MB graphics card;
• Windows 2000 Pro.

When we created arrays, stripe-block size was equal to 64KB. For file 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. We used the controller driver version 3.03 and firmware version 370F. 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. The same array was used to find out the influence of the cache-buffer size on the performance.

Performance

WinBench99

Now we will find out what you get if you decide to use this controller for the ordinary Windows applications.

DTR: Beginning

Graph

Graph

Graph

Graph

Well, this test shows that IDE RAID controllers hardly provide any advantage. :)

The scalability depending on the number of HDDs in RAID 0 can be clearly seen only in linear reading, and in applications the benchmarks results hardly depend on the number of hard drives involved. When the fourth HDD is connected, the linear read speed also stops growing, which means that we have reached the top bandwidth of the PCI32 bus or the controller. Referring back to the previous reviews, 90MB/sec is the maximum for all PCI32 controllers that is why we shouldn't blame Adaptec 2400A for that. On the contrary, we should praise it. Maybe we should rebuke it just a little bit for the absence of PCI64 or PCI32 66MHz support.

DTR: Beginning

Graph

Graph

Graph

Graph

Graph

Here the results are also not very interesting to comment on. The only curious thing is the linear read graph for RAID 5 made of 4 HDDs. Something seems to have interfered there… :)

Intel IOMeter

Adaptec 2400A controller is positioned as a solution for Low-End servers. I don't know if our tests correspond to the level of Adaptec's Low-End servers, however, I will try to vary the controller workload, so that to test it in a wider range of different conditions. Who knows, maybe it will outperform SCSI?

At first come the results (only Total I/Os) for the controller with RAID 0 array:

As we see, the scalability is doing quite alright. A little bit later we will see it on the graphs:

And here the interesting things start happening. RAID 1 array is much faster than a single hard drive, RAID 5 is also quite good. I can't wait to compare them on the diagrams :)

For this purpose we will need the results for different array versions in each pattern in case of the maximum workload:

The first test brings the first shock: RAID 1 appeared just a little bit behind RAID 0 in case of 2 HDD array. And RAID 5 turned out pretty fast. Though adding the fourth HDD to RAID 5 array didn't result into as high performance growth as by RAID 0, but this is actually the way it should be.

Also I have to point out very good results shown by RAID 01 array, which outperformed RAID 0 built for 3 hard disk drives.

Judging by the results of RAID 1 array, Adaptec bears in mind the idea of read requests alternation between the two HDDs in the mirror-group, which used to be implemented only by 3ware. In other words, RAID 1 array doesn't yield even a tiny bit to RAID 0 of 2 drives during reading operations.

Let's find out how it will tell on the results in other patterns:

In this pattern we see that RAID 1 yielded a bit to RAID 0 of 2 HDDs. It happened not because of the lower RAID 1 performance but because RAID 0 got faster when working with 8KB data blocks (in FileServer pattern the data block size can vary, though the major part of requests deals with 4KB blocks).

Here RAID 1 falls behind RAID 0 of 2 HDDs for a different reason: there are more write operations effected here and they cannot be alternated. The block is written onto two drives and it takes a bit more time than writing onto a one HDD in RAID 0.

The same problem arises in case of RAID 01 array, which speed drops down to that shown by RAID 0 of 3 HDDs.

This is the heaviest pattern for RAID 1, RAID 5 and RAID 01. RAID 1 performance appears even lower than that of a single HDD, since there are almost no reads, but only writes, which need to be duplicated and written onto the second drive in an array.

The speed for RAID 5 is most likely to be limited by the speed of XOR processor and the necessity to write not only the selected data block but also the modified checksum.

Even when the data block increases up to 256KB, no drastic changes occur. Only the results of RAID 01 get a bit lower: the poor thing can't cope with the task because of the growing cache-memory load.

This is an excellent evidence that my hypothesis about the "alternation" of read requests in RAID 1 and 01 is true. The results of these arrays are nearly equal (RAID 1 is even a bit faster than RAID 0!) Another curious thing is the fact that reading from RAID 5 array doesn't cause any performance drops compared with RAID 0 array built with the same number of HDDs.

In this patter RAID 1, 5 and 01 arrays do not look that nice any more. As for RAID 1 and 01, everything is more or less clear: since the read requests are distributed between the hard disk drives (or stripe-groups) according to the set stripe-block size, then 256KB are requested from every HDD (or stripe-group). It means that each of the RAID 1 HDDs reads and throws out 256KB blocks (though in this case the next 256KB request is processed by another hard drive). This loads the bus and reduces the overall system performance.

And as for the poor results shown by RAID 5, I hardly have any explanation ready.

Stripe Block Size and Its Influence on the Performance

In those IOMeter patterns, which we use for tests, the size of processed blocks of data is fixed. But will anyone warrant that this default stripe-block size will let the controller reach the top of its power? I wouldn't warrant that :)

Therefore, I carried out some tests for stripe-blocks of all possible sizes, which could be set with Adaptec 2400A controller: 32KB, 64KB, 128KB and 256KB.

The graphs below show the dependence of Total I/O (the requests processing speed of the controller) on the stripe-block size for each pattern.

As you can see, there is very clear dependence of the performance on the stripe-block size in all patterns except SequentialWrite and SequentialRead. In most patterns the bigger is the stripe-block, the higher is the speed. Also we see that further increase in the stripe-block size (over 256KB) will hardly make much sense. Although Adaptec engineers took care of it themselves. :)

Cache-Buffer Size and Its Influence on the Performance

Another important parameter influencing the performance is the size of the controller cache-buffer. Adaptec 2400A controller is sold equipped with a 32MB module, however, you can increase the cache-buffer size up to 128MB if you like (I will not write about the prices of 128MB modules here, as they will get outdated too quickly).

I wanted to try it and here is what I got:

Why did our hero equipped with 128MB cache-buffer perform so poorly: even worse than in case of 32MB or 64MB modules? I didn't have a 128MB PC100 module with 2-2-2 timings at hand (and 32MB and 64MB modules were exactly with these timings), that is why I used a PC133 memory module… Maybe that was the reason of this failure? However, let's look at the problem from a different view angle: we have already proven that we need a memory module not only of the maximal capacity but also with the minimal timings (it'd better be a brand-name module with the correct SPD) to get the highest performance.

Caching System Settings and Their Influence on the Performance

As far as I understood, enabling write back option in the controller BIOS leads to forced caching of the writes, i.e. the controller creates some writes queue in its cache and then performs these writes when it has time. We know (see our article called IBM Deskstar 60GXP: Performance Secrets) that lazy write influences the HDD performance quite a lot. Let's see how it will influence the RAID array speed!

As we can see, the performance doesn't change even when the write back is enabled. There are two explanations: either this option has been inherited from the Adaptec SCSI controllers' BIOS and simply doesn't work by 2400A, or this option is enabled by default.

Reliability

To check if the controller is capable of recognizing the failed drives in an array and undertaking appropriate measures, we imitated some emergency cases in two types of arrays: RAID 1 and RAID 5. RAID 1 rebuilt in 15 minutes, while RAID 5 of 4 HDDs required 1.5 hours. Even though we stopped Intel IOMeter and set the top priority to rebuild operations.

Conclusion

To leave a little bit of intrigue, I will not compare Adaptec 2400A with the competing products now. However, it is evidently faster than Adaptec AAA-UDMA (SequentialWrite speed of 2400A in RAID 5 is three times as high as that of AAA-UDMA). In the patterns imitating server load the controller also performed very well. Besides, Adaptec 2400A controller can improve its performance over the nominal by simple increase in the cache buffer size.

So, now it's high time we summed up everything.

Highs:

• Excellent performance in RAID 0, 1, 01;
• Opportunity to increase cache buffer capacity;
• Drivers for all widely spread operation systems.

Lows:

• Large PCB;
• No support for PCI32/66Mhz and PCI64.