Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!uunet!in2.uu.net!136.142.185.26!newsfeed.pitt.edu!neurocog.lrdc.pitt.edu!hahn From: hahn@neurocog.lrdc.pitt.edu (Mark Hahn) Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc Subject: Re: IDE vs SCSI (was Re: Linux vs BSD) Followup-To: comp.os.linux.misc,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc Date: 23 Jan 1997 18:19:21 GMT Organization: Learning Research and Development Center at U. of Pittsburgh Lines: 52 Message-ID: <5c8a39$7tn@usenet.srv.cis.pitt.edu> References: <32DFFEAB.7704@usa.net> <5c155c$p6u@raven.eva.net> <87k9p4rckd.fsf_-_@murkwood.gaffaneys.com> NNTP-Posting-Host: neurocog.lrdc.pitt.edu Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:152430 comp.os.linux.networking:65032 comp.os.linux.setup:92239 comp.unix.bsd.bsdi.misc:5602 comp.unix.bsd.misc:1915 : Peter Mutsaers <plm@xs4all.nl> writes: : > Todays IDE drives are not much slower than SCSI drives this is true. I routinely sustain >6 MB/s on EIDE with mundane motherboards and drives. that's with busmastering, of course, so there's no significant CPU overhead. : 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 nope. the seek is seperated from the read; the drive/interface generates an interrupt when the data is ready to read. if you're interested in this stuff, you should definitely read ide-disk.c; it's very nice on the inside. : 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). it may well be true that only one seek can happen at once; I don't know. : 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. well, IDE caches are tiny, for some reason, never more than ~128K. anyone know why? incidentally, hdparm does let you enable write caching on IDE disks. : 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. this is pretty iffy. while its certainly true that the OS has little hope of optimally scheduling head motion (because of zoned recording), blocks _are_ sorted, and so the gross motions are already in a good order. where tagged queueing would give SCSI an advantage is those places where naive elevator sorting (by block number) doesn't work: lower-numbered blocks within the current cylinder and bad-block remapping. : It is possible with some high-end SCSI controllers to offload the : entire file-system code from the operating system into the controller, I've never heard of this. in fact, the SCSI protocol doesn't really encompass a concept of files... regards, mark hahn. -- operator may differ from spokesperson. hahn@neurocog.lrdc.pitt.edu http://neurocog.lrdc.pitt.edu/~hahn/