17

Can not find that anywhere it seems.

What is the expected performance difference in a storage backend scenario that is heavily parallellized in access (like a SAN, Virtualization host storage etc.) between SAS and SATA, all other things being equal?

I Think it runs down to the impact of NCQ (32 command limit) to the MUCH higher oustanding command limit of SAS discs.

We are considering replacing some discs and have a chance to go for SAS or SATA - all the rest is in place - and I look for an evaluation from a performance point. Please ignore all the other issues (reliability etc.) - I purely wonder about the impact SAS will have on similar specced discs (RPM etc. being equal). The discs we have in mind can be ordered with both connectors and - there is an idea here to use SATA for ap ossibly repurpose later. THe price difference is not really high, but it made me wonder about the performance impact...

MDMoore313
  • 5,531
  • 6
  • 34
  • 73
TomTom
  • 50,857
  • 7
  • 52
  • 134
  • 3
    It's not like you to ask "All things being equal" because the differences in SAS and SATA are enough that things... are not equal. – Mark Henderson Apr 01 '14 at 06:23
  • @MarkHenderson Reality is - all other things can be equal. Seagate offers some discs with either SAS or SATA connectivity, so all other parameters (cache memory, rotational speed, speed of moving the moving parts) are equal, it all runs down to the SAS / SATA Protocol issues. – TomTom Apr 01 '14 at 06:28
  • I think you'd have to benchmark the specific disks under your specific workload to be absolutely sure - maybe you can get a few disks of each, benchmark & post it back here? – Andrew Apr 01 '14 at 06:54
  • @Andrew Yeah, like I am the only one who ever did that. I remember (faintly) once being told to expect about 50% more IOPS based on serious queue lengths being possible in SAS (but not SATA) under heavy parallel load (so a long gueue length does actually happen). Just missing any sort of reference. – TomTom Apr 01 '14 at 07:51
  • 2
    Are you considering nearline SAS at 7.2k RPM, or real SATA? – Basil Apr 03 '14 at 13:45
  • I am considering Seagate Constellation 2. They are available with SAS and SATA interface - otherwise totally identical. I did not want to get exacty here (because I wanted this to be generic) but this is what we talk about - so the deives are totally identical except in this case. – TomTom Apr 03 '14 at 13:51
  • Oh, by "all other things equal", you are including spindle speed! That totally changes my answer... – Basil Apr 03 '14 at 16:13
  • @Basil As I said - ALL other things being equal. I really care only about "what impact does SAS vs. SATA have at the performance of a disc under heavy parallel IO (random)". I don't find any benchmark done by anyone for that. The serious difference in handling queueing SHOULD give SAS a significant advantage (the NCQ limit in SATA is very low). – TomTom Apr 03 '14 at 16:15

3 Answers3

12

Yes, the extensive command set of the SCSI is a big bonus of using it over SATA. from SAS' Wiki:

SATA uses a command set that is based on the parallel ATA command set and then extended beyond that set to include features like native command queuing, hot-plugging, and TRIM. SAS uses the SCSI command set, which includes a wider range of features like error recovery, reservations and block reclamation. Basic ATA has commands only for direct-access storage. However SCSI commands may be tunneled through ATAPI[2] for devices such as CD/DVD drives.

The error recovery commands and block reclamation commands are pivotal in data integrity, S.M.A.R.T. is really for consumer grade equipment.

Also, SAS uses a higher signaling voltage, which enables longer cables compared to that of SATA. That's important when trying to cable up additional storage to an existing SAN.

You menitoned NCQ, but SCSI uses TCQ instead, which can be used in three different modes, however the bigger bonus imo with regard to parallelized setups is the ability to send up to 2^64 commands before filling the queue. Protocols like iSCSI and Fibre Channel limit this right now but the ability is there for future use.

I can only answer that portion, because I don't know if going with SAS for a couple of new disk will give you the same benefit of a purely SAS setup.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73
  • Some of the error recovery features are spilling over into ATA, with some drives now supporting TLER (though I don't believe there is any standardized command in ATA to configure the error timeout, as there is in SCSI). – Chris S Apr 03 '14 at 14:18
4

This is a late answer, but I would like to add my opinion.

From a pure speed standpoint, a nearline drive (as the ones OP considered) will performs practically the same both using the SATA interface or SAS interface. Despite the much lower-depth NCQ (31 entries rather than TCQ 64K), this limited hardware queue is sufficient, when augmented with the much deeper software-based IO queue, to extract almost the same IOPS which can be obtained using SAS-based TCQ.

Anyway, this does not means that SAS has no practical advantages:

  • much better support for expanders
  • support for double-link interface
  • full-duplex operation
  • much faster maximum signaling rate (12 Gb/s vs 6 Gb/s)

However, when considering performance alone, the sad reality is that mechanical disk's random IOPS values are so low that the interface has almost no impact, excluding huge disk arrays where is can sometime limit your sequential IO transfer rate. Due to how they take rotational delay (which is hidden from the OS) into account, the killer performance-enhancing feature is NCQ/TCQ, and the SATA implementation is sufficiently good at that.

Some more significant differences appear when considering higher end SAS disks, which not only offer higher-RPM disks (10K and 15K), but have some interesting write-coalescing technologies (ie: HGST media cache tech) which, by the way, are slowly spilling into enterprise-SATA drives also.

1 https://ata.wiki.kernel.org/index.php/Libata_FAQ:

However, the ATA standard has a design flaw. The NCQ tag is presumed to be a 32-bit bitmap (32-bit dword). If all 32 tags are asserted, this produces a value (0xffffffff) that is the same value returned by reading a hardware register after the hardware has been hot-unplugged, or suffers a major failure. Thus, to distinguish this condition, libata artificially limits all NCQ configurations to 31 tags rather than 32.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
1

Old post, but I wanted to update it since I never see mention of the most important difference in terms of performance which is that SATA is only half duplex. Expect a huge performance difference under heavy loads with a mix of read/write. Definitely not suitable for SAN or virtualization IMO.

Of course as stated above there are other benefits with SAS. Nowadays NL-SAS disks can be had for not much more than SATA.

Nathan K
  • 11
  • 1