SAS vs SATA RAID performance on multiple spindles

"... all things are equal (i.e. same RAID controller, same drive RPM, same RAID configuration), how much performance increase in average read and write throughput is expected by simply changing from SATA to SAS drives? " ==> Short answer: None.

Longer answer: With drives of the same RPM, same buffer, and same areal density, the performance will, for all intents and purposes, be identical. The only difference would be if you have a large # of drives and multiple arrays on the controller, then the full duplex nature of SAS would provide some benefit if you had a write operation on one array at the same time as a read operation on another array -- providing these operations were on arrays on different physical disks, so there was no disk thrashing involved. But other than the full vs. half duplex isssue, there is NO significant electrical difference between SAS and SATA (SATA is in fact a subset of the SAS command set) ==> and the key performance driver is the performance of the drives ... which is essentially IDENTICAL for the two drives you've listed (in fact, the larger cache of the SATA drive will give it a very slight edge ... although that will make a VERY small difference in most operations).

There's more to the difference between SAS and SATA than the interface speed. Here are a couple of good articles to review:
From Seagate: More than an Interface: SCSI v ATA:  http://pages.cs.wisc.edu/~remzi/Classes/838/Fall2001/Papers/scsi-ata.pdf
From Microsoft: SATA in the Enterprise - use this Google search term: SATA in the enterprise site:microsoft.com  - the article you want is the first in the list.
The Seagate document tals about the physical and electronic differences between enterprise storage drives and personal storage drives. It makes very enlightening reading. The Microsoft document talks about the suitability of SATA for business-class workloads. Again, very sobering reading.

The upshot is that SAS is faster than SATA for the same reason that the drives are more expensive: each SAS drive has a processor that handles I/O and command queueing and re-ordering, and one processor that handles head tracking. Where you have multiple drives in an array, induced vibration from one drive affects all its neighbours and so on. A SAS drive can handle that because it has additional processing grunt to deal with the tracking issues. A SATA drive has a single processor to handle I/O and tracking. I'm sure you can see where this is going - the more I/O, the more vibration, the more tracking errors, the more processor power that is required just to keep the heads on track. You can see the result of this on slide 28 of the Microsoft document: performance drops from 120 IOPS to 20 IOPS for a SATA drive, but only 175 to 160 for a SAS drive.

Slide 21 shows the measured increase in failure rate of SATA drives used in enterprise environments.

For these reasons, for any random workload in an array of multiple drives, use SAS drives in preference to SATA - you can expect a 30-50% performance advantage. For sequential workloads, it's not so critical - there is less seeking, therefore less induced vibration, therefore the performance penalty of multiple SATA drives will be less.

This page: http://blogs.sun.com/brendan/entry/unusual_disk_latency contains a very good example of how vibration affects disk performance. You may have already seen a YouTube video called "Don't Shout at Your Disks" - this is the source. Worth a look.

The Microsoft presentation is comparing 7200rpm SATA drives with 15k SAS drives. While it's certainly true that SAS drives are built to more enterprise-grade standards, you can also get enterprise-class SATA drives. The two specific drives noted in this question are both Seagate ES class drives, for example; and have the same rotation speed, same areal density, etc.

The presentation does make a good point r.e. the rotational vibration issues if the drives aren't in high quality cabinets. And the onboard electronics can improve performance IF the RAID controller doesn't implement the drives' NCQ functions -- but virtually any good RAID controller will.

Both SATA and SAS models at 7200rpm are considered "near-line" storage devices -- the 15K drives are the only ones really considered appropriate for real-time transactional use ... and there's simply no SAS vs. SATA choice in that market -- the 15K drives are all SAS (or SCSI) ... I believe this is because when you get to that level of performance the SCSI command features (whether parallel SCSI or SAS) need to be onboard the drive to eliminate any performance bottlenecks.

SAS is clearly a "better" interface ... but I don't think in a 7200rpm drive configuration there's enough difference in performance to warrant the added cost. You will, however, get MUCH better performance with 15k drives -- and there's no choice but SAS (or parallel SCSI) for that level of performance.

Agreed on the interface speed - but the difference in performance even at 7200rpm is worthwhile for random workloads. SATA NCQ is not as fast as SAS NCQ and command re-ordering which is where a lot of the performance gain comes from as queue depths increase (vibration issues aside).

