Unified Serial RAID Controllers for PCI Express

Toggle sidebar Toggle sidebar
Consolidation for sure. A couple short years ago there was quite a buzz about Storage Processing Units on raid controllers but try to find one now. Perhaps they were ahead of the market they were aiming at, i.e. media servers or perhaps the on-board MB controllers and the new large capacity drives ran over them.
 
The idea of using energy efficient 2.5" drives in raid farms for higher density sounds great indeed, but with pretty much every server case using 1" hotswap bays for 3.5" drives, there's going to have to be a major redesign in the industry - procuring an army of 2.5" to 3.5" adaptors just defeats the purpose.

I've seen this neat device -http://www.scsi4me.com/enhance-q14ss.html- that lets you use 4 2.5" drives in a single 5.25" bay, but that won't work with enclosures with 1" hotswap cages such as a 5U/24-bay or 3U/16-bay server chassis.

You can still get 4U/5U cases with 8-10 5.25" bays to fix the solution short term, but what would work best is a 3U/24-bay or 2U/16-bay chassis that lets you hotswap 2.5" drives directly.

I would also hope that as 2.5" drives gain ground, their prices will go down.
 
Corrections:
- SATA is half-duplex providing only 300mBps bandwidth per port
- 3gb SAS provides 600mBps bandwidth full duplex per phy
(Kind of a big performance difference for read/write traffic patterns)
- SATA is a dedicated Point-to-Point protocol. It is NOT switched. (STP protocol of SAS allows SATA tunneling through a switched SAS expander network)
- Where did you hear about 12gb SAS??? Not on any serious road maps that I've heard of. Link plz? Only really useful for interswitch connections. AFAIK there is currently no drive than can come close to saturating a 3gb link. (*edited* to reflect SAS 2.0 connection multiplexing capabilities)
- You can't connect a SAS HD to a SATA controller. It won't work. No cables that I've seen make it physically possible but even if you did a SATA controller cannot talk to a SAS HD. They could wake the link and be aware of eachother but they wouldn't even be able to even do speed negotiation much less transmit a dword as speed negotiation comes before any actual data is transmitted and after COMSAS and even if you did find a way to trick them into skipping COMSAS and doing speed negotiation SAS drives don't understand ATA, they only do SCSI.
- A SATA HD will have no problem connecting to SAS Cables to connect to a SAS controller. They even make SAS wide-port cables that have multiple SATA connectors on the other end.
- A SATA data cable will not fit on a SAS drive
- A "fan out" and "edge" expanders are specific devices defined in SAS 1.0 so you should not use those terms casually when talking about SAS. SAS 2.0 expanders only have one type.
- SAS connectors are exactly the same size as SATA data + power connector and will fit fine on a 2.5" drive

...I stopped reading at this point (top of page 3). If you would like me to proof the rest of your article let me know but I want credit for it. Now I must get back to gearing up for EVT testing a forthcoming SAS expander :)
 

Regardless of throughput performance there is also latency, and a 12Gbps link is able to transmit data faster than a 3Gbps link. Let's do some calculations:

ATA66: transferring 2MB takes 30,3ms
SATA150: transferring 2MB takes 13,3ms
SATA300: transferring 2MB takes 6,7ms
600MB/s: transferring 2MB takes 3,3ms
1200MB/s: transferring 2MB takes 1,7ms

As you can see the interface imposes a propagation delay and thus latency on the I/O stream. Now normally this is not significant, yet in blocking I/O (database reads for example) it is. It would wait until the data reaches the RAM and the total latency also called service time is what counts, not the throughput.

I've not tested the effects of interface bandwidth on such applications though, but i would like to. If the differences are any significant (higher than 2%) i would like to say interface bandwidth should always stay ahead of throughput performance of the physical disks. Besides there's always the cache transfers which can transfer at much higher speeds. Especially with SSD/hybrid disks coming. I believe an interface should never be a bottleneck - like PCI is now and Parallel ATA still is today with 2 disks in a RAID sharing the cable.
 
