cheap scsi raid?  good luck.   maybe something on ebay, but then its Caveat Emptor, and likely the raid batteries will be dead or dying.

What speed is your scsi backplane?  you can't get Ultra/320 speeds across older backplanes that were designed for U80 or U160 speeds.  in fact, I've had a few backplanes that were supposed to be U320 but only worked reliably at U160 speeds, would get SCSI protocol errors when pushed under high IO loads at U320.     64bit 33Mhz PCI will sustain about 200MB/sec, which is about all you can get out of a single channel of U160 or slower SCSI anyways.

In that case there's no real point upgrading. :-) The drives are U160's.

I was just hoping a slightly newer card might be available that'd give me a speed boost for cheap. :-)

The key is the backplane, not the drives. You should be able to get u320 speeds if you have enough u160 drives.

Does five drives count?

...

I was just hoping a slightly newer card might be available that'd give me a speed boost for cheap. :-)

Again, like John posted, it depends on whether your backplane(s) can feed the u320 card and whether its bus can take the bandwidth.

AFAIK, the back plane is rated at U320 speeds. The unit is a Supermicro CSE-M35S (SCA) which is listed as a U320 rated unit.

On 04/09/11 8:11 AM, Christopher Chan wrote:

On Saturday, April 09, 2011 10:47 PM, Drew wrote:

...

...

The key is the backplane, not the drives. You should be able to get u320 speeds if you have enough u160 drives.

Does five drives count?

I guess that depends on whether they can flood an u320 bus. If they are 10k/15k rpm drives, I'd think so...

Ummmm. say huh? if any one device on a SCSI channel is U160, the whole channel has to run no faster than U160, thats all she wrote. its a single bus not a 'star' like SAS or SATA.

On 04/10/11 3:09 AM, Christopher Chan wrote:

OH, is that how those babies work? The backplane is not using a controller chip that mutiplexes the stuff? Oops, sorry.

The backplane typically has a SAF-TE (SCSI Accessed Fault-Tolerant Enclosure) chip which provides backplane management services, like notifying the raid controller or host software when devices are inserted or removed, as well as controlling device power, monitor enclosure environment, etc. In fact, SAF-TE itself is a SCSI device on the same backplane.

Now, SAS backplanes do have multiplexers. One of the big functional[*] differences between SAS and SATA is that SATA only supports a simple expander where 1 SATA channel can be expanded to several devices, whereas a SAS multiplexor allows N SAS channels to talk to M devices. N is often 4, and M is usually the size of the drive tray. With the SATA version, if you had 4 SATA channels each exanded to 4 drives for 16 drives total, drives 0-3 would always talk to SATA channel 0, drives 4-7 to SATA 1, etc. with SAS, any channel can talk to any device, so you are less likely to run into bottlenecks

[*] For the purpose of that description, I am ignoring the big implementation difference in that SAS uses SCSI commands to talk to drives, while SATA uses IDE/ATA derived commands. Another significant functional difference, SAS drives are commonly dual ported, so they can be connected to redundant host bus adapters or raid controllers, so if a controller fails, all devices are still addressable. SAS controllers are designed so they can talk to SATA drives, but SATA controllers can't talk to SAS devices.

On 04/09/11 7:08 AM, Christopher Chan wrote:

...

In that case there's no real point upgrading. :-) The drives are U160's.

The key is the backplane, not the drives. You should be able to get u320 speeds if you have enough u160 drives

SCSI (parallel) before U320 had a weak spot. the command and status phases of a SCSI command execution were stuck in asynch mode, only the data transfer phase could use synchronous ('fast', 'ultra', etc). Async SCSI is the old original 3-5Mhz mode, which on a wide bus means 6-10MB/sec. This wasn't a big problem with the original Ultra Fast Wide 40 and Ultra 80 low voltage differential modes, but when SCSI hit U160 it became a potential bottleneck, especially for high rates of small block random IOPS on raids with more than a few drives.

IIRC (rusty neurons), a SCSI command takes 16 bytes or so, and a status query takes 4-8. at the typical async 3Mxfer/sec, that means a command takes like 5 microseconds. In 5 microseconds at U160, you could have transferred 5*160 or 800 bytes, and a single status poll cycle takes another 16-200 bytes, or pretty much 1000 bytes total, eg, for every IO operation on the SCSI bus, you lose 1KB worth of potential data bandwidth... So if you're executing 1000 IOPS spread across 4-6 drives, you're losing at least 1MB/sec of your channel's bandwidth potential. in reality its several times worse than this due to the additional overhead of getting on the channel and the typical multiple polling cycles required to complete a transfer, I've calculated its as bad as 10% under heavy IOPS random multiple drive raids

U320 supports synchronous command and status, so its way more than double U160 speeds due to the elimination of this overhead. Interesting side note, U320 controllers and U320 devices can support synchronous command and status even if its running at U160 due to backplane and cable loading issues.

thankfully, with FC, SAS, and SATA, these things are all history.