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

[Aliencow]

ThinkGeek has some non-ribbon IDE cables... But I'm thinking it's probably due to interference or crosstalk between the cables..

Re:SASCSI

[epyT-R]

I'm not sure, but it probably has to do with the inductance effects on the longer cables.

Re:SASCSI

[grishnav]

IIRC, one of the reason to use non-ribbon cables is to reduce the crosstalk, so long as they aren't wound like a coil (but rather braided).

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

[Realistic_Dragon]

I have shielded rounded IDE cables on the desktop I usually keep in bits (ribbon cables were a nightmare in this thing). The sheilded ones are supposed to be pretty good, but they cost a fortune (easily 10+ times ribbon cable costs), and the unshielded ones are best avoided.

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.

Re:SASCSI

[bluxus]

yep. totally.

Re:SASCSI

[TheCrazyFinn]

Apple's Cases are MiniATX. Just better designed than PC cases which still owe alot to the crappy old AT minitower form factor.

Re:SASCSI

[hatchet]

Impendance includes crosstalk. Impendance is combination of resistance, inductance and capacitance. Crosstalk is caused by inductance. There is another problem with non-ribbon cables.. Length of wires must be equal. At high frequencies you can get phase shift damn quick.

Re:SASCSI

[The_K4]

It's also cheaper to make ribbon cables...... the to make round cables. The ribbon cable is very easy to snap on connectors and then cut. where as with round cables it's easier for a wire to not get crimped right when making the cable.

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

Re:evil technology!

[Unregistered]

then run bsd on it

Re:evil technology!

[Anonymous Coward]

"Does your computer support SATAN ?"

Well, it has a sticker that says it supports Win2K, is that close enough?

rim-shot...thanks folks....i appreciate it, really

Bits? Bytes? Whatever!

[Anonymous Coward]

The current parallel SCSI is 320 megaBYTEs per second, which is 2.56 gigaBITs per second.

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]

Yes, I'm aware of that; that was, in fact, the point of my posting: if you attach each of those drives individually to a controller using a slower connection, you don't need an expensive, high-speed bus standard and still get the same aggregate bandwidth. You also reduce the risk of breaking something when you add or remove drives. Sorry if I didn't spell it out clearly enough.

Re:bits vs. bytes

[Mattsson]

On that 320MB/s bus you can attach 15 drives.
And yes, there are cabinets that actually allow you to do just that.
Where I used to work we had a serious bottleneck in our RAID stacks.
We had 14 drives on two 160MB/s scsi busses.
When doing RAID, that's bad since every write had to send data to 5 drives.
Increasing to four 160MB/s busses and splitting the raidsets amoung as many busses as possible helped, but there is still a bottleneck.
A modern drive can have a sustainend read speed of almost 60MB/s.
That's 900MB/s if you put 15 of them in a rack!
And large raidsets connected to busy servers could probably create quit some saturation on such a bus too.

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).

Re:bits vs. bytes

[Anonymous Coward]

But you're confusing the issue. You would need 10 controllers with the current IDE implementation.

SATA, etc. is different, but that's neither here nor there since you're talking about the current implementation - okay, some bizaaro implementation that would require all-new silicon on both drive & controller for all these extra connectors.

