Thi page is now pretty much of historical interest only. If you would like to know the origin and evolution of early SATA then read on, otherwise go direct to the SATA II page.
Parallel ATA or IDE was the dominant PC interface protocol for desktop PCs in the 1980s, because of its simplicity, good performance, and low cost, but was more or less replaced by SATA a few years ago. One or two specialised systems do still use it. Parallel ATA has been enhanced over the years, data transfer speed improving from 3 MB/s to 167 MB/s. Other improvements include
However Parallel ATA had a number of limitations that made further development difficult
Parallel ATA uses 5-volt signaling, which does not match modern low voltage chips. Each ATA channel needs 26 * 5-volt signals, and large physical chip pads to accommodate the high pin count. The chip pads are now almost larger than the chips. The decline in chip sizes means the smaller silicon geometries require lower voltages. This makes the 5V parallel ATA requirement difficult to engineer.
A parallel ATA cable is a wide, flat 18-inch ribbon. It is difficult to route this cable inside a chassis, and its bulky size restricts the cooling air flow, which creates hot spots. This is especially problematic with today's increasing processor and graphics subsystem power requirements. The fact that the cable length is limited to 18 inches limits the choices for adding peripherals and internal drives.
It is necessary to use some sort of redundant or parity information to check that data is being transmitted properly. Early ATA disks did not check the data at all. Cyclic Redundancy Checking (CDC) was introduced with UDMA, which verifies the interface data, but not the command data. This remains a potential error source.
Traditionally, serial communications were regarded as slow, but new standards such as USB 2.0, Firewire, Ethernet, V-Link, MuTIOL, HyperTransport, RapidIO are all serial-based, and are fast.
Version 1 of Serial ATA (SATA) was introduced in August 2001, and fixed the issues with Parallel ATA.
SATA3.2 Express, the more recent version, can run betwwen 8 and 16Gb/s over an FC connection.
SATA uses two data channels - one for sending and one for receiving. The signals run phase reversed, so interference is self-canceling. This means it is not necessary to twist the wires to avoid cross-signal inductance. However, there were reports of data corruption on SATA disks, and it wass believed that this corruption is due to the unshielded nature of the SATA cables. Some SATA cables are shielded now
The maximum data transfer rate was increased to 16 Gb/s. This is theoretical burst speed, and actual sustained speeds are likely to be nearer half that
Serial ATA just requires a 500 millivolts signal. This fixes the issues with the 5-volt signaling requirement for the parallel ATA interface.
Signal error checking and correcting capabilities are improved, and end-to-end integrity of both transferred data and commands can be guaranteed across the serial bus.
The Connection Cable now contains seven wires instead of 40. The Connectors measure just 8 mm wide, much smaller than the large and cumbersome 40-pin connectors required by parallel ATA. The thin, flexible serial cable can be up to 1 meter in length, which makes it easier to route inside the chassis. This, in turn means that housing designs can be smaller, or more ATA disks can be fitted inside a chassis.
Also, Serial ATA is backward compatible with the parallel ATA interface. Because the initial Serial ATA architecture changes the physical interface layer only, it maintains register and software compatibility with parallel ATA. No device driver changes are necessary and the Serial ATA architecture is transparent to the BIOS and the operating system.
The command queuing extensions are mainly aimed at enterprise storage applications.
Disks essentially contain a sequential series of concentric circles of data tracks. The data tracks are accessed by read write heads that move across the disk to access different tracks. Data within each track is accessed as the disk spins under the heads. Applications rarely request data in sequential order, but usually request data randomly from different parts of the disk. It takes a considerable time to move the heads, or wait for the disk to spin (in CPU time sense) so if the heads have to traverse back and forward over the disks, performance will suffer. When several applications are multi-tasking, and all accessing the same disk, the problem is exacerbated.
Native Command Queuing (NCQ) is intended to fix this problem. Commands are queued within the drive's internal command queue, and can be reordered to minimize head movement. NCQ is internal to the drive, and allows several commands to be active and queued internally in the drive at the same time. The commands can be re-ordered in the queue to minimise the amount of head movement needed to read all the data in the queue.
This process is sometimes called elevator seeking. Consider an elevator in a tall building. It will be given commands to proceed to a floor, depending on which button is pressed. Someone enters at the ground floor, and presses the button to floor 21, then someone else at floor 10 presses the up button to request the elevator to stop. It is inefficient for the elevator to go straight to floor 21, then back down to floor 10 to pick up the next customer. The 'button' commands will be sorted in order, and the elevator will stop at all required floors on the way up. Disk elevator seeking, or NCQ, works on exactly the same principle.
NCQ also allows commands to be outstanding in the drive, while passing command complete back to the application so processing can continue, and more commands passed to the drive. Applications and operating systems are increasingly taking advantage this facility.
back to top