|
Advice Contact Forum SiteMap Sponsors Home PC Hardware from Made-in-China.com |
. | |
|
Prices: |
LOSTCIRCUITS |
||
| Seagate Barracuda SATA-V Kudos to Cudas |
![]() |
|
| (Review by MS, February 4) | ||
Different interfaces specify different rates of transfer, the most current specs being UATA/66, 100 and 133 with the last implemented only by Maxtor. Running the risk of being redundant, the suffix designates the maximum transfer rate that can be achieved by bursting from the disk's cache. The burst rate depends on the interface frequency which, in the case of UATA-100 is 25 MHz (clock) and in the case of UATA-133 is 33 MHz (clock) using a DDR protocol for 50 and 66 Mbps (Megabit / pin / sec), respectively. The bus interface itself is 16 bit wide (2 Byte) and width multiplied by frequency gives the overall peak bandwidth.
As outlined above, the serial ATA interface only uses one pair of data line each for reads and writes. This means that at a signaling rate of 1.5 Gbit/sec both lines will have to operate at 1.5 GHz. Since it is only two lines, they can be shielded, and furthermore, skew, that is the phase shift between the two lines can be controlled easily.
One inherent risk of any serial protocol is adaptation of the receiver to prolonged signal strings of 0000 or 1111 which can introduce a bias or baseline shift. This can be avoided by introducing calibration bits like a 01 sequence after every byte. the consequence will be that instead of the standard 8bit / Byte conversion it is a total of 10 bits / Byte. Moreover, the added 5th bit (after every 4 bits of data) provides a reliable synchronization point for the embedded clock. This, however, means that the 1.5Gbit/sec translate into 150 MB/sec rather than 1.87 MB/sec. In theory, SATA is still faster than Parallel ATA but keep in mind that this burst rate only applies to transfers from and to the disk's cache.
Different Communication Protocols in Parallel ATA and SATA
Third Party Nature of the Parallel ATA DMA Scheme
One issue more important than the actual burst rate is the communication between the drive and the host bus adapter (HBA). Parallel ATA suffers from several severe limitations, mostly caused by the fact that the drive itself is entirely passive when it comes to the initiation of data transfers. In short, there are two possibilities for Parallel ATA drives to execute commands.
The first scheme is the immediate execution of the command, however, this has the severe disadvantage that the drive will occupy the bus during the entire time it takes to read the data off the media (platter) and transfer them to the controller. This interval includes seek times and rotational latencies. In case the data are already in the cache, this problem is less of an issue.
The alternative is that the drive defers the execution of the command to a later point, or in trivial terms, the drive accepts the command, then disconnects from the bus in order to collect all data that are asked for, move them into the cache, and as soon as it is ready to transfer, reconnects to the bus.
The main problem in this case is that the drive itself has no authority to arbitrate for the bus, all it can do is to set the SERVICE bit as a flag for the controller that it is ready for data transfer. The controller does not see the SERVICE bit until it polls the device the next time to check for any status changes. After detecting the SERVICE bit, the host sends a SERVICE command to start data transfer. In technical parlance, this means that the device is non-deterministic and the transfer mode is referred to as the 3rd Party Nature of the Parallel ATA DMA transfer scheme. What is important here are the command overhead (all commands have to be issued twice in different formats) and the latencies involved. That is, the drive may be ready but the controller is busy polling the other devices (since there are up to four devices possible). In theory, this could make a difference, especially if master and slave devices are present on the same channel. In practice, the polling latencies appear short enough compared to the mechanical latencies involved to not make too much of a difference, regardless of whether a single device or two are on a channel for practical purposes.
If multiple commands are sent to the drive and the drive has to service these multiple outstanding commands, another limitation of Parallel ATA drives occurs since the SERVICE bit, which is a logical true of a single command line within the 40 parallel ATA signal lines cannot, by definition, contain any information about which command is going to be served. As a result, the host does not know, which set of data is going to be transferred until the actual data transfer starts. This piece of information, however is critical to set up the correct DMA channel but it has to be handled "after the fact" in Parallel ATA. In conventional home-office desktop applications, this is somewhat negligible since in most cases the host will issue a single command at the time.
Most of the Parallel ATA limitations just mentioned have little if any bearing in a single host-single drive configuration when running non-multi-threaded software. However, with more complex applications running in parallel or, for example, multithreaded software like audiovisual rendering programs where separate streams of sound and video data are handled quasi-simultaneously, the command overhead of Parallel ATA may become a problem.
next page: => The Streamlined SATA Protocol =>