BTW, ultimately on an intelligent bus, you can do drive->controller->drive transfers without involving the CPUPCI bus. If SATA is implemented like regular ATA then yes, the PCI bus is going to get saturated (Intel works very hard to hobble standards so they're CPU-bound as much as possible, thereby increasing sales of high-end CPUs).

SCSI = ...

[product byproduct]

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

Re:SCSI = ...

[jspoon]

Small Computer Something Interface (I know you were joking, this just leapt to my mind)

Re:SCSI = ...

[damien_kane]

Small Computer Storage Interface, I believe...

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 = ...

[perlchild]

My old history books had
small computer standard interface

but the only place where it was standard was on a mac

Re:SCSI = ...

[mattkinabrewmindspri]

Smart Computer Systems Interface

Re:SCSI = ...

[dotgain]

System Can't See It.

Re:SCSI = ...

[NanoGator]

"System Can't See It."

Ha!

How about:

Same Configuration, Spastic Interface

Re:SCSI = ...

[dotgain]

Whoops! I wasn't actually trolling, I prefer the SCSI interface to IDE for many reasons. System Can't See It probably resulted from the early days when people thought terminaters were optional.

Re:SCSI = ...

[NomNet]

Super Compatibility-nightmare Storage Interface

Squillion-Connectors System Interface

Ad infinitum - there are MANY more :D

Re:SCSI = ...

[b1t r0t]

Sacrifice Chickens, Spread Incense

Serial SCSI Drives

[GeXX]

Now only if we can get the drive to read or write to the platters @ 3Gbit/sec. Also, is that suppost to be 320Mbit/sec or 320Mbyte/sec for the current SCSI throughput, because if my math is right, 3Gbit/sec is 380Mbyte/sec which os what 60MB faster / sec then current scsi drives.

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:How parallel will it be?

[dotgain]

As long as SCSI still takes advantage of a more intelligent controller on the drive itself, rather than IDE's philosohpy of cheap drive controllers (load all the work on the host CPU) no it won't suffer like that.

This is the main reason SCSI drives are more expensive. Some say the disk itself is of higher quality too, I won't confirm nor deny that.

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.

[lederhosen]

DRAM modules (or the mem-controller) does not
lie on the pci-buss. It lies on the northbridge
or on the cpu itself (like hammer). Nothing is
forcing you to place the SCSI controller on the
pci-buss.

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

[taliver]

Fine, but if it's not going to be on the PCI bus nor on the memory bus, where do you propose to put it?

Now, about 2-3 years ago, there was the infiny-band (sp?) solution, where this SCSI device could simply feed any number of processors and memory units on a huge 30Gb/sec shared bus structure. That has since died.

But that still leaves me with the question of where you plug this puppy into.

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.

[lederhosen]

On a hyper-transport link or on the northbridge
like the agp buss.

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.

[taliver]

With a 533MHz front side bus, and assuming a 128 bit wide structure (unrealistic), you're just at 8GB/sec. And theoretically you'd want to have something else beside disks on this system-- maybe memory and video? Maybe a network?

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

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

[taliver]

Well, then, I sit corrected.

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

[DeathPenguin]

Indeed. So what if the current PCI bus specs can't keep up? If we're going to have this standard around for years, possibly decades, then we need to think ahead.

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

[chunkwhite86]

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 [kingston.com] 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.

Why does it need to "keep up"? Think of it as planning for the future.

Accusing 3GB/s of being "too fast" is like saying "640k ought to be enough for everyone!".

In addition, there are architectures (think AlphaServer Wildfire) that could *easily* gobble up 3GB/s of SCSI data and then some. As ubiquitous as the i386 platform is, it isn't the only platform, and it certainly isn't the leading platform in the high performance space - which just happens to be the target audience of high performance storage like Serial SCSI.

Just my 2 cents.

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

[borft]

How about copying from 1 disk to another?
btw, I think they mean 3 Mbit, opposed to the 2.56 Mbit (320 Mbytes/s), the current fastest scsi standard is. Besides, who said anything about using a pci bus?

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

[John Sullivan]

If the I/O bus specs is going to be around for decades (and it will be obsoleted by an even faster SCSI standard within that time, though it will have a significant installed base), then the system bus specs *will* catch up and exceed its capability.

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

[evilWurst]

Five people modded this up without checking the math first...

3gbps = 3000mbps.

3000mbps / 8 = 375MB/s. There are 8 bits in a byte, not ten!

375MB/s (serial SCSI) is more than 320MB/s!

Re:U320 SCSI

[packeteer]

Sorry but your math is off. Remember the whole 1024 bytes to a kbyte thing. 3 gigabits a second should come out to about 384 megabytes a second which is fast than U320's 320 megabytes a second but not by much. The added speed here is not a big issue as SCSI drives dont typically max out their available bandwidth for very long.

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

Re:U320 SCSI

[Unix_Geek_65535]

Perhaps... or perhaps one of my former classmates

Incidentally, what is the distance to your local POP?

PS What kind of wiring is present in your residence or place of bussiness and who is your provider? Just trying to see if I can help.

Re:U320 SCSI

[dmadole]

"1024 bytes to a kbyte thing" is only for storage. And even then, only consistenly for RAM. Most hard drive manufacturers use 1000 bytes.

Bit rates and frequencies are always n^10.

3Gbps = 3,000,000,000 bits per second.

A 2.4Ghz CPU has a 2,400,000,000 cycles per second clock.

Re:U320 SCSI

[ThaReetLad]

actually thats 1024 bytes to a kibibyte. the prefix "kilo" means 1000. This is the standard that hard disk makers adhere to, which is partly why your OS always reports a hell of a lot less disk space than you thought you bought. Regardless, the simplest and least ambiguous way to compare bandwidths is by counting bits.

Re:3 gigabit/sec!

[Sponge Bath]

Imagine what a Beowulf cluster...

Wouldn't that be called parallel?

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.

Re:good performance.. but at what price?

[timeOday]

Look, the whole point of SCSI anymore is just to differentiate between "industrial-strength" drives with high markup and long warranties, and consumer-grade drives. Without some clear boundary, the "server hard drive" market would die. In other words, bringing SCSI to the masses would defeat the whole point.

Re:good performance.. but at what price?

[Fulcrum of Evil]

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.

Isn't that about average for a nasty power spike?

Re:good performance.. but at what price?

[nexthec]

Power spike is a seperate issue, If you dont have a decent UPS(not aUPS that switches to to the inverter during transients and outages, but where you are always drawing on a AC->DC->AC) and a decenet Backup system, then you shouldnt say "mission critial"

Re:good performance.. but at what price?

[Fulcrum of Evil]

If you dont have a decent UPS(not aUPS that switches to to the inverter during transients and outages, but where you are always drawing on a AC->DC->AC) and a decenet Backup system, then you shouldnt say "mission critial"

And if you rely on a UPS completely, then you need to say 'Tape Backup' before you find out just how reliable your UPS is.

Re:good performance.. but at what price?

[Rosonowski]

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.


But then you have to consider this: what is the likely hood of three disks failing simultaneously?

Re:good performance.. but at what price?

[drsmithy]

Actually, you have to ask yourself "what is the likelihood of three disks failing within the rebuild time period".

Then you have to take into considerations the possible failure modes - if your disks start going because the fans have gone in the disk enclosure have led to excessive heat buildup, then the chances of many disks going in a small time frame gets uncomfortably high.

Like I said, RAID isn't a silver bullet. It helps a lot and is probably all the redundancy most people need - but not everyone.

Re:good performance.. but at what price?

[nexthec]

Yeah, thats what I was thinking when I said and a decenet(sic) Backup system. That is always unfortunate to discoever when you need it

Re:good performance.. but at what price?

[chunkwhite86]

so this seemingly good idea could just be another good idea that won't pan out for most users.

"Most users" is not the target audience here. The data center is, especially high performance technical computing.

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.

And neither of these is the current high end. Dual Ported 2Gb/s Fibre Channel hard drives are the current high end. I know. I sell them for a living. And they are not cheap. Think ~$3800 for a single 72 GB drive. And these are typically sold in arrays as large as 168 drives.

Serial SCSI is not targeted at the "l33t g4m3r" crowd. It's targed at the enterprise data center crowd.

Re:good performance.. but at what price?

[AbRASiON]

You are totally correct!

Unfortunately the drives themselves and the costs to make them (lets say they DO drop their costs by going to a 1 year warranty) does NOT justify the cost of the drives.

SCSI is a niche overpriced product to gouge the consumer, or rather rape the corporate buyers with no choice.

SASCI is unfortunately to be priced "similarly" to SATA according to a SAS FAQ I read recently.
It's simply a "gentlemens agreement" between the drive manufacturers to not lower the prices and continue to gouge the consumer as much as possible ensuring their profits

Sure they don't make much on the desktop models anymore and they NEED that money (or some of it) but unfortunately it is artificially inflated, the costs of making those drives / interfaces is leaps and bounds lower than what they charge.

I for one will never touch SCSI again, I have no qualms with the technology, I have qualms with the un-necessary pricing.

Unfortunately all the nifty cool shit that SCSI has to offer for the desktop will never make it here affordably.

Re:good performance.. but at what price?

[chunkwhite86]

Sure they don't make much on the desktop models anymore and they NEED that money (or some of it) but unfortunately it is artificially inflated, the costs of making those drives / interfaces is leaps and bounds lower than what they charge.

I'm sure this is a true statement however the cost of research and development must be factored in. After all, a Ferrari is made of aluminum, steel, glass and rubber just like most other cars are, but a significant portion of the Ferrari's retail price goes to pay for huge Research, Development, and testing costs. The same goes for enterprise class data storage. I used to work for a large enterprise data storage manufacturer, and they spend huge amounts of time and money just on testing and qualifying hardware, and certifying it to interoperate with products from other vendors.

I for one will never touch SCSI again, I have no qualms with the technology, I have qualms with the un-necessary pricing. Unfortunately all the nifty cool shit that SCSI has to offer for the desktop will never make it here affordably.

Amen brother. As nice as SCSI is, I agree that it's priced waaay above an acceptable consumer level. Not to "stick up for" the drive manufacturers, but SCSI drives are considered "high end", but many companies make all their profits from the high end sales. I'm sure Maxtor wouldn't make much money if they just sold $69 40GB ide drives.

Fortunately for me (being in the high-end data storage business) my home PC (a dual athlon) has a 64-bit PCI SCSI raid controller with a mirrored pair of 15k rpm SCSI disks. ;-) Those were gratis; I would never consider such a setup if I had to spend my own money. That stuff is just too over priced.

Re:good performance.. but at what price?

[AbRASiON]

I understand the concept of paying for research, hence me suggesting they re-coup costs by dropping back to a 1 year warranty (ie make the drives a bit cheaper etc)

Sure there's more costs with SCSI and a lot more testing, but if we just had them drop a few small basic things from a SCSI drive, such as extensive research on the 10,000 rpm platters and how to keep it stable / reliable - less worries on cooling then, only 1 year warranty means slightly less research on the life of the drive etc, you round all of this down and you should be able to get SAS drives maybe 10% more than SATA, but ... as we both know, it's not going to happen.

