Navigate: Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home	.	.
Prices: Mainboards ABIT ASUS Chaintech Shuttle Soyo Tyan CPU Intel P4 2.4C-800 P4 2.6C-800 P4 2.8C-800 P4 3.0-800 P4 3.2-800 AMD AthlonXP XP 1700+ XP 2000+ XP 2400+ XP 2500+ XP 2700+ XP 3000+ XP 3200+ Athlon64 Athlon64 3200+ Athlon64 FX-51 Opteron Opteron 240 Opteron 242 Opteron 244 Opteron 246 Memory Corsair Crucial Kingston Mushkin OCZ Search Prices:

What happens if the effective internal performance exceeds the effective host transfer rate? As long as only the transfer capacity and potential bandwidth is concerned, nothing is going to happen. However, if there is a massive request of data from the drive and the effective host transfer rate is too low to handle the onslaught of data, the drive's cache will fill up to the point where the heads will no longer be able to read the data out from the platter into the cache until some more data have been dumped from the latter to the host bus adapter.

The problem in this case is that the "window of opportunity" is missed, that is the data are on the platter and the LBAs on those platters are moving away from the head before they can be read. That is, they can be read by the head but the head cannot write them to the cache because the cache is full. The solution in this case is very simple, just wait one rotation of the platter and by then, the cache will be emptied and the data can be written to the memory.

Once the host transfer rate is lower than the effective internal transfer rate (e.g. because of a jammed I/O bus as shown in the illustration or else because the combined media performance of two or more drives in a RAID Level0 configuration exceeds the host transfer rate), the cache fills up and the data can no longer be transferred from the media to the cache because there is no capacity left. In that case, the head will have to skip reading e.g. LBA #1 (as shown above) but since it is necessary for all further transfers, the drive will have to wait one full rotational latency to "get back to business as usual". During this artificially imposed latency, the cache can be emptied by outputting the data to the system bus.

This condition of having to wait one rotational latency is called a Speed Matching Condition, a term I have used occasionally in the last few articles. In single drive configurations, speed matching conditions rarely occur, however, all it takes is two modern drives in a RAID Level 0 configuration and the bus will fill up very fast in sequential transfer tests. In RAID Level 0 configurations, data transfers have to abide by the striping pattern, meaning they are internally scheduled to complement each other. As a consequence, if the first drive misses the target LBA because the cache is full, then the second drive will be subjected to some sort of domino effect, that is, it will have to wait for the first drive to complete the transfer before it can start its own transfer. In other words, each drive can cause a speed matching condition on the other drive(s).

Two Seagate Barracuda SATA-V on a SiliconImage 3112AR controller in RAID-Level0 configuration. The combined sequential transfer rates are higher than what the bus back-end can handle and, therefore, a speed matching condition is created. The problem is only solved once the head goes to more inward located "zones" with a lower sequential media performance. At that point, the measurements "stabilize", however, because of the algorithms used by HDTach 2.61, things still look rather ugly. Part of it relates to the fact that HDTach does not use true sequential reads, rather, it stacks eight consecutive block reads of 1,056 KB that are then written into the drive cache in write-through mode before they are burst into the bus. If both drives start bursting simultaneously or if the bursts are overlapping this will cause bus contention, speed matching errors and other artifacts. In real time operating systems this would not be a problem, neither is it with slower drives but in the current environment (OS AND drive technology), HDTach appears to be out of its league.

A single Maxtor Diamondmax 9 160GB (6Y160M0) in WinBench 99 on a SiI 3114 controller on the ABIT KV8 MAX3 (VIA chipset) appears to suffer from a similar Speedmatching condition as the RAID setup shown above. As soon as the sequential reads are reaching the second zone, which is within the transfer capabilities of the back-end bus, the sequential read data are graphing in a straight line.

Once the host transfer rate is lower than the effective internal transfer rate (e.g. because of a jammed I/O bus as shown in the illustration or else because the combined media performance of two or more drives in a RAID Level0 configuration exceeds the host transfer rate), the cache fills up and the data can no longer be transferred to the cache because there is no capacity left. In that case, the head will have to skip reading e.g. LBA #1 (as shown above) but since it is necessary for all further transfers, the drive will have to wait one full rotational latency to "get back to business as usual". During this artificially imposed latency, the cache can be emptied by outputting the data to the system bus.

In case the entire platter length of the drive(s) is measured from OD to ID, this speed matching condition will only pass when the heads are reading from more inwardly located tracks, that is, zones with a lower effective transfer rate.

next page:    => Stay Tuned For SATA =>