Interface Overkill: Analysis Downloads And Additional Results

This blog post references my cover story 'Interface Overkill? Is eSATA Necessary For Your Next System Design?' in EDN's May 10, 2007 edition. It's one of a series of web addendums to the print writeup.

First off, this ZIP file, with the files inside it subdivided by means of an archived directory structure, contains all of the raw data I captured in this project (a subset of which turned into the print article's Tables 1 and 2). I've included both the report files generated by SiSoftware Sandra and JPG versions of the screenshots I captured of the utilities' results, so you can see how the referenced storage interface/device combination compared against other storage interfaces' and devices' results data included with Sandra.

Before discussing the additional results I obtained subsequent to submitting the print article draft, I'd like to first explain Silicon Image's SteelVine storage appliance in more detail. Sorting out the problems I encountered, as briefly described in the print article, took several weeks and several conversations with several individuals. If I found the situation confusing, I suspect you did too!

As mentioned in the print article, the ASUS L1N64-SLI WS motherboard in the system I used to conduct my testing contains a Silicon Image Sil3531 single-lane PCI Express eSATA transceiver. The BIOS for the Sil3531 is integrated within the system BIOS. I also attemptedto use a Silicon Image SiI3124 eight-lane PCI Express eSATA add-in board, containing a PCI-X transceiver and PCI-X-to-PCI Express bridge chip. The BIOS for the SiI3124 is stored in a nonvolatile memory chip on the add-in board.

If you scroll through the file downloads available for the Si3124 and Sil3531 on Silicon Image's (byzantine, IMHO) support website, you'll find several sets of BIOS/driver combinations: system BIOS, BASE, and SATARAID5. The first one, as its name implies, is intended for Silicon Image's motherboard partners to integrate into their system BIOSs. It's what ASUS, for example, included within the L1N64-SLI WS motherboard BIOS in order to support the Sil3531 transceiver.

The BASE BIOS/driver add-in card combo is intended for use in non-RAID applications, as well as with storage peripherals (such as the SV2000) that contain their own storage processors (such as Silicon Image's SiI4726 and family follow-ons). To configure the SiI4726 and thereby configure the up-to-five HDDs also contained within the SV2000, you'd use Silicon Image's SV2000 Manager utility.

Conversely, the SATARAID5 BIOS/driver add-in card combination is intended for software RAID applications; i.e. those in which the RAID software stack runs on the PC's system processor versus on a dedicated storage processor such as the SiI4726. As its name implies, it supports RAID 5 mode in addition to JBOD, RAID 0, RAID 1 and RAID 1+0; conversely, the SiI4726 does not support RAID 5 mirroring-plus-striping. I ran the companion SATARaid5Manager utility for the SV2000 testing that appeared in print.

The BASE-versus-SATARAID5 distinction was, I confess, unclear to me until after I'd completed my first round of testing. However, judging from the fact that I obtained a full set of SV2000 results with the Sil3531, I must have installed the SATARAID5 driver suite for that particular eSATA transceiver, and its BIOS support integrated within the L1N64-SLI WS system BIOS must be SATARAID5-cogniscent. Fortunately, since both the Sil3531 and the SiI4726 are port multiplier-aware, and since the SiI4726 is by default in JBOD mode, I was able to configure the SV2000 via SATARAID5Manager.

So why couldn't I obtain a full set of SiI3124 results? Although that particular eSATA transceiver is also port multiplier-aware, I suspect that the add-in board currently only has a BASE BIOS installed, and/or I inadvertently only installed the BASE driver suite for it. SATARaid5Manager therefore was unable to 'see' the SiI3124, and I could therefore only operate the SV2000 as a set of five contiguous HDDs, with per-drive partitioning and formatting handled via Windows XP's Computer Management utility (via the Storage/Disk Management sub-utility).

Future SV2000 evaluation plans, as personal bandwidth allows, include:

• Re-test the Sil3531-and-SV2000 pairing, this time with RAID configuration and management handled by the SV2000 Manager utility, if the Sil3531's system-resident BIOS allows for BASE functionality (Silicon Image isn't sure if this is possible). This'll also require that I de-install the existing Sil3531 SATARAID5 driver suite and replace it with a BASE equivalent.
• Ensure that I have a BASE BIOS and driver suite loaded for the Sil3124, then use the SV2000 Manager utility to enable testing of SiI4726-controlled 'concatenated' (JBOD), 'striped' (RAID 0), 'mirrored' (RAID 1) and 'mirrored striped' (RAID 1+0) modes.
• Reset the SiI4726 to its default JBOD mode, replace the Sil3124's BASE BIOS and driver suite with their SATARAID5 counterparts, and re-test the SV2000 this time with JBOD, RAID 0, RAID 1, RAID 1+0 and RAID 5 management handled by the AMD CPUs in conjunction with the SATARAID5Manager utility.

Continue reading with 'Interface Overkill: FireWire Quagmire'….