Alternatively - fuckit, lets just strap an SAS controller on a WD 200JB edition drive (keep the 8mb cache ;) ) and see how that goes?!

I'm dreaming of course, I'm destined to still be using spinning magnetic media with a sub modernised 15 y/o interface for another 10 years aren't I?
Someone just club me now, I give up :(

Re:good performance.. but at what price?

[Rosonowski]

Well, personally, if I was going for redundancy, I would go for RAID, then double offsite backups to either tape or DVD-R. But that's probably overkill, and most people use RAID for speed advantages now, anyways.

Re:good performance.. but at what price?

[eyeareque]

dollar per gig comparisons between scsi and ide are like compairing apples to oranges.

SCSI benifits over IDE:
320 megabytes per second
more devices per chain
scsi controller does most if not all of the proccessing (watch you rcpu load when you do a large file transfer with ide hard drives)
faster latencies
longer warrenties
higher quality parts
and im sure there is more to add.. the above are the reasons that matter most to me.

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!

[g4dget]

Why would adopting a serial standard lead to "the elimination of the distinction"? When both were parallel, they were different.

The distinction is largely one of software and controller standards. SerialATA looks like an IDE controller, and SerialSCSI looks like a SCSI controller. The fact that both use a handful of wires in a thin cable to attach them doesn't change that.

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

Re:Horray!

[g4dget]

USB1 is compatible with USB2; they are still "distinct" and behave very much differently.

Re:Horray!

[Stoutlimb]

Seeing as I can put a serial-ATA or a serial-SCSI drive on a serial SCSI bus...

What is the exact technical difference between a serial ATA and a serial SCSI drive? I read somewhere that the only difference between IDE drives and SCSI drives are the interfaces and electronics, while the actual storage mechanisms are identical. So if both can now work on a SCSI bus, what the heck is the difference between ATA and SCSI???

Bork!

Re:Horray!

[Unregistered]

Not hooray

I know that if i ever need an extremely reliable system i can buy scsi disks and know i'm getting quality.

Re:Horray!

[quintessent]

I think the poster meant compatible as in the same. As in, you could also take a SCSI drive and plug it into your SATA controller.

Re:Horray!

[Hes Nikke]

funny, my ATA controller looks like a SCSI controler!

Re:Horray!

[Anonymous Coward]

There is still a huge difference between SATA and SAS drives. A SATA drive is designed to be a desktop drive. The SAS standard just allows for SATA drives to be plugged into a SAS backplane. There is translation from the SAS STP protocol to the SATA protocol in the expander that the SATA drive is attached to. You can't just plug a SATA drive into a SAS HBA. You need an expander--so it isn't a cost effective setup for just 1 drive. Who knows if the STP feature of SAS will take off, since the SATA guys are inventing their own SATA expanders. SAS is just the follow-on the U320 parallel SCSI, and it was derived from fibre channel (but designed so the expanders won't need a processor and should be cheap).

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

Re:For more info

[GunFodder]

Thanks for this excellent link. Here is an excellent one-pager on this site:

http://www.lsilogic.com/products/islands/sas/exp an ders_config.html

They show multiple desktops hooked up to a disk array but that wouldn't be very practical since you would have to run yet another wire to each box. But a server box full of blades that all shared high-speed access to a single disk array could be a very powerful and flexible system.

You can...

[Kjella]

I have some rounded cables. But:

1) The connectors must still be huge
2) As a consequence, the connector -> cable area is big.
3) There's so many connectors, the cable is big and inflexible.

Basicly, I couldn't fit the cables the way I wanted to have the disks, because they were so inflexible they collided with my GF4. So I had to rearrange the disks instead. With ribbon cables, it'd be much more of a mess but it would have worked. SerialATA is much better designed for this.

Kjella

Re:You can...

[-Surak-]

It's a bit of a hack, but you can split the wires in a ribbon cable (very carefully) into 8 or 10 narrower "strips" and then tape the whole thing together with electrical tape or use wire ties every few inches. It's not quite as nice as a "real" round cable, but it does work and really makes it convenient when you need to route around a crowed case without obstructing airflow.

