From: Mark Lord <liml@rtr.ca>
To: Richard Scobie <r.scobie@clear.net.nz>
Cc: Jeff Garzik <jeff@garzik.org>, linux-ide@vger.kernel.org
Subject: Re: SAS v SATA interface performance
Date: Sat, 01 Dec 2007 22:45:09 -0500 [thread overview]
Message-ID: <47522A45.50706@rtr.ca> (raw)
In-Reply-To: <4751F482.60204@clear.net.nz>
Richard Scobie wrote:
>
>
> Jeff Garzik wrote:
>> Mark Lord wrote:
>>> SATA port multipliers (think, "hub") permit multiple drives
>>> to be active simultaneously.
>>
>> Quite true, although the host controller could artificially limit
>> this, giving the user a mistaken impression of their port multiplier
>> being limited to one-command-per-N-drives.
>
> Interesting. I was basing my comments on what may well be a vested
> interest slanted paper - see the sidebar on page 2.
>
> http://www.xtore.com/Downloads/WhitePapers/SAS_SATAValue%20Whitepaper_final.pdf
>
>
> For the modest extra cost of a non-RAID SAS HBA and JBOD enclosure with
> SATA drives, over a port multiplied setup, there would seem to be some
> advantages.
>
> Or have I been taken in by the hype... :)
..
Here's the "hype" part from that biased paper:
>
> Performance: Port Multipliers only support one active host
> connection at a time, signi\x1fcantly degrading e\x1d
ective
> throughput. Each time communication is initiated with a drive
> time-consuming drive reset must occur.
>
> Data Integrity: PMs must close the connection to one drive
> to open a new one to another. When a connection is closed
> drive history (e.g., data source, destination drive, data &
> command context) is lost; with each opened connection the
> chance of misidentification and sending data to the wrong
> drive is increased.
Fiction. Or rather, heavily biased.
Modern SATA hosts and PMs have no such issues.
The key SATA term to ask for is "FIS-based switching".
The biggest difference between SATA and SAS,
is the same one we previously had between ATA and SCSI:
Vendors like to position SAS/SCSI as a "premium" brand,
and therefore cripple SATA/ATA with lower spin-rates
(7200rpm max, or 10000rpm for WD Raptors, vs. 20000rpm
for high end SAS/SCSI).
There may be other firmware algorithm differences as well,
but "RAID edition" SATA/ATA drives have similar low-readahead
and fast-seek programming as their SAS/SCSI counterparts.
Simple spin-rate (RPM) is the most significant distinguishing
factor in nearly all scenarios. SAS/SCSI may also still win when
connecting a ridiculously large number of drives to a single port.
Cheers
next prev parent reply other threads:[~2007-12-02 3:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 19:19 SAS v SATA interface performance Richard Scobie
2007-11-30 21:24 ` Michael Tokarev
2007-11-30 23:17 ` Alan Cox
2007-12-01 7:43 ` Richard Scobie
2007-12-01 14:37 ` Greg Freemyer
2007-12-01 19:19 ` Richard Scobie
2007-12-01 20:01 ` Mark Lord
2007-12-01 20:40 ` Jeff Garzik
2007-12-01 23:55 ` Richard Scobie
2007-12-02 3:45 ` Mark Lord [this message]
2007-12-02 3:49 ` Mark Lord
2007-12-10 7:33 ` Tejun Heo
2007-12-10 14:36 ` Jens Axboe
2007-12-10 16:28 ` Mark Lord
2007-12-10 14:50 ` James Bottomley
2007-12-10 16:32 ` Mark Lord
-- strict thread matches above, loose matches on Subject: below --
2007-12-01 0:04 Richard Scobie
2007-12-01 0:17 ` Alan Cox
2007-12-01 3:06 ` Mark Lord
2007-12-10 7:15 ` Tejun Heo
2007-12-10 16:23 ` Mark Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47522A45.50706@rtr.ca \
--to=liml@rtr.ca \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=r.scobie@clear.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.