I have no hesitation is recommending SAS drives above SATA for a random workload - virtualisation platforms, databases, Exchange and the like purely for performance. The performance advantage has been borne out through personal experience in implementing this stuff. For sequential workloads, (backup to disk, media streaming etc), SATA is the better choice.

No, SAS will easily outperform SATA with transactional workloads (high volume, random access workloads) -- but until the IOPs get above ~ 75  there's no notable difference between SAS and SATA performance on drives of the same basic specification.     So as meyersd noted, "you get what you pay for."

My earlier comment was focused on the interfaces -- the discussion since is on the performance differences between the drives.   As meyersd noted, the SAS drives have onboard processors that can do much more sophisticated command reordering than the simple NCQ functions on SATA drives.   These can (and do) notably improve performance when there are large numbers of IOPs.

The bottom line:   It really depends on how the system is being used.   If there are a lot of large data transfers that saturate the bandwidth with relative small numbers of different I/Os per second, then SATA is best.    If there are a large number of IOPs, then SAS will outperform.

As for the original question -- "... what % performance increase is there going from SATA to SAS drives in a RAID array ..."  ==>  there's no really concrete answer to this, as it could be anywhere from NONE  (the interface-based answer)  to  perhaps a doubling of performance for very active transactional environment.    What IS true is that SAS will perform better ==> and in most cases the comparison isn't apples-apples (as in the two essentially identical drives noted in the question), but is comparing 7200rpm SATA vs. 15000rpm SAS ... in which case there's a BIG difference even in the basic drive specifications.

It all boils down to the comment above, which is worth repeating:  "You get what you pay for."

Expanding on andyalder's comment...

ES.2 SAS drives may use the SAS interface, but those drives are not on the same performance level of what is typically considered a SAS drive.  When referring to a SAS drive it usually means an enterprise class server or workstation drive (at least in my mind, consensus?) - drives like the HITACHI Ultrastar 15K300.  The drive costs around $1/GB, but will sail past almost every SATA drive in any given situation (not to mention superior reliability).  

A raid 5 with 8 1TB drives?  How large of a SAN are attempting to create?  If you really need 7TB take the performance hit and use SATA drives - it'll cost over $6k in drives alone as opposed to $1500 for SATA.

What will typically be written to these drives?  Perhaps using two array sets would be more viable...propose using SAS drives for frequently accessed or written data.  The SATA drives can be used for less intensive purposes such as backups, archiving, etc.  

As for the RAID controller, always opt for the SAS interface.  They typically don't cost must more than a comparable SATA controller and the option to upgrade is always available.  

It's not just 10K SATAs vs. 7.2K SAS vs. 15KSAS ==> it's also the "desktop" vs "enterprise" drives,  the "raid-enabled" versions, etc.     That's why it's really not possible to answer the "... what % performance increase is there going from SATA to SAS drives in a RAID array ..." question.     There are simply too many variables.    For example, Western Digital's RE series SATA drives have onboard dual processors that provide excellent command reordering ... and are very competitive with SAS drives of the same rpm;  Seagate's ES series drives have similar features.    Both have utilities that let you enable/disable TLER, which can make a big difference in how reliable they are for RAID environments.      The real distinction with SAS is the more stringent interface specifications, the higher degree of "intelligence" on the drive vs. the controller, and the higher speed components they use (which are important when using higher speed physical media like 15000 rpm platters).

Then there are the "vanishing specifications" ==> it's becoming more difficult to find the actual performance specifications of many drives.    WD describes their green drives rotation speeds as "Intellipower"  (meaning something between 5400 and 7200);  almost all the makers now list "average latency" as a spec (to show a nice low number -- like 4.16ms for a 7200rpm drive) => a meaningless number since it's always 1/2 the time for a rotation ... and thus the same for ALL drives of any given rotational rate;  average seek times are either not published or buried in a hard-to-find specification sheet;  etc.

I understand the desire to quantify the difference -- but the simple fact is that the SAS vs. SATA decision IS generally a 7200rpm vs. 15000 rpm choice ... so it's not an apples-to-apples comparison.

Having said that, there are a few factors that can be addressed:     The interface speeds are identical, but SAS is a full duplex protocol, so in a heavy transactional environment SAS will have an advantage.   Note, however, that the duplex channel is only for commands -- DATA cannot flow both ways, so this is only an advantage in high transactional environments where several commands can be queued during an ongoing transfer.   But for large file transfers, there's NO difference, since the sustained data rate will be identical for both IF the drives have the same operating characteristics (as you've assumed), and the impact of a saved millisecond or so for transmitting the next command sequence is irrelevant.