It's probably not the best thing to do electrically, but I've never had any problems doing it, even with fairly long (~5') cables. I'd make a point to keep the number of lines per strip even, since every other line is a ground. The newer high density cables are tricky to split without exposing a wire, so practice on a scrap cable first before you hack that 8-connector ribbon cable.

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?

[Anonvmous Coward]

"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."

That problem is on it's way to being rectified. My company has a large LCD monitor that needs lots of data to drive it. We've got a $700 optical cable that takes it's range to some ridiculous length like 30 meters. They've made a small adapter that converts the electrical impulses to light, and back to electricity again on the other end so that the monitor itself doesn't have to be modified to use the cable.

Light doesn't cause this type of interference, so they'd be able to (in theory) apply this to other technologies as well. I don't think it'll be long before we see hard drives using something like it.

Re:Is this a trend?

[Noehre]

They already have this: fibre channel and work over either fibre or copper.

The thing is, for short distances there is almost no reason to use fibre over copper. Ever notice that not many workstations have fibre gigabit ethernet? Its great for connecting two routers together that happen to be a mile apart, but over short distances it makes no sense.

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?

[virtual_mps]

Light doesn't cause this type of interference, so they'd be able to (in theory) apply this to other technologies as well. I don't think it'll be long before we see hard drives using something like it.

I don't. We're nowhere near saturating the potential bandwidth of a fiber with consumer electronics. So there's not a great benefit in putting a bunch of fibers next to each other to aggregate their bandwidth--especially since (regardless of the optical path) the electrical signals going into the electrical-optical converters would be subject to the same high frequency timing issues that're causing the push away from parallel busses in the first place.

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.

Re:Is this a trend?

[Jeff DeMaagd]

A problem is that you have to multiply the frequency by ten or twenty to make the throughput equivalent to a 8 bit or 16 bit bus. Wire is wire, but you start getting to weird and unpredictable effects when you get to gigahertz. I don't know if they are using some sort of modulation scheme, I understand gigabit ethernet over copper uses a fraction of a gigahertz but modulates multiple bits over more than one sideband at a time.

At least it's a point-to-point system.

I think I'll note that the latest iteration of Firewire has provisions for a fiber optic link.

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:It's too bad...

[TheRaven64]

Show me a drive that can achieve 3 gigabytes/sec and I'll be impressed.

The interface runs at 3Gbps, not 3GBps. A standard SCSI interface can support at least 7 drives. This only 45MBps per drive on an U320 channel not counting protocol overhead. Quite a few SCSI drives can handle that speed.

Re:It's too bad...

[TheRaven64]

Okay, So 21MB/s per device. Even my IDE disk can manage that...

Re:It's too bad...

[RedWizzard]

by Quaoar (614366)

According to this you might be a planet soon.

Re:It's too bad...

[ottffssent]

Why? What conceivable use is there for a single drive that can kick out 300MB/sec?

Haven't we learned this already a dozen times now? Bandwidth is EASY. If you want a high-bandwidth link between NY and LA, charter a few trucks and fill them with DDS4 tapes. If you want a high-bandwidth disk subsystem, fill it with a dew dozen drives. If you want more memory bandwidth, add another channel or three.

Latency, not bandwidth, is the problem in nearly all applications. You want a drive that can sustain 3GB/sec. Well, I'll give you a hypothetical drive that can transfer data instantaneously. With a 5ms access time, it can still only transfer 100KB/sec if it reads 512byte sectors randomly. A drive with half the latency but only 10MB/sec transfer rate could come within 95% of doubling the first drive's performance under those conditions.

Until you approach petabits/second, bandwidth is not a technical problem, it is a financial problem. I have to go, so thus endeth the lesson.

Re:It's too bad...

[corsec67]

Show me a drive that can achieve 3 gigabytes/sec and I'll ... show you a RAID array. Multiple drives on the same channel, or on the same driver, will fill up any bandwidth limit, if you had enough drives. Maybe it is a connector to an external RAID cabnet. Imagine a beowolf cluster... Plenty of data transmission.

Oh no, not yet another interface...

[hamster_nz]

Argh! Who needs more standards! Why not just use fiber channel?

Parallel Interface?

[Kenshin]

SCSI is very close to joining ATA in leaving a parallel interface design behind in favor of serial one.

If I'm not mistaken, doesn't SCSI stand for "small computer serial interface"?

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.

If it came from GNU...

[Garion911]

It would be Small Computer SCSI Interface...

FireWire

[Blaskowicz]

Isn't FireWire a serial interface derivated from SCSI?

Re:FireWire

[Cyno01]

Isn't FireWire a serial interface derivated from SCSI?

Yes, yes it is.

Re:FireWire

[chunkwhite86]

Isn't FireWire a serial interface derivated from SCSI?

It does have many similarities with the SCSI protocol and is much better suited for hard drive data transfer. I'm not sure why USB2 external drives are so popular as USB is not nearly as approperiate for disk drives as Firewire is.

Re:FireWire

[walt-sjc]

I'm not sure why USB2 external drives are so popular as USB is not nearly as approperiate for disk drives as Firewire is

... Cause it's not apple, mainly. MS made a big push for USB2. Pushed Hard on computer manufacturers to NOT implement firewire on the motherboard. Intel who also happens to make so many of the chipsets also had a vested interest in USB. Apple STILL (while dropping the license fee requirement) is anal about the Firewire NAME.

It's a pitty as firewire has several advantages over USB2. When I went out looking for an external hard drive to use with laptops / desktops, I found one that did USB1, USB2, AND firewire. Instead of buying a USB2 PCMCIA adaptor however, I bought firewire so I can use my DV cameras on more than one system.

Re:FireWire

[MarcQuadra]

Um, not quite.. FireWire is a Serial Interface like USB or your COM port, but FireWire has a SCSI layer so it's just as easy to send a SCSI command to something on the FW bus as it is to the drive on your SCSI card. Some companies are working on making SCSI packets play nice inside IP packets, so you could mount a 'SCSI' drive over your network connection directly. This is way oversimplified, but SCSI is just a set of commands and frames to stick them in, the pipe you push those frames in is relatively arbitrary (apologies to device driver programmers, I make it sound so simple)

I doubt it...

[Kjella]

The very reasons interfaces are changing to serial is that it's very problematic to keep signals synchronized in parallell. So it's either "fast" serial, or "slow" parallell, and it looks like serial is winning. While fast parallell obviously would be the best, don't hold your breath for it.

Kjella

Re:I doubt it...

[lederhosen]

If its not optical! Then every fiber transmits
data in parallel! But its no use at the moment
cause the electric2optical circuts is adding a
lot of latency so for short distance it is no
use, at least for now.

Re:I doubt it...

[Neon Spiral Injector]

What I don't get is there already is a serial SCSI, it is called Fibre Channel. Right now it is clocked at 4 Gbits/sec. and there is no reason it can't go faster.

But I do agree about the problems with parallel. Thing about the interfaces called "parallel" and "serial", the old ports on the back of the computer. Sure the LPT ports were faster, but were very limited to the distance they could run because interference.

Also to get IDE over 33 Mbits/sec. they had to add an extra ground wire between each data wire to keep the noise down. SCSI always had extra wires, but they had to go to twisted pair (aka LVD) with in the cables to get any distance.

But FC is here today, it supports high, and huge cable lengths on optical cables, and respectible lengths on copper.

Re:I doubt it...

[Daniel Phillips]

The very reasons interfaces are changing to serial is that it's very problematic to keep signals synchronized in parallell. So it's either "fast" serial, or "slow" parallell, and it looks like serial is winning. While fast parallell obviously would be the best, don't hold your breath for it.

Hypertransport is a good example of a serial/parallel interface. To get more bandwidth, you add more links in parallel, each of which is a serial link capable of carrying the whole traffic on its own, just slower.

Re:I doubt it...

[0x0d0a]

What I don't get is there already is a serial SCSI, it is called Fibre Channel. Right now it is clocked at 4 Gbits/sec. and there is no reason it can't go faster.

Fiber optic hardware is more expensive. What I'd like to know is why *Firewire* doesn't serve the purpose.

Re:I doubt it...

[sjames]

Fibre channel is godawful expensive. It's only practical use is for multi attached devices and where long cable runs are necessary.

The same economics are behind copper Gig ether dominating fibre for everything but long haul links.

Re:I doubt it...

[Bishop]

the electric2optical circuts is adding a lot of latency

Is less then 1 clock pulse really a lot of latency? Ofcourse there is also latency in every electrical circuits as well.

The real problem with fiber is the cost. For short distances electric signals over coppper are cheaper.

Re:I doubt it...

[Neon Spiral Injector]

If all of the SCSI market were moved to FC the cost would drop considerably. But by creating a compeating standard they'll never see the wide range adoption of Fibre Channel that would be needed to get the cost down.

I haven't used multiple Firewire devices on the same bus to find out how they perform. That is my main reason for using SCSI and FC now. I just hope any new standard that comes out doesn't suffer like ATA does with 2 devices on the same channel.

Benefits of SCSI?

[DarthWiggle]

Ok, this is not a fanboy post on either side. But I'm wondering what the benefits of SCSI are in this day and age. Is it just the ability to have more than four drives? If that's it, are IDE/SATA drives somehow hard-limited to just four connections, or is that a motherboard limitation that hardware vendors stubbornly refuse to leave behind?

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)?

I have to admit, I've got a box with two IDE drives and two CD/DVD drives, and I'm irritated that I can't keep my IDE ZIP drive installed or add another drive (transferring data is a pain in the butt...). It would be awfully nice just to throw another drive in the chassis, and add the free space to my existing partitions.

I dunno, I'll be in the market for a new desktop in the next year or so, so I'm trying to figure out now what the best hardware arrangement is.

Pizzle.

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.

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:Benefits of SCSI?

[man_ls]

I run a similar setup...my 2+4 channel controllers, my optical drives are on the 2-channel and my HDD on the RAID controller, all master devices.

Re:Benefits of SCSI?

[autocracy]

The SCSI bus supports more drives per channel (limited by bus type, up to 126 right now using FireWire. ATA is stuck at 2). SCSI drives support fancy things such as command queing and the controllers are optimized to handle things like high numbers of small transactions with greater efficiency. A nice explanation to set you in the right direction is found here.

