G
George Macdonald
As a bus, it beats SATA2 marginally (320MBytes/sec vs 300) and allows for
multiple drives per channel (and continues to with SAS, through expanders).
20MB/s is a pretty small nit and is going to need PCI-X or a 2-lane PCIe
card?
As a protocol, I'm not sure if the command queueing in SATA2 has caught up
with SCSI or not; the NCQ implementation through SATA1 drives was definitely
less powerful than the SCSI implementation.
Probably not but what SATA-II has does extend its reach up into previously
SCSI-only territory.
As for controllers, and this is not inherent to SCSI itself, they tend to do
a lot more offload from the processor. This can actually be disadvantageous
for raw bandwidth given how fast processor speeds are, but can be a big
advantage in terms of random access/transaction processing performance. This
is not as big an advantage with say a $150 Adaptec board or similar (or the
motherboard-integrated SCSI chips); also, many of the hardware RAID
SATA/SATA2 solutions (like 3ware sort of thing) have equally powerful
offload abilities to comparably priced SCSI solutions.
Processor load, as you say given modern CPU speeds, has not been a problem
for IDE since UDMA-33. More recently, one thing SCSI, as an add-in card,
cannot have is the integration into internal chipset data paths.
Also, in an earlier post, you mentioned "not counting 15k rpm sorts of
things" but of course that's part of the picture; for serious TP workloads,
those make a huge difference and as far as I know are still only available
for SCSI (though there's nothing inherent in that, just marketing - there's
little advantage for home users and a lot higher cost/lower capacity.)
Well yeah - big servers could benefit but the market for SCSI is shrinking
rapidly. In fact, in the workstation/small server, much of the continued
"recommendation" for it is based on myth & legacy folklore. In the context
of the current discussion, it seems like a red herring to me.