The Enterprise class SATA drives from WD and Seagate have onboard dual processors that implement many of the command reordering advantages of SAS drives -- although admittedly with lower queue depths (typically 32 for SATA, 256 for SAS ==> but real-world queue depths rarely exceed 8 to 10, so this is rarely a factor).

The rotational vibration issues discussed in the Microsoft presentation noted earlier can be real -- but are much less so in the Enterprise-class SATA drives, which are designed to the same tolerances as SAS drive.    In fact, the two drives you listed in your question are essentially the same drive with difference PCBs ... one for SAS and one for SATA.    I seriously doubt there would be ANY notable difference in two identical systems, one using the SAS version, the other using the SATA version of that drive.     This would NOT be true with desktop SATA units, which do not have the 2nd onboard processor, and are not designed with 24/7 enterprise tolerances.

... Note these details r.e. the Microsoft presentation:  (a) they're comparing desktop class 7200rpm SATA units with 15000rpm SAS units;   (b) the rotational vibration issue is again desktop SATA drives vs. enterprise SAS drives;  and (c) the error analysis is based on a 1 in 10^14 rate for the SATA drives vs. 1 in 10^15 rate for the SAS drives (the enterprise class SATA drives have a 1 in 10^15 rate).    You might note that the presentation was from 2005, and was co-presented with Seagate.     In 2005 Seagate had not yet entered the enterprise-class SATA market in any appreciable way -- whereas Western Digital had.    I suspect that MAY have had some influence on the focus of the presentation :-)

Bottom line:   The larger queue depth;  duplex command/data capabilities;  and more consistent enterprise-class tolerances do favor SAS for transaction oriented applications ==> but when comparing drives of identical specifications, enterprise-class SATA is very competitive.    Modern enterprise-class SATA drives are NOT appreciably outclassed by their SAS cousins of the same performance specifications.    HOWEVER,  the added features of the SAS interface make it more capable of handling the demands of the very-high-performance 15000rpm drives ... thus virtually all drives in this category are SAS.    So most SAS vs. SATA discussions really translate to 7200/10000rpm vs. 15000rpm drives ==> and in this case the faster drives win :-)

3) Our clients are very small businesses (typically < 25 employees).  Common sense says that a 1000 man company should not use SATA drives for an email store.  Likewise, most would agree that a 2 man company can live with SATA drives in a RAID 1.  How about 2 heavy users?  5 light users?  10?  50?  The line where SATA drives are no longer acceptable is a quality assessment, based on the user experience (opinion-based) and performance statistics (fact-based).  I am looking for quantitative data to help my clients make qualitative assessments.

If you can project/guesstimate the number of I/Os per second, then you can take a pretty good stab at what you'll need. In my experience, a cheap-and-cheerful NAS with a pair of mirrored SATA drives (so you can extrapolate that to a small business server) chokes pretty early on with a random workload - say, one person reading large files because they've sneaked their iTunes library on there, one person working on office documents, another person copying their iTunes library and dodgy movie collection to the shared drive etc etc. The conflicting workload types hit the SATA drives where they're weakest; processing a highly random workload. The work-around is to either use faster drives, such as SAS, or a larger number of SATA drives. In fact, I've been seeing this more and more and more - both SCSI and SATA drives in SAN arrays are now so large, many people make the error of sizing the array on the amount of storage they need and end up with way to few drives to handle the performance they require. For example, you may need 5TB for your shiny new virtualisation platform and that's covered off by 6 1TB drives in a RAID 5 set. Those 6 drives will give you about 480 IOPS (80 IOPS per drive). But 5TB of VMware could potentially have more than 150 virtual machines, each demanding a slice of the available performance - which works out to 3.2 IOPS per VM. Bzzzzzzzzzt! Thanks for playing. Although this is much bigger than the example you've given, a typical workplace of 50 -100 seats with 12 servers with the usual mix of SQL, Exchange and so on is generating over 1200 IOPS. Once again, Bzzzzzzzzzzzt! Thanks for playing. There is no way that 1200 host IOPS will fit on 480 IOPS of disk performance. Which leads to a discussion of parity RAID write penalties. The penalties matter to you because you will end up deploying RAID 5 or 6 at your customers, and it directly affects the number of disks you need to service the load. So. For every host write operation, you generate 4 operations at teh disk fro RAD 5 and 6 for RAID 6. t works like this:
1. Read original data
2. Read original parity
Generate new parity from original data, original parity and new data
3. Write new parity
4. Write new data.
This process is true for *any* parity RAD schema. RAID 6 generates an extra 2 I?os per write because it has to deal with the second/redunant parity block. Some RAID controllers and SANs have optimisations to reduce the overhead of these transactions, but in a random environment there is ni escaping them.

