Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!newsfeed.internetmci.com!news.pe.net!news.corpcomm.net!news From: Zach Heilig <zach@blizzard.gaffaneys.com> Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc Subject: IDE vs SCSI (was Re: Linux vs BSD) Date: 23 Jan 1997 03:00:18 -0600 Organization: Corporate Communications Lines: 55 Sender: zach@murkwood.gaffaneys.com Message-ID: <87k9p4rckd.fsf_-_@murkwood.gaffaneys.com> References: <32DFFEAB.7704@usa.net> <5c155c$p6u@raven.eva.net> <5c19pg$rf6@lynx.dac.neu.edu> <5c341j$3dp@cynic.portal.ca> <5c3k6o$qro@lynx.dac.neu.edu> <873evtxn6t.fsf@localhost.xs4all.nl> NNTP-Posting-Host: dialup2.gaffaneys.com Mime-Version: 1.0 (generated by tm-edit 7.89) Content-Type: text/plain; charset=US-ASCII X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:153725 comp.os.linux.networking:65842 comp.os.linux.setup:93485 comp.unix.bsd.bsdi.misc:5687 comp.unix.bsd.misc:1977 Probably little disagreement here, except among the clueless :-) This is my explanation why IDE will always be slower than SCSI (and why SCSI is usually more expensive). Peter Mutsaers <plm@xs4all.nl> writes: > Todays IDE drives are not much slower than SCSI drives [snipped] There probably aren't any performance differences between IDE and SCSI hardware. The differences come in when you compare the interfaces themselves. Your average IDE interface has little or no logic on the interface card, so it is up to the host CPU to send commands to each drive, and then proceed to wait for the results (perhaps wandering off and doing something else while waiting). Once one IDE drive on the IDE bus has received a command, it does not give up the bus until the last byte of data resulting from that command has been transfered. This obviously forces each IDE interface to only allow one drive to be accessed at one time. Fortunately, there is a limit of two drives per IDE interface (limiting the effects of the damage to performance). I would assume that caching IDE drives are a little smarter, and take a bit of load off the host CPU. I've been wrong before though. Your average SCSI interface also forces the host CPU to wait for the data (duh! :-), but most interfaces will buffer commands so the host CPU doesn't have to wait for the SCSI bus to be quiet. Each drive disconnects from the SCSI bus after it receives a command, allowing the bus to be used by the other occupants (up to 6 other narrow devices or 14 other wide devices). After the drive has found and loaded the data into its internal buffer, it waits for the SCSI bus to be free, and transfers the data to the host CPU (all SCSI cards I've run into do this via DMA). This increases latency a bit (usually negligible), but it allows several drives to be active at once, reducing average disk access times. With the new tag-command-queuing (or whatever its officially called), each drive can queue up to 32 commands. The most obvious advantage this gives is optimizing head accesses, optimally servicing all 32 commands with one sweep across the platters. It is possible with some high-end SCSI controllers to offload the entire file-system code from the operating system into the controller, and merely have the operating system ask the controller to DMA requested files into host ram. This would be possible with IDE as well, but then you have lost much if not all the cost advantage of IDE over SCSI. -- Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email Support bacteria -- it's the only | is unwelcome. I avoid dealing form of culture some people have! | with companies that email ads.