SAS uses 1k frames so a 2mb transfer isn't going to show latency differences, it will show bandwidth differences. You're actually right, I had just come back here to post a correction, but your explanation is off. The reduction in latency has almost no effect. In a transactional database seek time and arbitration is what's holding it back for the most part and for a large block transfer the reduction becomes dwarfed by the time it takes to do the transfer itself. That's why the 150mbps Raptor was faster than any of the 300mbps SATA HDs for so long.

SAS can do connection multiplexing. So a 12gb SAS HBA could talk to 4 3gb SAS drives simultaneously on the same phy. This doesn't *really* improve performance though, it just lowers cost as, theoretically, a single 12gb phy link would cost a lot less than 2 6gb phy links (especially as you multiply that down a few shelves of drives). I still haven't seen 12gb on any official time tables though... I haven't looked very hard either though. With connection multiplexing it makes a lot more sense though for interswitch connections.
 
SATA is physically a full-duplex link, at the electric level.
It does run in essentially half-duplex mode when without NCQ (request-response).
With NCQ, I would believe it qualifies for for the "full duplex" label.
Unless there are some deep-down details that counter this simple reasoning
and that enforce some sorta half-duplex-style "collision avoidance"
on the genuine full-duplex link 🙂

"Unified Serial" seems to be a marketing label used by Adaptec when referring
to its recent family of SAS controllers, all of them featuring the SFF-8087/8088
connectors including standard sideband/SGPIO. Namely the ASR-3405, 3805,
3085, 31205, 31605. It's an Adaptec product family name.
This is to distinguish them from the first-generation SAS controllers,
such as the 4800/4805, with the older SFF-8484 flat plastic multilane connectors.

12 Gbps SAS is a reality. Or speak about 1200 MBps if you will.
There are external RAID controllers and RAID units on the market,
with SAS-based host channels (SFF-8088 connectors). In this case,
you connect the HBA to the SAS target using a single point-to-point
x4 multilane cable, and the load is spread across all the 4 lanes within
that cable. This is how the external RAID controllers (I know about
AXUS/Areca) can achieve throughput of about 800 MBps without
multipath IO or host-based software striping.

A SATA-only cable connector should be keyed in such a way that
a SAS drive won't fit in. For a thorough illustration and description
of the differences between SATA, SAS single-port and SAS dual-port
connectors, check this slide-show, page 12:
http://www.scsita.org/aboutscsi/sas/tutorials/SAS_Physical_layer.pdf
The illustration published at THG misses the flip-side additional pins
needed for the optional second SAS port (for dual-port disk drives).

Yet it is technically possible to attach a SAS drive to a SATA-II controller.
There are universal passive SAS/SATA backplanes that take both
sorts of drives, e.g. from SuperMicro. You can connect the backplane
to a SATA-II controller that has native multilane SFF-8087 SAS
connectors or even individual SATA ports (using an octopus cable).
As someone has already pointed out, it won't work at protocol level.
SAS controllers are backwards compatible with SATA drives, owing
to a legacy SATA mode at the HBA side. It doesn't work the other way
around, the native SATA-II HBA chips (such as the venerable Marvell
88SX6081) just don't have the protocol stack required to talk to
a SAS disk drive (which is not backwards compatible with SATA).

I've heard rumors that Adaptec Unified Serial RAID controllers
couldn't talk to SATA drives if interconnected via an LSI expander
(i.e., via an expander-based active backplane), because the
SATA tunnel mode was defunct in that setup. This information
is somewhat untrustworthy, potentially out of date etc.

 
I actually own this card. I have it attached to a Supermicro SC933 Enclosure with dual LSI Expanders. The chassis is populated with 15 SATA drives and it works fine.
 


http://www.supermicro.com/downloadables/pdf/Supermicro_SAS_LinuxWorld.pdf
page 3
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom