Serial SCSI Standard Coming Soon

rchatterjee writes "SCSI is very close to joining ATA in leaving a parallel interface design behind in favor of serial one. Serial attached SCSI, as the standard will be known, is expected to be ratified sometime in the second quarter of this year according to this article at Computerworld. Hard drive manufacturers Seagate and Maxtor have already said that they will have drives conforming to the new standard shipping by the end of the year. The new standard will shatter the current SCSI throughput limit of 320 megabit/sec with a starting maximum throughput of 3 gigabit/sec. But before this thread turns into a SCSI fanboy vs. ATA fanboy flame war this other article states that Serial Attached SCSI will be compatible with SATA drives so you can have the best of both worlds."

Comments

SASCSI

[epyT-R]

Well, at least we can get rid of those hard-to-route ribbon cables. That alone is worth the switch, IMHO.

Re:SASCSI

[chrisseaton]

I've always wondered, why are they ribbions? Why not simply roll the ribbons up into cables? Can anyone enlighten me?

Re:SASCSI

[sirsex]

I believe it is due to the inductive crosstalk between the channels. With ribbons, only the two adjacent wies are a major concern, while a cable would have many more conductors in close proximity. The interfence will add linearly with each noise source

Re:SASCSI

[Ryan Amos]

To reduce crosstalk between the wires so that you can run at faster speeds. Indeed, the "rounded" IDE cables often reduce performance by 5% or so. We're getting better at data throughput though, so we can use serial technologies and actually get faster transfer rates. Good riddance to ribbon cables :P

Re:SASCSI

[shepd]

>Why not simply roll the ribbons up into cables?

Impedance, crosstalk (mentioned) and price.

It takes seconds to crimp a ribbon cable. Cheap and easy. You can even do it yourself!

Taking a bunch of twisted pair wires (which is what would be required to keep the impedance and crosstalk bearable) and soldering them onto connectors individually takes a lot more effort, and therefore costs more.

Not to mention fabbing individual strands of insulated wire and twisting them together costs more than running 5 wires parallel to each other and simply coating them all at the same time with PVC.

Re:SASCSI

[Waffle Iron]

Another major advantage of ribbon cables is that they are dirt cheap. They can be stamped out in one step without handling the individual wires. You can also attach connectors to all ~50 wires just by shoving the sharp teeth through the ribbon in one motion. No soldering or advanced tools required.

Re:SASCSI

[iotaborg]

If you've taken a look inside Apple's cases, you would notice how much better ribbon cables can be than rounded. With the ribbon cables routed on the side of the case, under the motherboard, completely out of your way due to the flat nature, it's much more cleaner than what you get with rounded cables (and esp ribbon cables just dangling in mid air). However I do not think this is easy to do in an ATX format.

Re:SASCSI

[dotgain]

External SCSI cables aren't ribbons, and work fine. You can't use any old 50 core cable, I think all the pairs inside them are twisted together.

I have a 10M SCSI ribbon, and each pair is twisted. I think the main reason for ribbons inside the box is so you can crimp on a connector wherever you want. Oh, and in a Sparc20, the internal SCSI cable isn't a ribbon, it's a cable from the motherboard right up to where it connects to the disks, cable again to the CDROM.

So, IMO, there's no reason it can't be a ribbon, except for the convenience of crimping connectors wherever you want.

evil technology!

[Anonymous Coward]

Serial ATA Network = SATAN

Re:evil technology!

[kidlinux]

it gets worse...

Serial ATA Network Interface Controller = SATANIC

Re:evil technology!

[dubbreak]

i can see it now in banners and somputer mags everywhere:

"Does your computer support SATAN ?"

Next thing you know all new dell computers will support SATAN.. imagine the adds, "Dude you're connected with SATAN!"...
ok ok i'm done

bits vs. bytes

[David Jao]

Guys (meaning submittors and editors), the current version of SCSI delivers 320 megabytes per second of interface transfer rate, not megabits.

320 megabytes is about 2.5 gigabits ... which is a lot closer to 3 gigabits than the erroneous 320 megabits figure.

Re:bits vs. bytes

[g4dget]

Yeah, but what drive actually delivers 320 Mbytes/second? As long as the connection between the controller and each drive can keep up with the drive, the connection is fast enough.