I run both ATA and SCSI drives. My take is that if you're using small numbers of drives or just doing straight, simple high bandwidth sequential seeks, ATA is fine. SCSI will show when you have differing loads that are more real. Personally, I'm much happier with SCSI for just about anything. The fact is that ATA propenents can only compare against current SCSI technology by trying to be "good enough" for the job. They're not. It's all an issue of price vs. performance - but take out the issue of price, and SCSI wins.

Re:Benefits of SCSI?

[taliver]

Just to share.

We're currently running some experiments using IDE drives, and so we packed a standard tower case with 9 60GB hard drives. It wasn't easy, and took 4 IDE cards, and we had to search for a system that had enough PCI slots, but we did it.

The problem we've run into is a matter of power-- the power supply really doesn't like being chained out using splitters to all those drives.

Just an FYI.

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.

Re:Benefits of SCSI?

[timeOday]

Why limit yourself to controllers on the motherboard? With SCSI the use of an add-on controller is almost assumed, no reason not to do the same with IDE. 2 channels = $36, and that'll support 4 devices if you're willing to do the master/slave thing.

Re:Benefits of SCSI?

[dotgain]

And why have all those drives powered up, when you're only using one at a time. Me, I cram 8 OS's over a 30G ATA and a 9GIG SCSI.

Re:Benefits of SCSI?

[dotgain]

And the only way anybody has demonstrated (or tried ) to me that ATA is faster assumes that all people do with their machines is:
dd if=/dev/hda of=/dev/null bs=1024 count=1024000
People do much more complex things than continuously read large files, yet that's all the psuedo-techs understand.

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:Benefits of SCSI?

[drsmithy]

And the only way anybody has demonstrated (or tried ) to me that ATA is faster assumes that all people do with their machines is: dd if=/dev/hda of=/dev/null bs=1024 count=1024000

Even that should be faster on a SCSI system.

People do much more complex things than continuously read large files, yet that's all the psuedo-techs understand.

The point is not that SCSI is slower on the desktop (although in some cases it is), it's that for most all workloads it isn't much faster (if at all), and costs much, much more. SCSI only really shines with lots and lots of randomised IO (particularly writes) that simply don't occur often in a single-user desktop system - or if you have some need to have lots and lots of drives attached to the system. Benchmarks (eg at www.storagereview.com) bear this out.

Re:Benefits of SCSI?

[ProfMoriarty]

>WTF do you have 40GB (or 60?) dedicated to an OS for?

Hmmmm ... because I can.

Re:Benefits of SCSI?

[dotgain]

Even that should be faster on a SCSI system.

True. I haven't stayed in a SCSI vs IDE arguement for long enough. And I'm no speed freak anyway, sure people have a need for fsking fast hard drives, I only need the ability to easily add many drives, particularly outside the case on my desktop machine.

If you're using a *NIX,( and even then it depends what you do with it) then I'd say even a single user desktop is still going to have a lot of random i/o, and assert that SCSI will have to be the winner in all categories except price.

Re:Benefits of SCSI?

[JKR]

Maybe I'm just one of those "rare" power users, but I commonly run up against the I/O limits of IDE on the desktop (Windows XP); with IDE, things just bog down under I/O intensive workloads (like, running Adobe Acrobat & Illustrator, MS Visual Studio .NET compile, maybe a few RDP / terminal server sessions).

My other Windows system is entirely SCSI based and never bogs down in the same way (and before you ask, yes, they have similar RAM, M/B, CPU, software load...). In fact, it's usually CPU bound.

Partly it's due to the fact that Windows pages to disk, even with large amounts of RAM (both machines have 512 MB, about to be upgraded); that just kills IDE stone dead; under heavy paging it's totally unusable without multiple drives on dedidicated channels.

Sure, I get no advantage by having SCSI optical drives except for reclaiming the IDE interrupts. Annoyingly, mine are severely obsolete now that very few people make SCSI CD-R drives or DVDROM drives. For the disk subsystem though, I do see a real difference. I think the randomised I/O you mention actually happens most of the time with a real working system (certainly my systems work for their living ;-). I've yet to see a benchmark that actually reflects the reality of life as a software developer.

Jon.

Re:Benefits of SCSI?

[drsmithy]

My other Windows system is entirely SCSI based and never bogs down in the same way (and before you ask, yes, they have similar RAM, M/B, CPU, software load...). In fact, it's usually CPU bound.

What type of IDE controllers and drives ? Do your drives have 8MB of cache on them ?

Re:Benefits of SCSI?

[JKR]

What type of IDE controllers and drives ?

Maxtor DiamondMax something-740s (40 GB, 7200 rpm) on Intel i845 boards (ICH4 south bridge I think)

Do your drives have 8MB of cache on them ?

No, neither do the SCSI disks. I am contemplating replacing the IDE drives with WD special editions, but I think I might wait and see how SATA pans out. The SCSI disks are 2 year-old IBM (probably 2nd generation) 10K RPM disks - possibly the access time is what makes the difference for my work load. Certainly the head rate from them is nothing special these days.

Possibly it's all perception, but a SCSI disk subsystem seems to make a overall better balanced system which doesn't lock up solid thrashing the disks. That said, if SATA / SAS takes off I might well go for SATA RAID on my next system; SCSI IS expensive and the heat and noise problems I've had with one of my systems might swing it.

Jon

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.

Re:Firewire?

[khuber]

Firewire (IEEE 1394a/b) really isn't the right technology for disk data transfer. It's an extremely sophisticated interface that has features for synchronizing realtime multimedia stuff. It's also expensive.

-Kevin

Re:Firewire?

[iotaborg]

I suppose the main issue is that no one makes true firewire hard drives (afaik), so a firewire bridge would reduce performance. Though adding more firewire channels does seem a lot cheaper than fewer scsi channels.

Re:Firewire?

[gilesjuk]

Creating another serial bus is pretty dumb though. Surely we should be moving towards a world where you can plug your hard disk into any computer, your scanner into your mobile phone, your printer into your digital camera?

Why not create a serial bus with many different speeds depending on the application required, make a wireless version too. Why do we need bluetooth, 802whatever, USB, firewire, serial ATA and now serial SCSI? it's just in the interests of hardware vendors to make all these different technologies.

Re:Firewire?

[Catbeller]

Noooooooo, Firewire is not expensive. It's a cheap chipset on the mobo. It's a cheap chipset anywhere.

Re:Firewire?

[SoupIsGoodFood_42]

If you read the firewire specs, you'll notice it can go upto 3200Mb/s if you use good fiber, or short copper. www.apple.com/firewire and download the PDF, it has a chart with the speeds for the different cables and different lengths.

I'm not saying it's a good SCSI replacment or anything, just making a correction.

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:no longer pronounced "Scuzzy."

[vistic]

The way I read the article title in my mind was "serial scuzzy"

Re:no longer pronounced "Scuzzy."

[quintessent]

Scuzzy? Ask any Mac user. It's pronounced "sexy".

Does SCSI now compete with firewire2 ?

[ozzee]

Firewire2 or IEEE1394B is already shipping and purports 3.2Gb/sec.

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

