Serial ATA and Serial SCSI

aibrahim writes "In the recent Slashdot article about Serial ATA some people wanted to know where SCSI was going, and if Serial ATA could deal with some higher end workstation and low end server requirements. Apparently it has been decided that Serial ATA 2 (pdf doc) and Serial Attached SCSI are the answers."

Re:Where are the drives?

[bjschrock]

The Segate Baracudda ATA V, Serial ATA version is going to be released "this fall" according to a press release I read somewhere. It has a 8MB cache and comes in sizes up to 120GB.

Re:just like the RAMBUS story

[jamesbulman]

Double / Quad pumped rambus channels refer to the frequency at which they are being driven, not the number of traces laid down. Rambus is as narrow as it has ever been.

Re:just like the RAMBUS story

[cheezedawg]

Ethernet has had no problems scaling to higher bandwith while maintaining its serial "bus". Serial ATA is a packetized interface that is more similar to ethernet than RAMBUS. They already have 600 MB/sec SATA on the roadmap.

Re:Internal firewire?

[alienmole]

Current Firewire is half the bandwidth of ATA/100. Theoretically, Firewire can be saturated by a single fast disk, so for internal Firewire you'd want a separate Firewire channel on the motherboard for each disk - but Firewire was really intended to be a serial bus which supports multiple devices. That's why in its current form, Firewire is more appropriate for connecting devices like video recorders, or hooking up a single external drive for data portability, than for internal drives.

It will only support ONE device per channel

[Anonymous Coward]

No master, no slave ... just one lonesome cowboy.

It supports 150 MB/s because its trivial for them to support that speed, because there is only 1 device on the cable signalling becomes very robust. Also there's only 4 pins needed on an ASIC per port, so putting lots of ports on chips is no problem either ... all in all 1 device per port makes perfect sense, cables are cheap and no problem with drives contending for bandwith or needing to support disconnects in the protocol.

Re:So?

[gerardrj]

But the buffers are insignificant. an 8MB buffer will be emptied or filled over the wire in .06 seconds at 133MB/s. So you can't get max throughput for anything longer than about .2 seconds.

Since the caches on the drives don't undstand filesystems or file structure, they can only contain things that have already been read from disk, or assume the next read will be a sequential block and pre-fetch that. More often than not, the cache on the drive does not contain the requested data. The disk cache only helps for small files that are re-read often like directories, and really the OS's disk cache will provide even better performance in these situations. The drive buffer does nothing to increase real-world data throughput on ATA disks, it's just there so the drive makers can claim a really high (wire speed) peak throughput number. Caches do make sense on SCSI drives where the drive can be ordered to read a set of blocks to buffer, disconnect, and later have the blocks read from buffer. During that drive's read phase (while disconnected) other drives can be commanded to read or write data to/from their buffers. This is why SCSI RAID systems outperform ATA RAID systems.

As for the increase in drive throughput from media: if future advances play out the way the industry has advanced in the past, it will be 15-20 years before a drive will be able to move 100MB/s sustained from rotational media. 10 years ago we where getting 10MB/s sustained, today we are getting 20, sometimes 30. Switching to some non-rotational media might see throughput increase dramatically, but all such devices I've seen connect to Firewire or USB[2] thus negating the need for more ATA bandwidth.

Serial ATA is a project in search of a problem, or perhaps more accurately marketing hype in search of consumer dollars.