So - back to the example above. For 1200 host IOPS, lets assume 50% read, 50% write:
1200 IOPS =
600 R + 600 W
allow for RAID 5 write penalty =
600R + 600 * 4 W =
600 + 2400 = 3000 disc IOPS at the disks! Even worse:  4200 IOPS for RAID 6

If you are planning to use SATA drives to handle that load, you'll need 38 drives to handle the load. For SCSI, FC or SAS drives spinning at 10K rpm, you'll need 22, and 15K drives, you'll only need 15. For RAID 6, try 53 SATA drives, 30 10K drives or 21 15K drives. Ouch.

Incidentally, RAID 1/0 can be a load more economical than RAID 5. Here's why:
For every host write I/O, there is two I/Os at the disc to mirror the data, so the calculations become:
600 + 600*2 = 1800. So: 24 SATA drives, 14 10K SAS drives and 10 15K drives.

The point to that rambling discussion is that if you plan to use a parity RAID, then you should consider SATA drives, and you may want to add extra drives depending on what the server will be used for. A pair of SATA drives will cause you pain if you have more than a handful of users - better off to put SAS drives in when you're purchasing the server and negotiate yourself a stronger discount with the vendor (if you're dealing with HP, tell them the Dell reps been calling and vise-versa...  :-)). It will work out cheaper over the lifetime of the server than putting in SATA drives now and replacing them in 6 months when your customer outgrows the performance. Note that performance curves are asymptotic - once you exceed the available performance, response time of the drive rapidly increase and performance falls off a cliff. Nominal IOPS per drive are 80 for 7200rpm SATA (although I find that's usually a tad generous. I use 60 to be on the safe side for highly random workloads), 140 IOPS for 10K SCSI in all their various forms (SAS and FC) and 200 IOPS for 15K SCSI drives. A drive will typically deliver up to a little over twice the nominal figure before you're really in the poop, but response times will climb...

4) The purpose of asking for a "% increase" is twofold:
   a) I can easily calculate the % increase in price going from SATA drives to SAS drives.  I can also find price increase percentages for other hard drive performance factors (i.e. rpm, cache size, etc).  
   b) I can compare the ROI of moving from SATA to SAS drives, compared with other hard drive improvements.  Furthermore, I can compare the ROI of storage improvements vs other focus areas (e.g. improved network switches, CPU power, RAM, etc)

10K SCSI is 175% faster than 7200 rpm SATA
15K SCSI is 250% faster than 7200 rpm SATA
15K SCSI is 70% faster than 10K SCSI.

5) The affordability of a solution is ultimately a business decision, not a technical one.  We view our responsibility to provide accurate data on the costs and results of their choices.  Specifically, we have 5 man engineering clients who would call $6k for SAS drives 'petty cash' and worth doing.  We also have clients with 80 staff who couldn't justify an extra 1.5 TB desktop drive in a whitebox server for $150.  We prefer to say $$ for solution A, $$$ for solution B with an estimated % increase for the additional $, and let the client choose.

That all comes down to accurate sizing and the customer understanding what is going on in the server. I find myself white-boarding the whole performance thing frequently for customers so that they understand why we're quoting the number of drives that we do.

Agree with the performance numbers noted above (clearly "SCSI" is supposed to be "SAS" for this discussion).