Of course, a really fast connection may allow you to daisy chain and still get almost full transfer rates from each drive, but that's not really such a big deal, in particular when the cables are as small as they are for serial connections.

Re:bits vs. bytes

[Daniel Phillips]

Yeah, but what drive actually delivers 320 Mbytes/second? As long as the connection between the controller and each drive can keep up with the drive, the connection is fast enough.

Scsi is a bus. I have a box here with 5x10K drives, at 49 MB/s each, easily able to saturate its ultra 160 bus. These days, that box is nothing special.

Re:bits vs. bytes

[g4dget]

You don't need 10 controllers; the bandwidth limit is merely an electrical limit on the wire and connector, not on the controller. A single high performance USB2 or FireWire controllers should be able to do full USB2 or FW bandwidth per connector. Think of it like an Ethernet switch. In the past, a 100Mbps limit was aggregate, but now, the switch can do 100Mbps per port.

You can already get USB2 and FireWire cards that can do high speed transfers simultaneously on several connectors, and if this really takes off, there is no reason why you couldn't have a card with 8 or 16 independent channels (ultimately, of course, it gets silly because PCI can't keep up anymore).

SCSI = ...

[product byproduct]

If I understand the title correctly, SCSI = Standard Coming Soon Interface?

Re:SCSI = ...

[Anonvmous Coward]

"If I understand the title correctly, SCSI = Standard Coming Soon Interface?"

I think it stands for

Some Can't Stand IDE

Re:SCSI = ...

[dotgain]

System Can't See It.

Re:SCSI = ...

[NomNet]

Super Compatibility-nightmare Storage Interface

Squillion-Connectors System Interface

Ad infinitum - there are MANY more :D

How parallel will it be?

[tjstork]

Will this new standard be able to do things in parallel the way SCSI can? Will I turn my server into a PC like box that seemingly pauses every time the swap file gets touched?

Re:Mbit != MByte

[Anonymous Coward]

Actually, that's 320 Megabytes per second for Ultra 320 SCSI and 3 Gigabit per second (approx 375 Megabytes per second) for Serial Attached SCSI

Ok, So I've noticed a couple of corrections.

[taliver]

If the article meant to say 3GBytes, then how in the world will the PCI *at 64bits and 133MHz, it's 1 GB/sec transfer) bus keep up? Or even RAMBUS memory, which, here says it has a bandwidth of 4.2GB/sec. (So, kinda means you couldn't have more than one SCSI system at a time and get full bandwidth from both.) Now, if you may have to have memory banks for each SCSI component... ick.

Re:Ok, So I've noticed a couple of corrections.

[Zebra_X]

PCI Plus proposed by Intel is promising 2GB/sec dedicated channel per device on the PCI Plus bus.... this doesn't fully meet the needs of the drives but is certainly a step in the right direction.

Re:Ok, So I've noticed a couple of corrections.

[torre]

With PCI-X 1066 8.6GB/s bus tranfers are possible so that should be too much of a problem. Also, the InfiniBand aims to solve that problem. One can see that 6GB bus' were planned even in this older dell whitepaper suggests.

Re:Ok, So I've noticed a couple of corrections.

[sedmonds]

The pci and rambus busses don't need to keep up. The peak throughput only needs to be serviced within the scsi chain. Buffering on the scsi adapter could deliver a relatively high sustained transfer rate from the scsi chain to the pci bus, within pci limitations.

Re:Ok, So I've noticed a couple of corrections.

[lederhosen]

from:
http://www.hypertransport.org/

11.
Question:
At what clock speeds does HyperTransport(TM) technology operate?

Answer:
HyperTransport(TM) technology devices are designed to operate at multiple clock speeds from 200MHz up to 800MHz, and utilizes double data rate technology transferring two bits of data per clock cycle, for an effective transfer rate of up to 1,600Mb/sec in each direction. Since transfers can occur in both directions simultaneously, an aggregate transfer rate of 6.4 Gigabytes per second in a 16 bit HyperTransport(TM) I/O Link and an aggregate transfer rate of 12.8 Gigabytes per second in a 32-bit HyperTransport(TM) I/O Link can be achieved. To allow for system design optimization, the clocks of the receive and transmit links may be set at different rates.

