|
Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home |
. | . |
|
Prices: 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 |
LOSTCIRCUITS |
|
|
| Intel i875 - Canterwood SATA and GbE for PAT | ||
| (Review by MS, April 14, 2003) |
At 133 MB/sec bandwidth, the maximum data transfer rates between any drive and the PCI-based host bus adapter cannot exceed ~ 120 MB/sec. The reason is that the bus is shared by data and commands with the latter making up approximately 10% of the total transfers. In light of the SATA 1.5GBs specs, allowing for a total of 150 MBs transfers, it is clear that the PCI bottleneck would eliminate any advantage of a higher interface speed.
Integrating the SATA controller into the ICH offers up to 266 MBs bandwidth for ATA transfers that, admittedly, need to share this bandwidth with other devices. However, arguably, this solution is far superior to the previous PCI-bus based solution. The only situation where, realistically, still a bottleneck could occur is the simultaneous access of a Gigabit LAN connection for large file transfers via Ethernet with simultaneous storage on the HDD or even a RAID setup. Gigabit connections are still the exception rather than the rule, however, the trend is going there and, moreover, large file transfers already are a battlefield over bandwidth between the storage and the networking channels.
The logical solution is to completely uncouple the two paths by giving each their own dedicated or shared bus or access to the system controller and DMA engines. If you think back to the beginning of this review and the huge amount of memory bandwidth offered that, quite honestly, the CPU cannot take advantage of, this is where everything falls into place again. To reiterate, we have a solution offering enough memory bandwidth for saturation of the CPU cache lines and several quasi-simultaneously operating DMA engines. In this context, think HyperThreading, and all of a sudden, the entire concept makes a lot of sense, even beyond or despite Intel's marketing infomercials.

Whoever paid attention to the above will have little difficulties maneuvering around in the block diagram. Aside from the addition of 8 x USB 2.0 support with 60 MBs, the rest, like AGP 8X is mostly window dressing to follow the trend of the times. Full surround sound is also integrated into the ICH5 and needs to be enabled using an AC'97 audio CODEC. Independent channels for GbE (short for Gigabit Ethernet) and I/O traffic allows optimal utilization of the DMA engines for streaming data from one system to the other without bus contention.
We did not talk about USB 2.0, offering 60 MB/sec bandwidth, neither did we mention IEEE 1394 Firewire. USB 2.0 support is integrated into the ICH as well but does not appear to constitute a serious problem with regard to channel contention. After all, adding 60 MBs to 150 MBs still only takes up 210 MBs of the 266 MBs total available. Firewire? It looks like somebody had to bite the dust, but then, we have SIS and VIA as alternatives and firewire can always be integrated via a separate controller.
To summarize this excurse into the why and how to of Canterwood, the new platform is defined rather concisely. What is needed is a high-speed dual channel DDR controller with enough flexibility to accommodate a waste difference of different system configurations in either single or dual channel mode, a Gigabit Ethernet controller plugging directly into the System or memory controller hub and a high bandwidth SATA controller, if possible with RAID functionality. This way all devices are still happy and content with the memory bandwidth available and even the processor itself still gets its fair share.
next page: => Avoiding The Speed Trap =>