|Conclusion||Major Premise||The Argument||Argument-part2||Minor Premise|
|Seek/Access||Tekram/Adaptec||This vs that||Misc||Misc config||Misc config 2||Config/Compare||Comparison||Linkage||Home|
SCSI vs IDE Comparison
Both SCSI & IDE are file storage & retrieval systems. A file is stored when it gets written to your hard drive. A file gets retrieved when it's read from your hard drive. Both actions put your storage system to work. Imagine your drive's storage & retrieval system as your local public library, and that the books in the library are the files on your hard drive. The only difference with this library is that you can't get the books yourself. Library attendants must get them for you.
Both the IDE library and the SCSI library employ athletic-looking attendants. They both have rippling arms with bulging biceps. They both can run almost as fast as each other. The SCSI attendants can run slightly faster than IDE attendants, but not much faster. How fast they can run is analogous to STR .. or, sustained transfer rate. That means, the speed they can run once they have the book in their hand. The attendants perform one of two functions:
Store a book
Retrieve a book
When you give them a book, they haul ass to store it, and when you want a the haul ass to retrieve it for you. The problem with IDE is that, when you want a book, IDE library attendants are slow at finding where the book is stored. Finding where the book is stored is analogous to a drive's access time. Drive's that have low access times are fast at finding where books are stored in the library. This should be an easy model to conceptualize.
SCSI library attendants eat IDE attendants for lunch when it comes to finding books quickly. IDE attendants seem to do a respectable job, and indeed they do. But not nearly as quickly as the attendants at the SCSI library. It's not until you pay a visit to the SCSI library that you even notice how sluggish IDE attendants are. IDE attendants run fast back to you once the find the book, but it takes them significantly longer to find your books.
Suppose you give your library attendant a list of 7 books you want. The IDE attendant will get book number one first, then book number two, then three, four, five, six, and lastly seven .. even if this isn't the most economical. SCSI attendants are smart enough to to re-order the way they retrieve files .. depending where in the library the files are stored. For example, it might be fastest to retrieve files files in the following order: 6,1,4,7,3,2,5. SCSI works more like a *team* of attendants .. than IDE's single attendant.
As long as the attendant gets all you books (files), you don't can what order he retrieved them in. Whatever is fastest for him is best for you .. cuz you don't like to wait .. cuz you're a busy man, and have important stuff to do. This intelligent re-ordering for maximum performance is an advantage of the SCSI interface.
Suppose you have more than one hard drive, and you want to both store & retrieve books. The SCSI attendant has a powerful helper named Billy Multitasking, who can retrieve a book while the SCSI attendant is storing a book .. and vice-versa. IDE is a single-tasking interface. In other words, with two drives on the same channel (master/slave), it can't retrieve a book until it finishes storing first.
The SCSI attendant is much better at doing many things at once. He makes a big job look easy .. while the IDE attendant starts huffing and puffing. The SCSI attendant is back saying, "What else can I do for you, Sir?" .. while the IDE attendant is still trying to finish the last job you gave him.
Now if you're the type of person who doesn't go to the library much, you're prolly not gonna notice a big difference between the IDE & SCSI libraries. But the more time you spend at the library, the more you'll appreciate how fast the SCSI attendants are at retrieving books for you.
Note that both IDE & SCSI attendants can run fast with huge books (video & audio files) .. but again, SCSI attendants still get to the big files faster. SCSI attendants have a greater advantage when you want them to retrieve a large number of small books at once. This is analogous to what it takes to run your operating system, which is full of small files.
SCSI has less of an advantage when you only want to retrieve a small number of large books. It still has an advantage, tho not as large as when many small books (files) are involved. That's why it's good to put your operating system, apps & swap/page file on a SCSI drive. This takes max advantage of SCSI's primary strengths.
I read a post by Tony Wilson of Australia that characterized SCSI drives this way: "SCSI drives .. are genuine champions in all fields. They are quiet and unassuming. Under little pressure, they perform like any other good player .. but under severe pressure, they just keep on performing where lesser players give up."
That's a great way of saying it. I notice my SCSI drive most when I have to use an IDE-based system .. just as I notice my Cable modem most when I have to use someone's dial-up connection. And I notice my Ferrari most .. in my dreams. =)
I've read that a performance increase of 10% is a barely a worthwhile upgrade .. 15% is worthwhile .. 20% is definitely worthwhile .. 25% is a no-brainer .. and anything above 30% is 'shame-on-you-for-not-upgrading-sooner'. Maybe now you have a better idea of what kind of performance your SCSI dollars buy you.
I got into SCSI from video-editing. Started with the DV300, by Pinnacle/Miro. Firewire card with onboard Adaptec 2940 UW controller. Very cool concept - for the time. Video comes into the PC from DV camcorder (we had Sony TRV9) -> to capture card (DV300) -> to SCSI bus -> to the awaiting SCSI drive .. dedicated solely for video/AVI files. Video files never even see the PCI bus (where there's much more traffic). Both the Firewire & SCSI busses were dedicated solely for video.
This, naturally, made the capture/output as reliable as you could get at the time - at least, without spending 5X as much. Kind of like having your own freeway to drive on. Harder to get in an accident if you're the only car on the road. Then we upgraded the boot drive to 10Krpm LVD SCSI (with a Tekram DC390-U2W adapter), and that took video-editing to a whole new level. Made a big difference.
If you get into video-editing, you'll find yourself learning about hard drive performance & operational factors. Almost impossible not too. Posted my experiences here -> Lessons from building a workstation designed to edit digital video. It can save you much pain if you want to get into NLE (non-linear editing).
Wouldn't have taken the time to write this if SCSI wasn't so cool - especially booting your system from an LVD beast. Wish I could be there for that first, snarling boot, when you say, "Rad was right." =)
Shout out to DocSilly. The Doc walked me thru my first SCSI boot. Put up with all my stupid questions. Nice to have someone on ICQ that you can dialogue with real-time. The Doc knows more about SCSI than anyone I know. I'm sure the guy who runs the mother-of-all SCSI FAQs (Gary Field) knows more, but I don't know him. I will add tho, that Gary has never failed to get back to me when I had questions that no one else could answer.
Remember that no one but you can say whether or not SCSI is worth it for you. Only you can make that call. I've heard staunch IDE/ATA people say, "There goes another one to the dark side," when some goes SCSI. I see it differently - more like what the blind man in John 9:25 said: This one thing I know: whereas I once was blind, now I see. =)
Next -> [SCSI Guide - Linkage & User Comments]
Previous -> [SCSI Guide - Configuration & Comparison with IDE]