Slashdot Mirror
SATA 3.0 Release Paves the Way To 6Gb/sec Devices
An anonymous reader writes "The Serial ATA International Organization (SATA-IO) has just released the new Serial ATA Revision 3.0 specification. With the new 3.0 specification, the path has been paved to enable future devices to transfer up to 6Gb/sec as well as provide enhancements to support multimedia applications. Like other SATA specifications, the 3.0 specification is backward compatible with earlier SATA products and devices. This makes it easy for motherboard manufactures to go ahead and upgrade to the new specification without having to worry about its customers' legacy SATA devices. This should make adoption of the new specification fast, like previous adoptions of SATA 2.0 (or 3Gb/sec) technology."
Let me know when we hit 1.21 GW -- then I'll be excited!
"The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants." ~Thomas Jefferson
Devices which aggregate themselves as a striped array behind a single eSATA/SATA interface. While the individual device may not be able to pump out enough data, they can in aggregate.
Wow, both your numbers are wrong. SATA 2.0 has a theoretical transfer rate of 3Gb/s, not 3GB/s. It also uses an 8b/10b encoding, so 3.0Gb/s translates to 300MB/s. Data throughput will be less than that, thanks to control protocol overhead, though the overhead is very small.
Modern drives do seriously better than 25MB/s. Seriously, go look at benchmarks. Also, SSDs, which are a very real design influence on things like SATA, are already getting close to the 300MB/s mark.
Exactly, it's not like technology advances or anything.
The spec as we have seen with most other transfer specs have little to do with real world device designs. Hardware interfaces (much less devices) languish in the "has to cost less than x per part" hell... But you bet your ass they'll put a SATA 3.0 up to 6GB per second label even though the actual device isn't designed to transfer more than a fifth (peak) of the spec. data rate.
Platform advocacy is like choosing a favorite severely developmentally disabled child.
No, because SAS will always be more expensive than SATA.
Current SSDs are very close to the SATA 2.0 limit and the performance of flash is about to double thanks to ONFI 2.0, so we can expect SSDs to quickly adopt SATA 3.0.
I've lost 3 drives due to plugs breaking off into the SATA ports on the 3.5" drives
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
Actually the limit is 300MB/s which some of the new drives are very close to reaching. One more generation of SSDs and they'll be bottlenecked by SATA 2.0.
What about us using MFM drives with removable platters?
---- Booth was a patriot ----
I think in a years time frame, we could see the 6 Gb/s passed with the way SSDs are going. To make this standard is dumb. If we're looking for speed, SATA 6Gb/s is not it and this ancient CHS scheme has to go to accommodate a better way to map, access and control data. Ultimately, we need to have these devices understand & control the file system. (Trim does this for SSDs) For example: The OCZ vertex nearly saturates the 3Gb/s mark already. They only way the drives 'fail' to accomplish this sustaining speed is with random writes, typically which occur when writing data to a spot marked as available when the NAND isn't zeroed, it either has to re-zero or move on. If the drive knows that the OS is deleting a file (not marking the site, as available) then the drive can zero automatically without you noticing. Its only in certain conditions, these drive don't Consistently perform at peak performance: Free space not consolidated, Free space not zeroed, Swap file creates random writing (slows performance), Indexing is now useless with .1 ms seek times. Using write filters, or something that converts random writes to sequential writes (through buffers, caches or drivers) greatly enhances speed, such as the MFT Software or even windows SteadyState for the devices.
I like the idea of the 'RAM socket' interface as someone stated above. These devices i think work better in a parallel manner. Most work like this internally anyway.
1.21 Joule Watts?
WTF is 1.21 m^4*kg^2/s^5 good for?
You do realize that at either end of a Parallel link you'd have to re-serialize right? That's what PATA does. So you still need the high clock rate regardless of how much you parallelize it on the wires. That's extra hardware, and another piece the needs to be be really fast. Then you also have issues with maintaining clocking integrity over parallel lines, which gets tricky at high data rates.
Right now, our technology is better in going pure serial. In the past, it was parallel. It might swing back and forth a couple of times between the two in the future. But make no mistake: right now, on commodity hardware for drives connected via cables, serial is pulling ahead in the speed war.
The problem with parallel is that you can't crank up the clock speed because you have to make sure that the signal on each line is combined with the ones from the other lines that were sent at the same time. This limits how fast you can send the send the bits (if the time being bits is comparable to the skew time, the receiver will not be able to reliably reassemble the data) and how long the interconnect can be (skew being linearly amplified by length). It's not for nothing that PCI has been replaced with PCI-E, PATA with SATA, SCSI with SAS. USB and IEE1394 would be impossible with parallel. Serial communications are more reliable and more scalable (one big exception -- wireless RF, but that's not what we are discussing here).
Multiprocessing, incidentally, has nothing to do with it -- the software interface to a storage device hides all the implementation details (PATA/SATA, for instance) anyway. The hard part in multi-threading IO-intensive apps has quite a bit more to do with latency issues and atomicity guarantees (the complete lack thereof) rather than the inability of the storage device to do 2 things at once (which, for a physical disk, is impossible anyway, meaning that it would have to back-convert into a serial process anyway).
Why? Do you have a hard drive that can even saturate a SATA I bus?
Not a typewriter
If my understanding of the technology is correct, the seek time on most hard drives already limits drive access speed to typically be slower than 3Gb/sec. Would this rely on a transition to Solid State Drives for any noticeable difference in performance?
The seek time has nothing to do with the throughput. The seek time refers to the latency between when a read command is issued and when it begins to be fulfilled. The throughput refers to the data transferred per unit time during fulfillment.
Here's a nice car analogy for those of us in New England -- consider the Mass Pike versus I-93. The Mass Pike has a very long seek time from the onramp because of the toll lanes (and the mouth breathers that won't get a transponder even though they are now free and clog the automatic lanes) but once you get on the highway, you can go 80 MPH until your exit. On I-93, by contrast, you can get right on, but you will be going 30 MPH for the duration. Of course, if you drive down to CT and get on I-84, you have a low-latency AND high throughput highway but if you drive too far down to, say, the Bronx, it becomes high-latency and low throughput.
where there are multiple INDEPENDANT heads reading/writing on multiple platters all at the same time
The entire idea of 'heads' should be forgotten. Mechanical drives should be sent to oblivion and we should welcome your idea of parallelism on solid state solutions.
Fact: Everything I say is fiction.
Prepare for mass storage connected to the north bridge.
/me wanks furiously!
Sequential reads on large-capacity drives are often in the 70-90MB/s range (yes MB, not Mb), bursting into the 200MB/s range. Hell, I've seen 50MB/s+ for at least the last half a decade. High-quality (read: expensive) SSDs can roughly double that.
And of course, the spec is in gigabits per second, not gigabytes, and includes overhead. Actual supported, sustained transfer is supported at 150MB/s, 300MB/s, and 600MB/s on SATAI-III respectively.
How are sites slashdotted when nobody reads TFAs?
Yea, while swearing at Apple 24/7 for giving SATA1 with Quad G5 Workstation (most expensive G5), I purchased a very nice performing Western Digital Caviar 1TB drive having 32MB cache. It took a while to figure that I can't really saturate SATA1 bus, even with "fill with zeros" (format) of OS X, it went up to 140MB/sec. Of course, Apple expects me to buy a ATTO like high end card if I need more bandwidth.
What matters is SSD, that is why they release the spec right now. If you have enough money to setup a very high end (not toy-like) SSD right now, you will see SATA2 is the bottleneck. People were already talking about a different standard or even getting rid of SATA alltogether for them.
Actually, there really isn't much difference. The main difference is that hard drive manufacturers build their SCSI/SAS drives better than their IDE/SATA drives, because most SCSI/SAS drives are going into servers.
The performance difference historically was much faster and that's the reason why SCSI is used in server hardware, but now it's mostly a matter of economics and pricing.
My blog
And what you clearly missed from the post you're responding to is that the clock rates that you can get from serial are so much higher than what you can do with parallel that it more than offsets the disadvantage of serialization.
There are two things that limit the speed of parallel interfaces. As the GP mentioned, one is signal skew. The clock rate has to be slow enough so that the receiver can sample all data lines at the same time and get them all within the data eye. The second is that the data lines are single-ended, meaning that there's only one wire per signal. The clock rate has to be slowed down to ensure that the signals have reached full on or full off at the other end and that they're noise free.
High-speed serial interfaces use DIFFERENTIAL SIGNALLING. The signal is transmitted over two wires that switch in antiphase. You decode them by comparing them. This has several beneficial effects. One is that noise affects them the same, so even if they're both offset by noise, they compare the same. The other is that now you don't have to wait as much on the effects of resistance, capacitance, and inductance. You can reliably decode the signal before the transitions are complete. (Look up "slew rate".)
So, using the same basic silicon technology, you can get a single differential pair to transmit data MUCH faster (in bytes/sec) than you can with parallel. It's interesting to see how technology transitioned from serial to parallel (wider means more bits per second), back to serial. The reason they didn't just stick with serial was that they just didn't have the technology to make the I/O drivers go that fast until recently.
IIRC, A 1x PCI Express channel is a single differential pair for data. (I think there's a side band channel and some other stuff.) This is just like DVI and SATA. 16x PCI Express is sixteen 1x channels. The trick here is that although data is interleaved across all 16 channels, those channels are not syncronized with each other. They are out of phase, and the the data is just put back into phase at the receiver.
And the OP is, frankly, unaware of the history of SCSI and PATA. Those big wide cables are deprecated for many reasons: one is their expense, another is their fragility, and another is the incredible variety of vaguely distinct, and often stupidly different, specifications for such broad interfaces. I had to deal with that debris, for decades, and it was extremely painful.
The amount of time saved in consistent, small interfaces having fewer things to screw up is enough, by itself, to make up for the expense of any drives lost from the fragility of the SATA connector. I remember the amazing crap shoot it used to be to design a SCSI chain of devices, the awful incompatibility and expense of the cables even for what were nominally the same type of SCSI, and tendency of those connectors to bend pins or fail under stress.
Give me SATA (and its low cost peer for external devices, USB), any day over the technically superior but less consistent SCSI and firewire.
Well, this may not be exactly what you were getting at, but I'd like to split hairs here anyway, and divide this into two separate issues that SATA/SAS resolved.
For best results it's important to model the cable as an RF transmission line, with a specific impedence. An ideal transmission line has the important qualities that all the energy you send from one end will arrive at the other, and none will be reflected back to you. To get reasonably close to this ideal, we space the wires we use a fixed distance apart (in relation to the wire's diameter), choose our dielectric (insulating material) carefully, use terminating resistors at both ends, and keep the line a simple line (no tees, etc.)
For those of you who cut your teeth on parallel SCSI, 10base2/10base5 Ethernet, or Apple LocalTalk, you'll wax nostalgically at just how much of a pain in the ass this was.
For those of you who have only messed with parallel IDE, you'll wonder why you never had to deal with this. The reason is that IDE cheated a little bit - they only terminated the controller (motherboard) side of the bus, and let the signals reflect off the other end. This left only a master/slave/cable-select jumper to infuriate you - but it also limited how long an IDE cable could be and prevented them from jacking up the clock rates on it.
SATA/SAS fixes this for good by limiting you to one device per cable ("port", not "bus"). Both ends are hard-wired to always terminate and any cable problems are limited to a single drive.
The other issue you may have been referring to is balanced (differential) vs. unbalanced signalling (where one wire is held to ground and the voltage read off the other wire). Electrical engineers do commonly call unbalanced signalling one wire because ground is so boring that they never bother to connect it on their schematics, but it does have to be connected in real life and coax Ethernet/most old SCSI/Parallel IDE/RS-232/VGA still used two wires per signal. Balanced/differential signalling (LVD/HVD SCSI, SAS, SATA, 10/100/1000baseT, USB, telephone lines, T1 lines, LocalTalk, etc.) allows for the can't-imagine-life-without-it common-mode noise rejection technique you describe.
marked your post Informative.
Quack, quack.