It's coming to a point where the difference in connection standards is so unimportant that you can see that in the not so distant future you'll be wiring up every peripheral (including your monitor and keyboard) with the same type of cable and the old Sun adage - "The network is the computer" becomes literal.

Re:Does SCSI now compete with firewire2 ?

[iotaborg]

1394b, or the current shipping firewire, is just 800Mbps (Which was just recently released too).

Re:Does SCSI now compete with firewire2 ?

[ozzee]

What 10Gbit Ethernet? Obsolete Ethernet is 10Mb. Typical current Ethernet is 100Mb. Up and coming 1Gb Ethernet is appearing.

Where have you been ? I've been using 1000BaseTX ethernet for over a year. Right now I would only buy a machine with a GigE port. The switches are still a little pricey but they will come down.

10 Gbit was ratified last year. See here. It's only multimode fibre though.

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?

Re:Does SCSI now compete with firewire2 ?

[Tailhook]

Where have you been ? I've been using 1000BaseTX ethernet for over a year. Right now I would only buy a machine with a GigE port. The switches are still a little pricey but they will come down.

Well la-de-da. You have been using 1000BaseT for over a year. You do realize that is 10 times slower than what the poster suggested using, correct? That happened to be my point.

100BaseT is the common medium today. While you may be on the cutting edge, the vast majority of build-outs in recent times is 100BaseT. Typical build-outs are still not specced for 1Gb operation at this time. Perhaps your misconception is due to a narrow view of your personal collection of gear and lacks actual experience in contemporary infrastructure specs?

10GBASE was ratified about 180 days ago. I can forgive the storage industry for not having faith! You can expect to wait a couple years before 10GBASE switches appear in the pipeline from vendors that matter. You can further expect that adopting such hardware will be risky and troublesome for a couple years after that. The Catalyst 6500 family of Cisco hardware doesn't do 10GBASE, and this is about as good as you'll find in typical corporate network cores. Probably not a feasible SCSI bus.

Re:Does SCSI now compete with firewire2 ?

[ozzee]

Well la-de-da. You have been using 1000BaseT for over a year. You do realize that is 10 times slower than what the poster suggested using, correct? That happened to be my point.

Well doody hooty. Get a life. .... and learn to write what you mean to write.

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:Fanboy?

[cliffy2000]

Don't you mean Sk8rboi? Ha'doi!

Re:Firewire is not fast enough

[benzapp]

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

I quote from the article you posted: The current generation supports transfer speeds of 800Mb/s (100MB/s, the same as most ATA controllers).

This discussion is about Serial SCSI which will have a peak throughput of 384MB/s. Clearly, firewire is insufficient.

SCSI?

[The Notorious ASP]

SCSI = Small Computer Systems Interface.

If it had been up to me, I would have moved the vowel sound and called it "Sexy" instead of "Scuzzy"

Re:SCSI?

[Hes Nikke]

i remember when i thought it was "Sdandard Computer Serial Interface"

and it was pronunced "Ess-See-Ess-Eye"

ahh... the ignarance (and golability) of youth

Re:SCSI?

[TheCrazyFinn]

That was Apple's semi-official pronounciation for years.

Price of cables

[bobbozzo]

Hopefully, this means prices of SCSI cables will come down from the current insane levels, as a serial cable is much easier to make than a twisted many-wire ribbon.

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.)

Re:why is serial better?

[Anonymous Coward]

crosstalk!!!!! current running through a wire creates magnetic fields that affects neighbouring wires...if there's only one wire, there's less interferance.

Re:It's already here...

[autocracy]

Different physical busses are a good thing. They're not working in competition either. The SCSI protocol is distinct from the media that implements it. This is like saying fibre is better for connecting computers, so all those people working with copper should just stop competing.

Realistically, how many drives can use that speed?

[beavis88]

I can't think of a case where I've seen single-drive performance approach 100MB/sec...even the 15k RPM SCSI drives. Perhaps I'm underrating the importance of headroom for higher speed bursts, but it seems that largely the bus has been way ahead of the drive for a long time now.

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.

Re:Yup -- post is wrong, eds please amend

[0x0d0a]

Actually, you are assuming that that is the speed per wire which isn't right.

No -- I meant the whole bus.

320Mbps = 320 / 16 = 20Mbytes/s

It's not 320Mbps. It's 320MBps, which is for the whole bus.

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.

Re:A couple of notes

[araemo]

"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."

Well, 600 MB/s is 4,800 Mb/s, or 4.8 Gb/sec.. so.. 2Gbps is under 600 MBps...

Re:A couple of notes

[AbRASiON]

But is it the same power connector!!!!!!!!!!!! (insert conspiracy music)

I refuse to beleive this industry is plotting a way to make things EASIER for us - it's NOT possible, somewhere the little marketing guys are masturbating and rubbing their hands together right now with their pinky finger to their mouths uttering "millions of dollars,... millions!" (insert evil laugh)

Seriously - is SAS and SATA are identical cable wise, this will be a damn sexy thing.

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

In fact...

[rmdyer]

You are right. This is the future...parallel (multi-channel) optical serial.

http://www.xanoptix.com/xtmseries.htm

+2

Crimping

[hackwrench]

Why not crimp the twisted pair wires like network cable?

Re:Crimping

[shepd]

I'm pretty sure cause just like network cable, you'll still have to spend a bunch of time sorting out the conductors...

Try crimping a 50 pin IDC ribbon connector. Now crimp 3 1/2 network cables. Which takes way less time? :-)

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.

Re:Here's a shot

[silas_moeckel]

Lets not forget cable lengths especialy with differential. Were talking about a LOT of drives on a server it's pretty normal to have at least one external chassie on a file server with say 14 disks attached. ATA only goes 18 inches or some such vs SCSI thats rated in meters. From the looks of this it's a step backwards or were moving to Fiber channel for the external stuff and religating SAS to internal expsnsion of low end servers (a lot of my high end servers dont contain any disks)

Re:why is serial better?

[bluGill]

In addition to the other posters (who are correct), minute differences in the wire length and composition mean the signals arriving at the speed of light often to not arrive close enough to the same time on parrell wires in the same cable to be considered close enough. With a scsi bus it is common for several signals to be in the wire at once.

SSA's revenge...

[Psyko]

For some reason I'm having flashbacks to IBM's Serial Storage Architecture (SSA) and it's failure to become a widespread standard when it was put up against FC-AL for a scsi drive interconnect... I used to use SSA quite a bit and was happy with it at the time. Nice small 4-wire connectors, redundant pathing to the drives by default (serial looping). Good throughput, high number of devices per chain, etc. etc.

Actually I just checked and IBM still sells the 7133's. The product line has to be pushing 5+ years old now and it's still only running at 160MB/s as well. Maybe with these new drives coming out they will reintroduce a modified version of SSA to fit new standards...

Re:SSA's revenge...

[haraldm]

This isn't entirely true. In 1997 when I worked for IBM I would have gotten all the specs from the EMEA storage product manager. I also had contact to one or two skilled developers who were more than anxious to start programming. I had adapters from Pathlight and IBM. The only part that was missing was an 7133 or 7131 or two. I couldn't get the hardware for more than 90 days internally. That was the IBM process, and IBM wasn't a lot into Linux back then. That was the problem, otherwise we would have had Linux SSA device drivers in the end of 1997. Part of the story is documented in the original Linux High Availability HOWTO (which is utterly outdated because I don't actively maintain it any more).

