by FastSite
02/14/2002 | 12:00 AM
Well, finally I completed the test of the last available IDE RAID controller supporting RAID 5: promise SX6000. It allows arranging up to 6 hard disk drives into RAID 0, 1, 01, 3, 5 arrays. This way, we had to test 17 different RAID configurations, which took a considerable time, as you may have already guessed.
If you remember the first RAID 5 controller from Promise, which we managed to test (SuperTrak100), we don't think it was a 100% success. However, now it should be even more interesting for us to estimate how well Promise engineers managed to single out and improve the drawbacks of the SuperTrak100 and if the today's hero, SuperTrak SX6000 is free from them.
SX6000 controller is shipped in a beautiful colorful box:
Inside this box there is another white one:
Besides the controller card, which you will see below, there were:
I would like to draw your particular attention to very nice-looking power cable splitters:
Unfortunately, not all the cases can boast enough power supply connectors to install all the hard drives that SX6000 can support. However, my tuning stand built in SuperMicro SC701D managed to cope with this task pretty successfully (and the cable splitters were left for a rainy day).
And now, please, meet the controller:
As we see, the location on the electronic components on the PCB is a bit different from the SuperTrak100 architecture. The CPU is now covered with a heatsink (which I failed to remove, as it was so perfectly stuck), the cache-memory slot is moved under IDE chips, and the latter were moved closer to IDE connectors.
There are no components on the reverse side of the PCB.
Each of the IDE chips is responsible for two IDE channels:
However, the chips on the controller PCB are not common chips! Judging by the marking (PDC20276) SX6000 controller is equipped with the newest UDMA133 IDE controllers from Promise.
The bracket is equipped with the controller status indicators, and near them we can see something looking very much like a not quite laid out COM interface for remote control. However, this is far not the only interesting thing. If we cast a glance at the opposite side of the card we will see the following:
This spot is intended for back-up battery for the controller cache-buffer. This is the first time I see something like that on an IDE RAID controller.
The controller package doesn't include a cache-memory modules, unfortunately. Of course, it saves the experienced users some money as they don't have to pay for the default cache-memory module. But on the other hand, you will not be able to start your controller without the cache memory. I suppose it does really make sense to provide a cache memory module, at least of the minimal capacity possible: 16MB.
| Promise SX6000 | |
|---|---|
| Controller type | PCI 2.2 Card |
| Core I/O Processor | 100MHz Intel i960RM |
| Cache Memory | 16-128MB 168pin DIMM SDRAM ECC/non-ECC |
| PCI Bus | 32bit / 33MHz |
| UltraATA/100 | up to 6 UltraATA/100 drives |
| Drive type | UltraATA/100/66/33 |
| ATA RAID Levels | 0, 1, 0+1, 3, 5, JBOD |
| RAID Stripe Block size | 4-64KB |
| Operation System | MS Windows NT4/2000 RedHatLinux 7.0/7.1 TurboLinux 6.0/6.1 SuSe Linux 7.0/7.1, etc… |
Well, SX6000 controller is equipped with a faster XOR processor (i960RM - 100MHz), than SperTrak100 (i960RM - 66MHz). It features faster cache memory, supports hard disk drives with over 137GB storage capacity (surprising that they don't have ATA/133 support, since PDC20276 chips support ATA/133 as a whole and not only BigDrive specification).
The controller can perform HotSpare (automatic replacement of the failed drive in an array with a reserve one), and HotSwap (if there are Promise SuperSwap chassises connected to the controller card).
The only concern is the absence of PCI 32/66MHz support. promise products do already support this bus. Take for instance, Ultra100 TX2, FastTRAK100 TX2, Ultra133 TX2, SX2000...
When I tested the controller, there was only one driver version for SX6000 available:
However, it worked fine and I didn't have any problems installing or running it.
The controller came with Promise Array Management utility (PAM):
It allowed managing the array remotely (or locally) that is to create, delete or rebuild.
I wouldn't say that its interface is convenient for a "non-administrator", however, it fulfils its functions quite alright. The access to arrays managing is provided only by password, so there is no need to worry that some bad guys will get in :)
Our testbed, the one you saw on the photo above, was configured as follows:
To build arrays I used 6 IBM DTLA 307015 HDDs. So far we didn't have the opportunity to see how SX6000 will work with HDDs of larger storage capacity (over 137GB).
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:
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 controller was tested with 32MB PC100 SDRAM memory module with 2-2-2 timings. We didn't check the dependence of the controller performance on the cache-buffer size this time.
Of all Winbench99 results, I will offer you only Business Disk Winmark, High-End Disk Winmark and linear read speed in the beginning and in the end of the drive.
| DTR: Beginning | Graph | Graph | Graph | Graph | Graph | Graph |
As we see, the highest speed was obtained in RAID 0 of 4 HDDs, and with the increase in the number of HDDs in the array, this value got a little bit lower. At the same time, we can't help pointing out that the array speed is lower than that of a single IBM DTLA 307015 with a regular UDMA100 controller.
| DTR: Beginning | Graph | Graph | Graph | Graph | Graph | Graph |
RAID 1 speed is almost as high as that of a single HDD, and RAID 3 performance reached its top with 4 hard drives involved.
I have to note that in case of RAID 1, the reads are most probably performed only from one HDD of a pair.
| DTR: Beginning | Graph | Graph | Graph | Graph | Graph | Graph |
Unfortunately, the controller performance in WinBench99 tests is extremely low. The linear read graphs show that the entire work with the array is carried out via a relatively small cache, which doesn't let the array perform adequately to the HDDs speed.
And now come the NTFS results (brief):
IOMeter results will be also presented in a very compact and easy to view form: only Total I/O (i.e. the number of requests processed by the controller):
We will analyze the whole thing a bit later on the diagrams. And now have a look at the results for RAID 1 and RAID 3:
And now it's high time to make a few graphs showing the dependence of the number of processed requests on the amount of HDDs in the array for each pattern:
Very interesting situation. Look, RAID 1 array works as fast as RAID 0 of two HDDs. In other words random requests for RAID 1 array are alternated by the controller between both hard drives. A slight gap between RAID 01 and RAID 0 is also quite impressive. Though the behavior of the RAID 3 array is still pretty unclear: the performance grows as the number of HDDs in the array increases, however, this growth slows down significantly once the sixth hard disk drive is connected.
Well, the situation repeats almost identically, though the results here a little higher. RAID 1 fell a bit behind RAID 0 of 2 HDDs. RAID 3 got "sate" by 5 HDDs.
See what happened to RAID 3 when the number of writes increased up to 33%! The performance of this array stopped growing by the fifth hard disk drive already.
The interesting thing is that RAID 1 array results do not beat the single HDD speed any more. The write requests are processed for both HDDs of the array and no "speeding up" is possible.
The situation with RAID 3 and RAID 5 arrays is simply dramatic. RAID 3 structure allows it to slow down to the single hard disk drive speed, though in case of RAID 5 the controller could have worked a bit faster, I suppose.
Here is an example of excellent operation: perfect scalability for all array types. Thought he absolute performance rates are not that high. For RAID 0 the controller wrote 6MB/sec onto each of the connected hard drives. What could we say about all other arrays then…
In this pattern the controller performance proves that Promise optimized its product for work with random read requests. RAID 1 and RAID 01 performance rates are higher than those of RAID 0!
The controller works with RAID 5 as fast as with RAID 0, and the graph for RAID 3 is just the same as that for RAID 0 but with a 1 hard drive shift (the one that stores the checksum in RAID 3).
In this pattern we see very clearly for the first time that several array types get sated by four HDDs already. They are RAID 0, RAID 3 and RAID 5. However, the speed is quite fast then: 62-68MB/sec.
It's funny but RAID 1 again slowed down to the single hard drive performance. Maybe the controller firmware doesn't allow reading from two HDDs of the array simultaneously in case of read requests like that. It's a pity…
Anyway, RAID 01 performed really successful.
Let's find out how greatly the controller performance will grow (if it will grow) when the stripe-block size is increased gradually. And how greatly this performance growth depends on the commands queue depth. For our investigations we resorted to RAID 0 array of 4 HDDs.
The current SX6000 controller firmware allows changing the stripe-block size in the interval from 4KB to 64KB, so that there are only 5 possible values to be selected: 4KB, 8KB, 16KB, 32KB and 64KB.
The first diagram depicts the dependence of controller performance in all the patterns when the queue depth is equal to 1.
No doubt that RandomWrite and SequentialWrite patterns react best of all to the stripe-block size increase. The least influence is imposed upon the controller performance in RandowmRead pattern.
I have to note that in two Sequential patterns (SequentialRead and SequaentialWrite) the maximum performance can be reached when the stripe-block is 64KB big. Well, everything is correct: we have a four-HDD array and the data pack in this pattern makes 256KB. This way, each HDD receives 64KB when processing each request. In this case the controller doesn't split the data pack into smaller bits, but it overloads its internal bus and adds more difficulty to the hard disk drives operation.
FileServer, WorkStation and DataBase patterns get noticeably revived, however, the RandomRead pattern appeared even more sensitive to the stripe-block size. Well, when the requests queue increases the controller can choose the most optimal order of processing them. In this case some requests take a bit longer to get processed (as they are moved to the very end of the queue), however, the average requests processing speed increases.
The increase in the requests queue depth proves once again the discovered regularity. In the patterns based on random requests the stripe-block size as well as the commands queue depth influence the performance. The Sequential patterns are nearly indifferent to the commands queue depth, so that the controller speed in these patterns depends mostly on the stripe-block size.
It's a pity that the current controller firmware limits the maximum stripe-block size by 64KB, especially, since our experiments showed that the array performance could keep growing once the stripe-block got bigger as well.
To check if the controller is capable of rebuilding an array if any of the HDDs fails, we imitated some emergency cases in the following types of arrays: RAID 1, 01, 3, 5 (for RAID 01, 3, 5 we took four HDDs to built an array).
I ran Intel IOMeter and after a few minutes disconnected the power from one of the HDDs and then removed it from the chassis together with the rack. In a while, when the disk array started working quite stably in emergency mode, IOMeter was interrupted, the hard drive returned to its place and got the power.
I measured the time, which passed from that very moment until the HDD array got completely rebuilt.
The arrays rebuild took:
The array rebuild lasts well over 45 minutes when it occurs under workload.
Promise SX6000 controller proves pretty fast in our tests and managed to outperform its predecessor - SuperTrak100 controller. It outperformed the latter in all terms, in all sorts of configurations and in all patterns. SX6000 controller also appeared quite scalable depending on the number of HDDs connected to it, which was not the feature of SuperTrak100.
Another advantage of our hero is perfect price-to-IDE ratio. 6 channels of only one Promise SX6000 controller allow creating two fault-tolerant arrays combining beautiful performance and high storage capacity (RAID 3 and RAID 5) or three RAID 1 arrays, which enlarges the market niche for this controller.
Among the drawbacks I would like to mention low processing speed in case of sequential requests and quite low performance of all arrays in WinBench99 tests.