But note that just as a 10K SAS drive is 175% faster than a 7200rpm SATA (when measured in IOPS ... and assuming the 60 IOPS is a good figure for the 7200rpm drive), a 10000rpm SATA drive is ALSO 175% faster than a 7200rpm SATA. The 10k Velociraptor starts at about 140IOPS and ramps up to 250 IOPS or higher with a queue depth of 16 !! [per the IOMeter results here: http://www.pcper.com/article.php?aid=548&type=expert&pid=10 ] And that's a single drive ==> use 5 or 6 of these in a RAID-5/6 array and you'll get the same results noted above.

As I noted before, it always boils down to comparing drives of different specifications (7200rpm vs. 10k rpm vs. 15k rpm) If you restrict the drives to an apples-apples comparison [e.g. 7200rpm SAS vs. 7200rpm SATA] the difference is MUCH smaller -- the SAS drive will still be the better performer ... but not by a significant amount unless the queue depths get larger than the SATA drives support (which is very unlikely).

Note that the issues discussed above r.e. having too few drives are real ... but more drives don't really eliminate them -- they just reduce their impact, since each I/O takes less time (since it's spread across more drives). Thrashing an array "drive" is just as bad as thrasing a single drive ==> that's why command queueing and reordering is so important in multitasking environments ... the I/O's are done in sector order, so the thrashing is minimized. Same is true for a single drive -- that's what NCQ helps with. The best solution to very high volume systems is to have enough DIFFERENT spindle sets (either via multiple servers or by multiple array sets using different physical drives) that the IO's are spread among the different spindles.

Holy-moley! The second page has some pretty important details: http://www.pcper.com/article.php?aid=548&type=expert&pid=11

It shows that response time for the SATA drives blows out way above 20ms beyond a queue depth of 8 - or referring back to the IOPS graphs, about 155 IOPS. At a queue depth of 16, response time is at a completely unacceptable 100ms! To put that into perspective, Microsoft say that response time must be less than 20ms per transaction for Exchange.

They also leave off a crucial detail: the I/O size makes a huge difference to the performance produced by the drive. You can't interpret the graphs without that piece of the puzzle.

I like IOmeter, but it is like any other statistic - you can make them show anything you want, and the interpretation of those statistics is critical.

ANY drive will have a rapidly growing response time at high queue depths -- new commands have a long time to wait while the drive works through its queue !!    But in real-life systems queue depths of more than 8-10 are relatively rare ... and above 16 even more so.     The graph also doesn't show anywhere near 100ms for the Velociraptor at a depth of 16 ... more like 30-40 or so [it's the bottom (blue) line].

A Velociraptor is very close in performance to any 10k SAS drive ... and indeed will outperform many due to its high areal density (and thus faster transfer rate).

I agree IOMeter is like any other benchmark -- it's good for some things; less so for others.   The real bottom line here is that the interface isn't the big difference in drive performance ==> it's the rotation rate; areal density; seek time, and whether it's an enterprise-class drive (with dual processors and onboard command reordering).    Those parameters will make far more difference than whether the interface is SAS or SATA.

It's not that simple.

First, if you're using RAID 1, you don't get the higher transfer rate of a striped array.   For the "6 drive SATA RAID 1" did you mean a RAID 10?   If so, then yes, that array will have a higher transfer rate than a single 10K drive.

HOWEVER, the transfer rate isn't the only factor -- and for MANY disk I/O's is not the most important.   The access time is MUCH better with 10K drives ... and a RAID array doesn't change that factor at all.    For MOST uses, the 2 drive SAS array with 10K drives is preferable to a 6-drive SATA array with 7200rpm drives.   (If the main use is large file transfers the 6-drive array ... assuming it's striped ... would be preferable)

This really does boil down to what I said early on -- the key performance difference is NOT going to be whether the drives are SAS or SATA ... it's the performance level of the drives you use [7200rpm, 10k rpm, or 15k rpm].

IOPs are driven primarily by the access time of the drives plus the average transfer time for an IO.    The 10k and 15k drives have MUCH better access times than 7200rpm drives [Much faster seek times, and of course lower latency due to the faster rotation].   These drives will FINISH many transfers before a 7200rpm drive would even start them (it would still be seeking) ==> the interface [IDE, SATA, SAS, SCSI, FC] makes NO difference in this basic fact.     SAS/SCSI IS a better multi-tasking interface because of the higher level of "intelligence" on the drives themselves, which allows higher queue depths and in general more onboard processing of the requests (e.g. command reordering).     But enterprise-class SATA drives have adopted many of these characteristics ==> and as long as you use this class of drive there's simply not going to be a huge difference ... certainly not in comparison to the major differences you get by simply moving up the rpm ladder.