----

For the pentium4:

133MHz Quad Pumped (533MHz effective) allowing access to up to 4.2GB Bandwidth

But I guess that most of the trafic is mem-hd
or hd-mem and thus does not nead to go trough
the cpu, I think the latest alphadesign was
to have 8 rambus chanels giving plenty of
bandwith

U320 SCSI

[Unix_Geek_65535]

Greetings fellow geeks :-)

U320/LVD SCSI is capabable of 320MB / sec not 320mbps.

3gbps ~= 300MB/sec. therefore it would not be be quite as fast as U320 SCSI.

Naturally 320MB/sec is the theoretical max bandwidth for the SCSI bus not the individual drives in the SCSI chain.

Live long and prosper

Re:U320 SCSI

[Unix_Geek_65535]

Indeed, my math was wrong and for that I apologize!

However I did say:

3gbps ~= 300MB/sec which was meant to indicate it was "[very] approximately" 300MB/sec

300*1024^3=322,122,547,200 bytes per second and 3gbps = 3,000,000,000 (3 billion bits per second).

3000000000/8 = 375,000,000 bytes = 357 MiB/sec (1KiB = 1024^1 bytes, 1MiB = 1024^2 bytes, 1GiB= 1024^3 bytes)

In the real world we also run into: encoding overhead, protocol overhead, errors, bus resets, cache misses, interference and many other factors which impact actual throughput.

FYI: Studies I have observed myself during a research project indicated that the maximum total throughput under GigE is approx. 80MiB/sec under ideal conditions, even though 1,062*1000^3 = 126,600MiB/sec
Of course it all varies depending on the network adapter used, packet size, processor "speed", RAM, Operating System [!!!], 64bit x 66MHz PCI vs. 64bit x 33MHz PCI vs. 32bit x 33MHz PCI, copper vs. MMF or SMF, HD vs FD, and about a bazillion other factors.

Believe it or not, at an undisclosed, fully accredited, state-owned University somewhere in the US they taught us in a senior level networking class of all places that due to those factors it is wiser to divide by 10 when converting bits to bytes.

Go figure! I am NOT making this up!

Peace and Long Life

good performance.. but at what price?

[thadeusPawlickiROX]

Sure, this definately looks like it could be a great setup: fast, and compatable on multiple systems. But how much will this technology cost? Standard, run of the mill IDE hard drives are about a dollar per Gig. Regular SCSI is a few times higher, especially as drives grow in size. This will be a great advantage if the price range is in the middle of the range, but I doubt that. Now, this won't matter to those with plenty of money to burn on their servers, but would that added price be worth the new types of hard drives? I still don't even see a huge advantage to going Serial ATA right now, so this seemingly good idea could just be another good idea that won't pan out for most users.

Re:good performance.. but at what price?

[Magus311X]

Not just fast, but reliable.

Not to say that ATA disks aren't reliable, but the components that are used in ATA disks are typically those that were outside the absurdly strict tolerances that are required for "enterprise-class" drives.

And yes, when it comes to speed, SCSI tends to rule the roost. Not only because you can throw 320MB/s down each individual channel, but you can toss enough devices on that channel to keep that overall speed sustained over longer periods of time.

Drives have very high burst speeds, but have it do lots of random data access constantly and watch speeds plummet. That's why a 10-disk striped array (with another 10-disks to mirror if you require redundancy, likely on another channel) tends to kick considerable ass. Because even if you're only sustaining say... 10MB/sec per disk, it's now 100MB/sec over the channel.

ATA storage is definitely cheap. If all that is required is just LOTS of storage, and performance and reliability isn't really critical, ATA is a pretty good choice. Of course then you could use robotic tape libraries as well.

SCSI also really ruled the server rooms because those expensive servers and storage systems simply didn't have ATA support. Period.

-----

Re:good performance.. but at what price?

[g4dget]

Not to say that ATA disks aren't reliable, but the components that are used in ATA disks are typically those that were outside the absurdly strict tolerances that are required for "enterprise-class" drives.

The future of reliable, enterprise-class hardware is not delicately engineered systems that cost a premium, but a large number of inexpensive, simple servers and drives. For disks, we already have that in the form of RAIDs. If a drive, or two, or three, fail, you just replace them.

