SCSI... IDE... SCSI... IDE?

[Walliser]

Hi guys,

just wanted to get some opinions on this: does SCSI still have "major advantages" over IDE? I am considering getting a smaller size SCSI harddrive for my OS and some apps and a large to very large IDE disk for the data storage. I am also thinking about getting a SCSI CDR/RW and DVD drive.

All comments are welcome. Oh, and yes, I am aware of the price difference. But nothing really beats a good SCSI harddrive.

 

[Crimson]

I JUST converted my system back to IDE after about 3+ years of being 100% scsi.. The difference is pretty small now, especially for non-server type usage. A newer 7200rpm EIDE drive will be faster than an old small scsi drive.. don't bother with that route.. Unless you get a 15,000rpm SCSI drive, the difference just ain't worth it.. Don't get me wrong, SCSI _IS_ better, its just not worth it right now..

 

[Beatnik]

For audio and video capture... my experience suggests that you will have
fewer dropouts with SCSI. If you are doing pro-level audio work, or video
that you want to be top quality, if you have a choice, I would go SCSI.
I wish this weren't the case, but it sure seems like it is from my experience.

 

[ChrisIsBored]

If you're doing a lot of file transfers you'll definately be happier going with SCSI. I have SCSI at home, but my 2 boxes here at work are IDE. Man it really pisses me off when my system slows to the point where I can't open up any programs while i'm moving files or writing to my A: drive.

If you have the money go for SCSI. If you have the balls, go all SCSI.

 

[Walliser]

Chris: that is exactly my experience. I am either converting files, joining files or doing something else that's hard on the disk transfer and my system pretty much locks up till it's done. And no, it is not an old system. It's a fairly new P4 1.6.

If I don't go SCSI I will most certainly have to look into improving the IDE transfer, I can't even burn a CD at 24x without the HD not being able to deliver the data. They must have put some cheap a$$ IDE controller in this new system.

 

[Rhombuss]

Hmm...I've also been wondering about this for some time now. Both my existing systems are using U2W SCSI, but when I build a new one in the summer, I'm not sure whether or not to migrate back to IDE.

Is the IDE Bus still that primitive compared to the SCSI Bus? That's the main reason I converted to SCSI 3 years ago, because the UDMA33 tech was way too slow compared to the 80mb/sec burst SCSI was able to obtain. I thought the gap would have closed considerably since then, seeing as how ATA100 and ATA133 have implemented themselves. Or do you need a RAID0 config to fully match a SCSI bus?

 

[Walliser]

they are still lagging behind. it's not the saturation of the bus, no drive will ever saturate a IDE channel, but the way I see it, it is the strain it puts on the CPU. maybe I expect too much from SCSI in that regard, correct me if I am wrong. but the way I remember is: with SCSI the command for transfer is sent and the controller/device then takes over. whereas with IDE there's a lot of overhead that still relies on the CPU and the (fill in appropriate) bridge.

as I said, maybe I have the wrong idea about SCSI. I am aware that IDE has come a long way but I believe that SCSI still does have some advantages.

 

[Rhombuss]

Ah, forgot about the CPU usage - that is a big issue.

I know integrated components generally consume more CPU cycles than standalones, so would it be an option to get a separate IDE controller card (possibly RAID), or are the new integrated IDE controllers just as adequate?

Also, I remember one of the biggest advantages SCSI had over IDE (in the past at least) was the seek time. Comparing 5400 RPM to 10000 RPM is a big difference, but now that IDE drives have significantly increased the platter densities and capacities, doesn't that lower the seek time without need for increasing rotational speed?

 

[Zoogy]

I'm selling my whole scsi setup
email me if interested

 

[Walliser]

thanks, appreciate that. will get in touch once I get off work.