... Note, however, that even if you don't stripe the data, a 6-drive RAID-1 WOULD get the benefit of higher IOPS, since there could be 3 different IOs ongoing at the same time vs. a single IO with the 2-drive array.    So from that simple analysis, then Yes, it would give you a slightly higher number of IOs per second.    But whether this would translate into a real performance gain or not depends on the average size of the transfers -- again, it boils down to WHAT you're using the system for.    And note that this analysis is equally true if you used 6 7200rpm SAS drives ==> it still boils down to the simple fact that the key difference is the drive's performance;  not the interface.

http://www.adaptec.com/NR/rdonlyres/3F1C96CE-B927-446D-8865-A0EE7A2C86C4/0/6190_Seagate_WP_12.pdf

I think you might find this a very helpful read because it compares exactly what you are after I believe.

Gives you good information and why SAS 7200rpm is much better than SATA 7200rpm, and how you get better data integrety as well.

And doesnt go into all the other "true SAS" 10/15K discussions.

"...Should this question re: 6 vs 2 drives be in a new post? " ==>  No need.    It's a natural evolution of the discussion r.e. SAS vs. SATA performance, which was the title of your question [You DID focus initially on drives at the same performance level, but think this comparison is a natural follow-up.]

The Seagate analysis of SAS vs. SATA in the paper referenced above is interesting, as it does compare 7200rpm SAS vs. 7200rpm SATA in the same family of drives ... and notes a 35% performance gain for the SAS version of the drive.    Note, however, the comment that these "... performance benefits are due to the Barracuda ES.2
SAS drives use of the powerful SCSI command set (including SCSI command queuing), dual core processors (vs. a single core processor on SATA).     This reflects Seagate's decision to maintain those differentiators between their "enterprise class SATA" and "enterprise class SAS" drives.    Note that Western Digital's enterprise class SATA drives have dual processors with command queueing -- so this difference is NOT because of the inherent differences in the interfaces;  but in the manufacturer's marketing focus.

Back to your question (which you stated slightly differently this time -- not mentioning what interface the 7.2k drives have) ... it's still difficult to answer that question with any reliability.    In theory, a 6-drive RAID 5 with 60 IOPS/drive performance could achieve 300 IOPs (the parity drive doesn't add anything), while a 2-drive RAID 1 with 140 IOPS performance could achieve 280 IOPS read performance (but less write performance) ... so the 6 drive array would "win".    But there are MANY variables this doesn't address, so it's by no means a hard and fast result.    Personally, I'd go with 10K SATA Velociraptors or 15K SAS drives if you want to maximize performance -- for transactional loads the faster access times trump just about everything else.

"... am I correct in concluding that a SATA RAID with enough drives can outperform a SAS RAID with less drives? "  ==>  Of course (as andy noted above).      That wasn't, however, your question :-)     The apples-to-apples comparisons will always favor SAS drives, for the various reasons we've noted ==> but only in those cases where the onboard SCSI command set provides advantages (e.g. high transactional loads) beyond the raw performance of the drives.

And you need to be sure you understand what you mean by "performance".    No matter how many drives in a striped SATA array of 7200 rpm drives, a single 15K SAS drive will blow it away for a single IO that's retrieving a small amount of data -- the 15K drive will be DONE with the transaction before the SATA array even starts it.   But for heavy transactional loads, where the most important factor isn't how fast a single transaction can be done, but how many transactions can be done in a given time (i.e. where the total bandwidth of the array is more important than the performance/transaction), a large striped array will give the better performance -- PROVIDING it has good command queueing/reordering  (so it doesn't result in severe disk thrashing in the array).

"... am I correct in concluding that a SATA RAID with enough drives can outperform a SAS RAID with less drives? "

Yes - especially for sequential workloads. Random workloads will be bedevilled by the poorer response times of SATA drives, so that's a tougher call, but throw enough drives at it and it'll go like the clappers. A good example is the IBM XIV array that uses only commodity SATA drives in some seriously wacky arrangements to provide  performance - but it uses 180 drives to do it. IBM claim a 1TB drive rebuild time of 30 minutes - its done by spreading data across a large number of drives. Mind you, similar performance could be driven from about a third the number of FC or SCSI drives - which will be cheaper to purchase and an absolute shed-load cheaper to run over its lifetime as power consumption and cooling consumption will also be a third.

The anti-vibration technology, TLER, and an advanced native command queueing capability were in the RE2 series.     But the RE3 series added the 2nd processor, and improved the anti-vibration technology to have enhanced tolerance for both linear and rotational virbration.      I would not expect to see much (if any) performance difference between an RE3 drive and a SAS drive of the same rotational speed and areal density.