And yes, when it comes to speed, SCSI tends to rule the roost. Not only because you can throw 320MB/s down each individual channel, but you can toss enough devices on that channel to keep that overall speed sustained over longer periods of time.

That is circular reasoning. If you pick separate channels for each device, then each channel can be slower. Besides, "tossing enough devices on that channel" makes the overall system less reliable because if there is a problem with any one of them, it may kill the whole channel. And, besides, the more devices you toss onto a serial bus, the less efficiently it will be utilized relative to having a single device with the same total bandwidth requirements. Overall, you are probably better off using five separate USB2 or IEEE1394 connections than one of these serial SCSI connections.

Re:good performance.. but at what price?

[drsmithy]

For disks, we already have that in the form of RAIDs. If a drive, or two, or three, fail, you just replace them.

And if/when these drives go down and take your 2TB RAID array with them, who wears the blame for buying crap disks ?

RAID gives you some added security, it is *not* a silver bullet - even with hot-spares and several replacement drives handy, a simultaneous failure of 3 drives could potentially bring down nearly any RAID array.

Horray!

[norton_I]

Hopefully this will eventually lead to the elimination of the distinction between ATA and SCSI interfaces. Already the feature distinctions between the two are blurring, hopefully soon the interface will be the same and people will just decide whether they need fast or cheap drives. That would improve the quality of desktop class drives and lower the price on workstation/server drives, as well as make system managment a bit easier.

Re:Horray!

[evilviper]

Why would adopting a serial standard lead to "the elimination of the distinction"

Well DAMN! Did you even bother to read the Slashdot summary? You're right, the fact that they share a similar physical design doesn't mean that they will be compatible... It's the FACT that they WILL BE COMPATIBLE that tells you why they would be compatible, and lead to "the elimination of the distinction"

And I blockquote:

this other article states that Serial Attached SCSI will be compatible with SATA drives

For more info

[Anonymous Coward]

For more info on Serial attached SCSI check out this page:

http://www.lsilogic.com/products/islands/sas_islan d.html

Is this a trend?

[Anonvmous Coward]

I've only paid attention to HD controllers for the last couple of years or so. But I'm starting to wonder if we're seeing a pattern here. "We'll make everything more efficient by making it serial, and then years later when that's not enough we'll make it paralell to send even MORE data through!"

Anybody think we'll have a massive paralell trend in a few years?

Re:Is this a trend?

[TheShadow]

I don't think so. The reason there is a tremendous push towards serial right now is because parallel interfaces create more interference at higher frequencies. The theory with serial is that you can push the frequency as high as you want without the interference.

Re:Is this a trend?

[curious.corn]

Right, and the setup/hold deltas become irrelevant. As the switching speeds go up the time wasted for all the pin signals to be good becomes a hard limit for the bus; after all parallel is just a workaround to slow inverters. As long as the cables aren't too long for signal distortion to arise, serial can really push the limit and when that'll come I expect Si optoelectronic frontends will be mature enough to substitute electrical transmission lines in consumer electronics ;-)

Re:Is this a trend?

[daoine_sidhe]

Actually, it's more mission dependent than that. The distance isn't as much of a factor (though it is in some applications) as the bandwidth future proofing capability. In the vast majority of telecommunications specs that have been coming out for the last few years (at least in New England) it's fiber for ANY kind of backbone application. Even if the closets (for some godawful reason, though it does happen) happen to be 50ft apart. 12-strand multimode fiber is what you'll usually see. It makes sense over even short distance because of the bandwidth capability. In 10 years, that backbone fiber can be pushing 10gbps between those closets, per transmit recieve pair. Now, I know that they are working on a 10gbps standard for Cat6 fiber, but who wants to run a copper backbone? Hell, that fiber put in 15yrs ago can push the new 10gbps fiber standard right now! And you've got no crosstalk, no interferance (ever see what happens to your bandwidth when your 200pair copper is running too close to a bank of fluorescent lighting?). I've even seen a dozen or so specifications for fiber to the desktop projects in schools even! I've managed two of those installations in the last year, and the reason they do it isn't because it's some newfangled technology, it's for future-proofing. They know that later on, they'll be able to push more and more bandwidth down those same fibers and just have to swap out the active components in the closets. Any idea how much it costs to swap out a cable plant? Anyway, what it boils down to is this; even internally in workstations, the actual interface itself could be fiber, and not only would it allow much greater bandwidth immediately, it would future-proof the specification as well. I think 5 or 10 years down the road, we're going to see optical links for data begin to really take over. There's only so much that can be pushed through copper, and only so much interference before data integrity is severely degraded.

