In order to test the controller’s ability to ensure proper data security if one of the array drives fails, we modeled this emergency situations for HDDs of RAID 1 and RAID 01 arrays.
Just like in our Intel SRCS14L Four-Channel SerialATA RAID Controller Review we imitated the HDD failure by disconnecting the SATA power cable from the drive. The array status was monitored with the help of PAM (Promise Array Management program).
In about a minute after the “failure”, PAM reported this fact and changed the array status from “Functional” to “Critical”. In order to avoid annoying the people around me (the program started emitting a very irritating beeps), I restored the power supply immediately. After that the program started restoring the array. I suppose that it is not quite correct: what if I used the same failed drive again?
Restoring the arrays under workload (when the controller not only checks the data integrity and restores the lost data, but also processes the users’ requests) usually takes a lot of time. I decided not to waste so much time. Therefore, the additional controller workload was eliminated (I terminated the running test) and measured the time it took the controller to restore the array completely.
It took the controller half an hour to restore RAID 1 array, while RAID 01 array needed a little over an hour.
According to the benchmarks results, Promise FastTRAK S150 TX4 controller is an excellent product. However, despite the overall great impression, we need to be objective to the end, that is why let’s recall the controller’s behavior in all considered tests.
DataBase: The controller demonstrated excellent performance scalability of RAID 0 arrays depending on the number of hard disk drives used, and excellent performance of RAID 1 and RAID 01. At the same time under moderate workloads in case of pretty low write shares we observed a “stepping” effect on the graphs. Besides, the RAID 01 array could suddenly start losing its speed… All this means that in these modes some algorithms of the controller driver get activated and try to optimize all ongoing requests. All in all, these algorithms seem to be set for different type of workload.
By the way, since we came to speak about the settings. It suddenly occurred to me: why don’t RAID controller makers make it easier for their own software developers by creating presets in the controller drivers just like we see in the drivers of some graphics cards? Why should they load the driver with a hard task of deciding what type of workload is currently involved, if it can be simply set in the driver?
Well, after I tried to imagine the settings pages of FC-test and WinBench99 I almost gave up the idea… But back to our Promise controller and its performance.
SequentialRead and SequentialWrite: The controller performed very fast only when working with RAID 0 arrays. Unfortunately, it slowed down as it came to RAID 1 and RAID 01.
FileServer and WebServer: The controller was beyond any competition. Brilliant speed of the arrays with reserved data is worth mentioning separately. Although we have noticed some strange performance drops in case of RAID 1 array working in FileServer pattern with 16 requests queue.
WorkStation: The controller proved pretty fast here, although large share of writes didn’t allow the controller to show its very best in RAID 1 and RAID 01.
In WinBench tests the controller also proved highly scalable when working in RAID 0 arrays, while RAID 1 and RAID 01 didn’t demonstrate anything special.
All in all, the benchmark results indicate that this controller is a great solution for small servers, rather than high-performance workstations. Although the only problem we faced during this test session, namely low linear erad speed in some testing modes, could have been the result of the controller’s incorrect functioning when installed into PCI-X 133MHz slot.
We will continue keeping an eye on the BIOS and driver updates!