| Quantum Atlas 10K
by John Reynolds
|
||||
|
As a hardcore gamer, I'm infatuated with high-end computer hardware. It's a strange attraction of mine, because while I'm loathe to shell out $50 for a new game that I've been waiting on for months, preferring instead to hold off until it goes on sale, I won't hesitate to pay $300 for a new 3D accelerator or $500 for a new hard drive. And the latter is exactly the newest addition to my gaming box, a Quantum Atlas 10K 9.1gb SCSI drive. I love all things SCSI (Small Computers Systems Interface), whether it's a controller, hard drive, or CD-ROM drive. . .it's just one of those PC acronyms that commands the respect of your gaming friends and the admiration of all women. Well, maybe not that last part, but there is something about SCSI that sets it apart, whether it's the incorrectly-perceived difficulty of its proper configuration (I've seen MCSE network administrators' eyes glaze over when confronted by SCSI) or the inflated price stickers when examined next to comparative IDE devices. And the Quantum Atlas 10K is merely the newest drive in a long history of SCSI devices to find a home in my gaming rig. Having dropped the entry-level Viking series, Quantum now offers its flagship line in two flavors, the Atlas 10K and Atlas IV. Sporting 2mb of buffers and an incredible spindle speed of 10,000rpm, the Atlas 10K is also the first drive on the market to support the new SCSI interface, 160/m. Quantum has been including this feature on all their spec sheets and marketing statements for the Atlas 10K, and thank god for its arrival, because personally I was getting worried about my old Ultra2 bus's 80mb/sec throughput and its ability to handle the sustained transfer rates of when I go out and buy five or six Atlas 10Ks. All sarcasm aside, there are, as of yet, no Ultra 160/m controllers on the market, but the 10Ks run just fine on older Ultra controllers. Having an ASUS P2B-S motherboard as the backbone of my personal gaming machine should have made installing the Atlas 10K a breeze. Sporting Adaptec's AIC-7890 chipset, the board comes with three connectors, two (a 50- and 68-pin) for single-ended and one (68-pin) for differential devices. The P2B-S keeps these buses, which operate with incompatible signals, separate through the use of the AIC-3860, a transceiver chipset that divides the single-ended (SE) and low voltage differential (LVD) segments, thereby bridging the compatibility gap. This setup also allows the full potential of the Ultra2 bus (80mb/sec) to not be hampered by older, SE devices, which, when connected to an LVD chain, force the bus to default to slower SE speeds and shorter cable lengths. |
 ASUS P2B-S
One of the most important issues for configuring a stable SCSI system is proper termination. Ever stand on a beach and watch the waves lap at the shore? Well, if you considered each wave as a signal on a SCSI bus, a beach would then be an unterminated end of a chain because the waves do not stop after they strike sand but instead roll back into the next wave, or signal, causing interference with this new wave's ability to reach the shore. However, if the beach were properly terminated it would capture, or absorb, the individual waves so that each one would have a clean shore to wash up on.
With the P2B-S, SCSI termination is configured in the BIOS settings. Worth noting is that LVD buses are usually terminated through cabling rather than jumpering the last device on the chain. A simple diagram illustrates this: <
With SE buses, that second device would require active termination, since it's effectively the end of the chain. With most LVD devices, there are no pins for jumpering on the drives themselves because the cabling has a termination block attached at its end. Therefore devices can be moved up or down the various connectors on an LVD cable without the worry of proper termination or the need to reset jumpers.
Another consideration in configuring SCSI chains is device IDs. These IDs are the address that each device is assigned, and consist of specific numbers that range from 0 to 15. Set with jumpers on the individual drives, the most important thing is that no two devices may use the same number, or ID, and any attempt to do so will most likely result in the system hanging upon bootup. Another consideration is priority: SCSI buses read device IDs from 7 to 0 and then 15 to 8.
Go to Page Two
|
|||
|
Copyright © 1997 - 2000 COMBATSIM.COM, INC. All Rights Reserved. Last Updated July 21st, 1999 |
||||