It's too bad...

[Quaoar]

...that the speed limitation on data access is mostly the fault of the DRIVE, not the interface. Show me a drive that can achieve 3 gigabytes/sec and I'll be impressed.

Re:It's too bad...

[Anonymous Coward]

Informative? How about ignorant?

That bandwidth can be shared between many drives. The drive itself has cache, so it isn't always returning data from the platters. And it's gigabits, not gigabytes. Get a freakin clue.

Re:Parallel Interface?

[jdoff]

You're mistaken. It's Small Computer System Interface. See dictionary.com

Re:Parallel Interface?

[aussersterne]

SCSI: Small Computer Systems Interface

descended from

SASI: Shugart & Associates Systems Interface

Re:why is serial better?

[ChaosMagic]

I don't know the technical details but I would imagine that in a virtual world where everything worked in theory, you'd be right, parallel would be faster. It stands to reason that however fast you can get a serial link, you can just put it together with a few more and have a parallel one just as fast.

I think the problem(s) come when you have to take into account keeping parallel lines in synch with one another, accouting for lost bits, and breaking down/putting back together all the information at either end. This all adds up in overhead for a parallel connection, where a serial connection just lets the information go through the line with little or no pre/post processing or synching to worry about.

Firewire?

[TheRaven64]

SCSI is expensive, FireWire is proven technology. Wouldn't it be more sensible to use FireWire?

Re:Firewire?

[torre]

SCSI is expensive, FireWire is proven technology. Wouldn't it be more sensible to use FireWire? [sucs.org]

Firewire is low end consumer product...even with its successor (which is taking longer than expected to ship) running at 800Mbits/s (100 Megabytes/second) it falls short of current SCSI technology running @ 320MB/s. As such there is no one who would seriously consider firewire for a large scale server handling many gigabytes/terabytes of data. Firewire is just too slow of a bus for big needs, but does fills its convenience needs in the consumer market. Everything has it's own niche... that's why heavily marked up servers/mainframes/supercomputers still exist instead of cheaper home machines which just can't fill the requirements.

no longer pronounced "Scuzzy."

[jfisherwa]

If SCSI is pronounced "scuzzy."

And the full acronym for "Serial attached SCSI" is SASCSI..

How exactly would we pronounce that? Sacksie? Sasky? Oh God, I bet it will be a silent C. .. "Sassy."

Yay, my computer iss really sspeedy now that I've upgraded to the new SSSASSSSSY DRIVE !@#!@^#^$^$#!

Jason Fisher. :P

Re:Benefits of SCSI?

[ProfMoriarty]

Uhmmm ... you CAN have more than 4 IDE devices ... what you need is more IDE channels.

Each IDE channel can have only 2 devices, a master and a slave.

The more IDE channels you have, the more devices you can have. Currently, on my Motherboard, it has 4 channels, (2 for "standard" IDE connections, for 4 devices, and 2 for "RAID" IDE connections, for another 4 devices).

In fact, there are a couple of MOBO mfgs that have 6 channels (2 + 4 RAID channels, for maximum throughput you would have only 1 device per RAID channel.) ... however, you don't need to configure the RAID array, and could have 12 IDE devices.

Currently, I have:

• 60G - master - channel 1
• 60G - slave - channel 1
• CDRW - master - channel 2
• DVD - slave - channel 2
• 40G - master - channel 3

BTW, it's really nice not to partition anything, and have a whole drive dedicated to an OS.

Fanboy?

[AtariDatacenter]

> But before this thread turns into a SCSI
> fanboy vs. ATA fanboy flame war...

