Testbed and Methods

Our testbed was configured as follows:

• Intel SC5300Base system case
• Intel SE7520BD2 mainboard
• Two Intel Xeon 2.8 processors (533MHz FSB)
• 2 x 512MB PC2100 ECC Registered DDR SDRAM
• IBM DTLA 307015 hard disk drive
• Onboard ATI Rage XL graphics controller
• Windows 2000 Pro SP4

We tested the controller in FC-Test 1.0 build 13 and IOMeter 2003.02.15. IOMeter was used to check the controller’s ability to process sequential requests to read/write data blocks of a varying size and to measure the controller’s speed in the Database pattern that consists of SQL-like requests. The performance of different arrays was compared in File Server, Web Server and Workstation patterns.

For FC-Test we used our five standard file-sets (Install, ISO, MP3, Programs and Windows) which we wrote to the array, read from it and then copied.

The LSI MegaRAID SATA 300-8X controller worked with firmware FW_813l and version 5.49 drivers. It was installed into a PCI-X/133MHz slot. The WD740GD hard disk drives (Raptor) were installed into an AXX6SATADB rack (SATA 6-Hot-Swap Drive Bay Upgrade Kit). We performed our tests on four drives only, so we didn’t examine RAID50 arrays.

The controller’s settings would take a whole new review to describe. LSI’s SATA controllers come with a very powerful BIOS that offers a staggering amount of various settings that are hard to learn the particulars of even if you’ve got the documentation. Most often we just carried out a series of experiments to pinpoint a new bottleneck and it took a huge amount of time, but eventually we settled on the following combination of settings:

We set the stripe size at 64KB for RAID0 and RAID5 arrays. The controller comes with a large cache buffer so we gave it a chance to show its ability to predict the nature of requests to the arrays by selecting “Adaptive Read Ahead” as the Read Policy.

We also permitted the controller to perform lazy writing to the array using the cache memory. Lazy writing was permitted for the disks, too, in another section of the controller’s BIOS.

The controller’s Cache Policy was set at “Direct”, but as we learned from our experiments, this menu item has a very little, if any, effect on the controller performance.

We call these the “maximum performance” settings since we only had time to explore the biggest the controller could do.

Of course, you may want to prohibit the drives to do lazy writing in order to improve reliability of the disk subsystem or to set the Read Policy setting at “Normal” to improve the controller’s speed in web-server mode, but it’s just impossible for us to test each and every possible combination of settings.

So we tested the controller at the max-performance settings, and let those who can do more! J

As an illustration of the hard life of a hardware tester: we didn’t have an LSIiBBU01 battery at first and the controller wouldn’t work with Write Policy = Write Back, which was wise as concerned keeping the data on the array safe. More exactly, the controller did allow setting Write Policy at “Write Back”, but this setting only worked until the next reboot of the server! Our test methodology implies frequent system reboots (the test script begins with a reboot command!) and we spent several days just trying to find why the controller’s performance remained the same with Write Back and Write Through caching!

So we performed two full test cycles, browsing through all possible types of arrays that could be built out of four hard disk drives.

The modes with enabled and disabled lazy write of the controller are referred to as WriteBack and WriteThrough, respectively. The numbers in the tables refer to all modes, but the diagrams for WriteThrough mode were only built for the four-disk arrays and only in IOMeter tests.