Now in 2003 it makes no sense to re-start this effort I guess. Although there are probably hundreds and thousands of "full metal" 7133s around which are replaced by SAN technology their storage capacity isn't what people want today. As for manageability, it makes more sense to put them behind a SAN-SSA gateway (which the ESS basically is).

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

I'm so confused. It's not Firewire?

[Sloppy]

I thought IEEE-1394 a.k.a. Fireware, was the serial version of SCSI-3. No?

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:No SAS drives on SATA

[AbRASiON]

HERE HERE to this post!

Problem is the licensing / costs / something somewhere will make these chips not just be 1 or 2$ more than SATA chips on the board - it will be like double if I know SCSI stuff! :(

Also SATA is going in the CHIPSET shortly and getting it's own bus so it's not going over PCI, (speeding it up ever so slightly) this will be great but it will mean that adding SAS to a board means external chips, which means costs, which means less manu's will do it :(

Be nice if they just said fuckit and made ONE host controller type (SAS / SATA in one) - put it in to most (all eventually) chipsets and the consumer simply decided if he / she wanted to hook up SAS or SATA disks

but hey ... that would be effecient and cool - of course it won't happen!

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.

Re:I'm so confused. It's not Firewire?

[Anonymous Coward]

IEEE1394 is a memory transaction based while SCSI is packet based.

Re:IBM's had this for several years, it's called S

[zenst]

Indeed and you can multipath discs/loops across adapters to gain 80MBps as well as redundancy adapter and cable/loop wise. Yes the shark has loads of these and a couple of rs/6000's inside loaded with SSA adapters. As for the distances, well you can get several kilometers with a fiber ssa adapter. There's a few airports that use this in a redundandt way mirroring data to the other side of the runway/airport for best data riliance given that a crashed aircraft can only rely at best take out half the airport and these are very very big places. Question is now why dont IBM muscle in by selling cheap adapters or do favourabvle royalaties on the SSA interface.

Infiniband

[B5_geek]

This is old information, and has been part of the Infinibad proposal for quite some time. Good news for you AMD-Fanboys: Infiniband is part of the HyperTransport scheme too. A+B=C Hopefully we will see a natural progression to integrated CPU-I/O controller at FULL CPU speed.

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???

Confirm that

[GunFodder]

There is exactly one IDE disk that runs at 10k RPM. This is the average speed of SCSI disks, and several run at 15k. SCSI seek times are usually lower as well. So it can safely be implied that SCSI hard disks are made to higher standards.

Re:Confirm that

[quintessent]

No. More money doesn't always mean better hardware. Of course, they want you to think the hardware is better. But it isn't a sure thing.

Re:Confirm that

[dotgain]

I don't think you paid attention to the parent post - he didn't say SCSI is better because it cost more, for that is not always the case. He said that only one IDE disk spins as fast as 10krpm, whereas some SCSIs do 15k, and most do 10k.

Thanks for reminding me, Gun Fodder, that this is the reason SCSI disks are of higher quality.

It's not that IDE drives couldn't achieve 15krpm, just that there doesn't seem to be the demand yet. Perhaps IDE controllers can't handle the throughput that a 15k disk affords.

No. This is a common misconception.

[merriam]

-- if you're serious. The moderators seem to think so.

It will sometimes make sense to use multiple serial connections between two points, but that is fundamentally different from a parallel connection.

Two serial links would not have to be mutually synchronized, and they would be redundant. Two lines of a parallel link, in the usual sense of the term, are always synchronized, and if one fails, the link fails. At today's speeds, parallel transmission makes sense only over short distances.

In any case, when you need more speed (and not more reliability) it will generally make sense to upgrade to a faster type of serial connection rather than to double up. Of course I'm talking about storage devices in the forseeable future. If in 50 years typical modular storage devices are the size of pollen grains, who knows?

Tim to get rid of the cables - just pug the drive

[xtronics]

Seems the data rates could be pushed - Probably requires an extention of the ATX standard. The only reason to moun the drives to the Chasis is for the bit of heatsink it provides.

solutions for hard drives improves both

[GunFodder]

People want hard drives that are faster and have more capacity. The economical way to get larger capacity is to increase areal density, which means you can pack more bits on less disk. If rotational speed is maintained then the added benefit is that bandwidth is increased.

The best way to improve speed is to reduce latency, and that means increasing rotational speed or reducing the size of the disks. Reducing disk size conflicts with our first objective, which leaves us with faster disks. This incidentally improves bandwidth.

So even if hard drive manufacturers don't want to increase bandwidth they end up doing it anyway to meet their other goals. But sequential access is actually quite common in workstations and desktops so it pays to improve bandwidth as well.

Re:solutions for hard drives improves both

[ottffssent]

Close, but no cigar.

Consider a 3-platter design, typical for high-capacity IDE drives. Six read heads float above 6 platter surfaces at all times. Guess how many of those read at once? Yup. One. If manufacturers were worried about transfer rates, they could read from all 6 heads at once. Know what though? Processing that much info at once is hard. Expensive. So they don't do it. Yes, the higher linear track density (not areal density) increases bandwidth if the same rotational speed is maintained, but this speed is limited by the electronics to read the data, which are improving more or less in sync with the mechanical assemblies.

In a theoretical sense decreasing platter diameter decreases STR and decreases performance, but as a practical matter STR has little to do with performance in most applications, and those that require high STR are best served by RAID arrays anyway. Thus there is little practical need for higher-STR drives, which nicely explains why they don't exist. If you're interested in hard numbers, check out Storage Review - they have a long series of discussions and benchmarks revealing the importance or lack thereof of STR on common applications.

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.

Where 3Gbps comes from?

[mr_zorg]

Figure 10 bits (including parity & stop) per byte. Then 300MB/s * 10b/B ~= 3,000Mb/s ~= 3Gb/s. Tada!

SASI

[Detritus]

"Sassy" is already taken. Shugart Associates System Interface (SASI), the predecessor of SCSI.

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:It's already here...

[evilviper]

Different physical busses are a good thing.

Yes, and old ethernet cards had UTP as well as Coax connectors. Different physical busses does not necessarily mean entirely different controllers.

They're not working in competition either.

Umm, what? How did you come to that conclusion? It's obvious that people are going to have to choose between external SASCSI or Firewire devices, and between SASCSI and Fibre Channel. In fact the article even said that SASCSI may well replace Fibre Channel... That's what I call competition.

This is like saying fibre is better for connecting computers, so all those people working with copper should just stop competing.

Again, I have no idea where you pulled that analogy from. I didn't say that Fibre Channel, Firewire, or Serial SCSI should go away... I said they should impliment some compatibility, since they have so many similarities already. So, to use your analogy, it would be as if I said fibre is better, so everyone working with copper should provide fibre capabilities as well.

SCSI ribbon cables & routing

[Penguin Follower]

Hmm, thing is... everyone who has replied to this thread has complained about 50 pin cables... I haven't had a 50pin scsi hard drive in about 3 years. The 68pin cables aren't that big of a pain to me really (like routing an IDE cable IMO, except available in longer length & more connectors).

Other than hard drives, I do have a scsi cdrw drive... It is on a 50 pin cable, but doesn't get in my way.

Re:Mbit != MByte

[Anonymous Coward]

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.

If you bothered to read the second article you'd know that SATA and SSCSI will have compatable physical interfaces, no adapter needed. Who cares if ATAPI is SCSI over a IDE physical interface if i can't plug one into the other without spending more money for a adapter of some sort. Plus if you checked out the specs you'd know that SSCSI is going to be faster than both fibre channel and firewire, niether of which have the physical interface compatability of SSCSI with SATA. next time RTFA.

Already here!

[sconeu]

Guys, we've already had 2Gb/s SCSI for a while.

It's called Fibre Channel. FC can run 2Gb/s full duplex, and I believe the next gen will be 10Gb/s.

rebuttal

[GunFodder]

What exactly is your point? Mine was that STR increases regardless of need because it is a byproduct of increasing the factors that do make a difference to customers (capacity and speed through latency). Oh, and by the way Storage Review will reinforce this point by illustrating that STR has improved dramatically over the years whether or not it is a major factor in performance.

And as a matter of fact it looks like straight throughput does benefit some applications. In particular the Bootup test that Storage Review uses favors disks with good throughput performance. This may be a minor factor for Linux but poor Windows users are often subject to multiple daily reboots.

Re:Mod parent up!

[AbRASiON]

Remember the dilbert one where he discusses the ttp project?

it stands for, the ttp project...

magic, just magic :)

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) :(

Why do we need this?

[Anonymous Coward]

The artical leaves me asking why. This is the closest answer I got.

"IDC analyst Robert Grey said the ability to mix serial SCSI and ATA drives in servers and arrays has the potential to lower total costs of ownership for corporate users while also letting them customize storage setup to meet their needs."

OK, so SCSI costs more. But I see not a single technical reason for this other than economies of scale and the possible extra quality/longer warrenties that go into SCSI drives.

So why create a new SCSI? Didn't SATA take all the best things SCSI offered and added them to the ATA standard like queing? Is there any technical reason SATA can't add whatever SASCSI has? They added DMA ability to parallel ATA-33 which IMHO killed the biggest advantage SCSI had, I see no reason they can't come out with SATA 2004 and add whatever they needed for SASCSI instead of making a 2nd standard.

What does this mean? "Serial Attached SCSI complements Serial ATA by adding device addressing"

That's the only advantage SASCSI has over SATA I got when I read the FAQ.

The rest of the advantages seem to be "it lets you use SCSI drives, which everybody knows are more reliable and cost 10x more", but there is no reason for having SCSI drives. Just build better ATA drives!

more info

[GunFodder]

Storage Review recently reviewed the lone 10K RPM IDE hard drive and there was an interesting quote from Western Digital (the manufacturer). They said they held off on releasing this drive because they needed the enterprise market to support the product, and previous iterations of ATA were incapable of supporting hot-swapping.

This implies two interesting facts: only enterprises are willing to pay the price for 10k+ RPM hard drives and SATA finally has the necessary features to support enterprise usage. Does this bode ill for SCSI?

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?

iSCSI

[XNormal]

iSCSI already looks pretty serial to me when it runs over gigabit ethernet.

This may be intellectual property in action

[randolph]

My impression is the rationale for the proliferation of standards in this area is that various competing vendors want to own them. Can some knowledgeable person confirm that?

I think there'd be considerable technical and cost advantages in settling on one open standard.

Performance benefits using SATA disks on SAS bus?

[Stentapp]

Will there be any performance benefits by using SATA disks on a Serial SCSI bus/controller compared to SATA disks on a SATA controller (especially in a desktop computer)?

Very Easy

[tweakt]

1. connect 15 fast drives in a RAID5 configuration
2. perform a sequential read from a large file (like digital video)
3. you'll peak to full bandwidth

Any I think they ment 3 gigaBITS not gigabytes. SCSI only does 320MBytes/s today, so that would be more than an order of mangitude increase in bandwidth, not very likely.

Serial Attached SCSI Interface

[gr8_phk]

SASI for short. Much better than the pronunciation of SCSI.

FireWire name

[jweeld]

Apple isn't "anal" about the FireWire name. See:

http://www.1394ta.org/Press/2002Press/may/5.29.a .h tm

and

http://news.com.com/2100-1040-928089.html?legacy =c net

Doing my part to correct factual errors,
QED

Re:FireWire name

[walt-sjc]

Actually, the articles you list actually PROVE my statement. Thanks!

If Apple was NOT anal about the firewire name, they would simply let ANYONE who wanted to implement 1394 use the name. Instead, it still must be licensed. What they did is pass the baton to the 1394 people to do the licensing.

Problem is, this was too late. USB2.0 already gained mindshare and a strong foothold. In Wintel land, firewire is all but dead. VERY few manufacturers include it, and generally only on home models to connect with cameras. In the corporate space, it's USB 2.0. (with about the only exception being Sony with a vested camera interest.)

Hey, I don't like it either, but it's reality.

1394b vs. FireWire2

[jweeld]

IEEE 1394b is a specification that supports speeds up to 3.2 Gbps. FireWire2 is essentially slang for the new FireWire devices that support speeds up to 800Mbps.

QED

Re:I'm so confused. It's not Firewire?

[jweeld]

Actually, IEEE 1394 is packet-based.

QED

Re:I'm so confused. It's not Firewire?

[dmayle]

Firewire IS SCSI. SCSI 3 is a huge standard with different feature sets, not all of which are required.

For instance, QoS is one feature set...(Which Firewire supports. It allows a device on the bus to gaurantee that it's going to get a certain block of the bandwidth for transfer.

So... Firewire is a SCSI 3 standard, as are both Ultra160 SCSI and Ultra320 SCSI. It's just that they're not compatible standards (though Ultra320 SCSI has a negotiation phase that could make it run Ultra160 instead)

Re:I'm so confused. It's not Firewire?

[Animats]

Actually, IEEE 1394 is packet-based.

Yes, it is. And it's used as a transport layer for all sorts of things, including TCP/IP and various disk protocols.

Now if I can figure out why my FireWire driver for digital cameras is missing scan lines at data rates that appear to exceed the isochronous spec...

Re:3 gigabit/sec!

[Rellik66]

Imagine what a Beowulf cluster.... Oh, this is too easy

a Beowulf cluster of disk drives would be called a RAID array. sheesh

Re:It's already here...

[autocracy]

And coax worked... I still know of spots using coax because it suits the conditions. I'll stay out of the SASCSI v. Fibre Channel mess, but suffice it to say that there is compatibility in all these devices. They all run the SCSI protocol. The software is a level above the hardware. Just remember the distinction between the two, and where the limiting factors occur.

The other option

[hackwrench]

The other option was soldering. How is it any faster?

Re:The other option

[shepd]

>The other option was soldering. How is it any faster?

It isn't... It's all a slow process with TP cable, soldered or crimped. It's all because you have to deal with individual strands of wire rather than an entire "package".