FWIW, the alternative name for fanboy is "fanboi". An even more disrespectful version of the term. (As if fanboy wasn't disrespectful enough for some people.)

Re:Benefits of SCSI?

[khuber]

Better drives that are designed to run 24/7 with load. The drives usually have lower seek times/lower rotational latency. Some of this comes at the cost of heat and noise which Joe Consumer might not tolerate. Seek times are incredibly underrated, btw. The SCSI interface itself really doesn't have much advantage over ATA, but the industry builds its best drives for SCSI/FCAL.

Re:Benefits of SCSI?

[MoralHazard]

There is no "hard-limited" maximum of 4 IDE drives per motherboard. Most boards have two IDE channels built in, and IDE will only support 2 devices per channel, so you get four devices from the board. However, you can buy many, many boards that have more than that, especially lately (Abit's AT7/IT7 models come to mind).

Most board manufacturers include only two IDE channels because that's how many are generally built into north-bridge chipsets. The Abit boards mentioned above use an additional Promise HPT374 chip to provide FOUR extra IDE channels, for a total of TWELVE IDE devices, altogether.

If you want more IDE devices than your board supports natively, you can just buy PCI cards that have more IDE channels. Promise, SIIG, and Highpoint all make really cheap cards that have an extra two channels, or four more devices.

SCSI limitations are similar. You only get 15 devices PER BUS, but you can add as many devices into your system as you have PCI slots and IRQs for. You can buy an Adaptec 29160 card (dual busses) and plug 30 hard drives into it. Buy four of them, and can have more than 100 drives.

Re:Mbit != MByte

[Cramer]

That doesn't matter. Almost everything else in the post is in error. SCSI already has a serial interface standard (and has for a very long time.) -- ever heard of Fibre Channel or Firewire? SATA and SSCSI compatiblity? F***ing duh! What do you think ATAPI is? The SCSI command protocol moving in packets across an IDE physical interface.

I don't know what stupid scheme they are trying to create here -- interface-wise. SATA is a point-to-point configuration. SCSI has always been a bus configuration. If they go the p-t-p route, then it depends on the controller to be able to support the device on the other end -- SCSI crossing the pyhical interface or IDE/ATA/ATAPI crossing it. (Think parallel port ethernet dongle.) I'll have a hard time accepting p-t-p SCSI.

If they want to make SCSI more attractive, they should stop significantly over charging for the technology. They can bulk test "desktop" SCSI drives just as cheaply as IDE drives. They all use the same servo assemblies -- and in some cases, the same basic interface logic (obviously with different microcode.)

Yup -- post is wrong, eds please amend

[0x0d0a]

Those numbers *sounded* completely wrong.

Existing SCSI is 320Mbps*8bits/byte = 2.5Gbps.

Moving to 3Gbits is evolutionary, not a huge jump.

I'm wondering what's going on here too -- WTF happened to Firewire? I remember thinking that everyone would be using it as a universal high bandwidth data bus, and for some reason it doesn't seem to be happening.

A couple of notes

[Jordy]

There are a couple important notes about Serial-attached SCSI (SAS) that I think are important.

First, SAS uses a point-to-point topology similar to Serial-ATA instead of a shared bus like SCSI. This means each drive has access to full bandwidth, not just one (the bottleneck being the card itself).

Second, according to the SAS working group, SAS comes in three speeds; 150, 300 and 600 MB/s. I'm not sure where that 3 Gbps figure came from.

Third, unlike Serial-ATA or parallel SCSI, SAS is full duplex like fibre channel. This should have some interesting effects on latency.

Fourth, SAS uses the same physical connector as Serial-ATA and in fact can use Serial-ATA drives in legacy mode.

IBM's had this for several years, it's called SSA

[Anonymous Coward]

Serial Streaming Architecture that is. It's a 40MBps serial hardware layer that runs SCSI protocal. It's configured in a loop so there's automatic redundancy in case one link gets disconnected. And a single segment can be up to 20 meters long. Anyone have a Shark (ESS)? It's all SSA inside.

coward

Re:Benefits of SCSI?

[drsmithy]

I keep hearing that SCSI drives are better for hardcore media editing and for servers, but I'm curious why. Is there a compelling advantage for desktop users (or even servers)?

For desktops, not really. For server, yes. SCSI, due to (generally) lower latencies, higher rotational speeds and a smarter interface destroys IDE in high-load multi-user style scenarios (lots of random reads & writes all over the disk). Very few (if any) desktop users generate the sort of usage patterns that allow SCSI to shine, so on the desktop it has little advantage (particularly taking into account the cost).

Most people who say SCSI gives them a good boost on their desktop machines are usually comparing quite new SCSI drives to quite old IDE ones, are dealing with poorly-configured IDE setups (more than one device on a channel) or are using an older, slower machine (probably with a crappy IDE controller). For the vast, vast majority of users (and that includes high-end users) SCSI offers little benefit.

Here's a shot

[0x0d0a]

Okay. SCSI lets you do command queuing and reordering. Serial ATA will have this too. Theoretically, if you have a bunch of things doing sequential accesses at once, this can help. SCSI can have outstanding requests to multiple devices on a bus at once, and ATA cannot. This is a pretty big deal for environments where you can have heavy disk load, since if you have two drives on an ATA bus, one can get starved if the other is doing lots of work. I'm not sure if Serial ATA addresses this. For Average Joe's desktop, it's not a big deal because he's usually only doing one thing at once -- loading a game up, or copying a file.

SCSI is generally used to allow price discrimination by vendors. SCSI drives have a reputation for being more reliable, and much more expensive.

SCSI supports many more devices on a bus. This is a big deal to me -- it's a royal pain to buy another controller to add another device or two.

It's unlikely that the two will be merged any time soon, because there's tremendous financial incentive to prevent "enterprise-class" drives from becoming commoditized. SCSI is one of the industry's last useful tools to avoid this.

If you're getting a desktop, use ATA, almost certainly. If you're getting a server with a lot of drives, it may be worth your while to get SCSI, for the abovementioned benefits.

If I had some extra money and just wanted some extra reliability, I'd probably have a mirrored RAID pair of IDE drives, if I were building a desktop without a ton of drives.

Firewire? How about PCI Express?

[Adam J. Richter]

What I'd really like to know is why not use 3gio / PCI Express, the upcoming variable-width PCI bus that can shrink to a 250 million byte per second point-to-point "one lane" configuraturation that sounds like it could replace USB, firewire, ethernet, serial ATA and serial SCSI. The drive would be "directly" on the PCI bus. I would think that this approach would involve the least amount of silicon on a computer that already had PCI Express.

n.b.: Putting the controller logic back in the drive unit harkens back to the original In Drive Electronics approach.

Ummmm....

[psyconaut]

SCSI is already at "SCSI320"....which is 320Mbyte/sec NOT 320Mbits/sec!!!!

That's already ~2.5Gbits/sec.

And isn't there a SCSI640 working group, too?

-psy

No SAS drives on SATA

[berwyn]

There is a good article here

http://www.snwonline.com/whats_new/sas_and_sata_ 03 -03-03.asp?article_id=211

The article states that the SAS drives won't work on a SATA channel, but SATA drive will on the SAS.

I wonder if mobo makers like ASUS, ABIT, MSI and the likes will choose to have SAS ships on the mobo instead of SATA, as a performance feature?

Lets hope so it would sure open a lot of option for upgrading a PC over time.

Re:Benefits of SCSI?

[SETIGuy]

I'm not sure I get what the problem is. No room left in your case? No PCI slots for additional controllers?

My current desktop setup is...

• IDE Channel 1A: 100 GB master
• IDE Channel 2A: 100 GB master
• IDE Channel 3A: IDE ZIP 100 (Bay 6)
• IDE Channel 4A: DVD-RW (Bay 1)
• IDE Channel 4B: DVD-ROM (Bay 2)
• SCSI O id 4: Jaz 1GB (external)
• SCSI 0 id 5: CD-RW (Bay 3)
• FD0: 3.5" (Bay 5)
• One 5" bay free. (Bay 4)

The additional cost to get the extra two IDE channels was $25 for a dual channel IDE RAID card. For a home machine, IDE is perfectly adequate for the main drives. I keep SCSI around in hopes of acquiring a reasonably priced backup solution at some point. (My current backup is to copy modified files to another machine in the garage with an eventual dump to DVD). If I need more storage in the near term, I'd probably pick up a firewire drive.

"Next year or so" the arrangement I'd choose would likely be entirely different. We'll see where serial ATA and SASCSI are at that point.

Re:why is serial better?

[dmadole]

FYI - signals do not travel at the speed of light. Somewhere around 50-60% the speed of light in most types of cable.

Overcoming the differences in arrival time of signals in a parallel cable is not significantly more difficult than handling clocking (and maybe clock recovery) and buffering and serial-to-parallel conversion on a serial interface.

The main reason that parallel interfaces were popular years ago when things like SCSI were established was the electronics at the time just weren't very fast. The 74LS00 family logic that SCSI and parallel printer ports were designed around had a maximum clock rate of about 30Mhz. Add in margin for cable noise and distortion and 5-10Mhz was absolutely the most you could manage through any distance. So, if that wasn't fast enough for what you wanted to do, you used more wires in parallel.

These days, it's relatively easy to put multi-gigahertz logic onto chips, and the fewer wires in a cable and connector, the cheaper, so serial wins.

Interface vs Drive Speed

[nicotinix]

Great, the interface will be faster, but what about the actual drive speed. We are currently maxed out at 15k RPM and ~3ms access time. Compared to the improvements made on other PC parts (CPU, memory, video etc), hard drives are limping way behind. Todays drives cannot even come close to saturate the existing interfaces (except in RAID configurations).

What I would really like to see is some kickass desktop performance improvements for drives. Not just 15-25%, no, I want 4x, 10x performance improvements.

Seagate, Maxtor, do you hear me???

SATA vs SASCSI

[Gerry Gleason]

The links with the story didn't have much info, but Google provides this one http://www.serialattachedscsi.com/ that has a technical slide presentation (PDF) that give more detail. It seems that the main 'compatibility' at the start will be identical cabling specs. They expect that mid-range host adapters would have both protocols, but PC chipsets would probably be SATA only and you would need a separate SAS HBA. It wouldn't surprise me if dual protocol PC chipsets arive at some point.

One detail is that SAS is now point to point, just like SATA, and not a bus, but they also indicate that there would be boxes to split a single connection to a bunch of devices, sort of like network hubs. The protocol addresses 128 devices. It isn't clear whether a hub could have SATA devices hooked to it, or if that would require 1 serial channel per device from the host adapter. That is what I understood to be the case for SATA (need one port for each device, no hubs or sharing). The most important protocol difference should be that SAS is still multipoint, even if the connections are point-to-point, so both hosts and adapters need to arbitrate for the bus, while SATA hosts adapters just send out commands and data and wait for the drive to respond on the reverse channel.

It wouldn't surprise me if devices eventually just supported both protocols, and maybe even auto-sensed the type of adapter on the other end. By the time these interfaces get common, I expect the cost differences to be negligible, so It begs the question of why SATA would survive. Because the cost differences are going to be sunk into the chipset designs with almost no marginal cost differences, both system and drive makers will probably save more by reducing the size of their product lines by having one product for both.

this is not the merge of scsi and ata

[jkorty]

Didn't anybody read the pdf whitepaper? The only thing common between serial SCSI and SATA is the connector and the power and ground pins on the connector. The two protocols use entirely different signal waveforms and higher level protocols on the signaling pins. The article specifically states that to plug the wrong device into the connector results in a nonfunctional unit.

Re:Does SCSI now compete with firewire2 ?

[sconeu]

And how about 10Gbit Ethernet ? What's stopping you from using this as a drive interface ?

Is iSCSI a standard yet?

Just some info about the cables

[AbRASiON]

Contrary to popular beleif the SATA cables are approx 1mm thick, 6-7.5mm wide and quite "awkward" to work with :(

I for one will be doing my best to hunt down a supplier which makes precise lengths so I can have mine cut to size as they aren't as easy to route as a ribbon cable (seriously!)

Plus if you have 6 devices that's SIX cables in the box instead of 3,... - one of the small shortcomings of SATa :(

(when I first heard about it, I was under the impression it dasiy chained with an "in" and an "out" port - boy did I think that was FANTASTIC... but I was sorely disapointed when I discovered I was incorrect) :(

Is Serial faster?

[samdu]

I remember a while back that there were some Parallel modems (I think I actually have one in my closet). The spin was that Parallel modems had higher throughput. In addition, Maximum PC just did a benchmark test between Parallel ATA and Serial ATA and the Parallel drive/interface beat the Serial in all but one test. Is Serial actually faster and why?