Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!news!nosc!crash!optigfx!mrm From: mrm@optigfx.optigfx.com (Mike Murphy) Newsgroups: comp.unix.bsd Subject: Re: 386BSD and IDE drives Message-ID: <1729@optigfx.optigfx.com> Date: 28 Sep 92 21:39:49 GMT References: <1992Sep24.022400.19483@fcom.cc.utah.edu> <Bv32LD.K9t@chinet.chi.il.us> <1992Sep25.184045.20768@fcom.cc.utah.edu> Organization: Optigraphics Corporation, San Diego Lines: 144 In article <1992Sep25.184045.20768@fcom.cc.utah.edu> terry@icarus.weber.edu writes: >In article <Bv32LD.K9t@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: >>In article <1992Sep24.022400.19483@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >>>Now I wouldn't buy an IDE drive at all, since I expect to eventually install >>>386BSD on all machines in unlocked offices. 8-). 8-). >> >> Something is very wrong here. My experience is that IDE drives >> are great for UNIX and IDEAL for 386bsd. >>[...] > >I have to disagree on the relative speed of the same hardware with a SCSI >board or an IDE board on the bottom of it. The SCSI will be facter, unless >you aren't running equivalent controllers. It depends upon the drive and the controller. If you actually go to the trouble of figuring it out, it is possible for an IDE drive on an ISA bus machine to transfer data faster than a SCSI drive. That's an ISA bus limit rather than the SCSI limit. This is not, however, what determines the transfer rate in *real world devices*. If the drive cacheing mechanism is fast in comparision to the mechanical components, then the limit is the number of sectors passing under the head per second. If the drive is MFM, and there are 17 sectors/track, and the drive runs at 3600 RPM, and the sectors are 512 bytes in length, the drive can't transfer data in bulk at more than 522240 bytes/second. That's for a controller that can manage the data. If an IDE drive has 42 sectors/track untranslated and runs at 3600 RPM, it can't transfer data in bulk at more than 1228800 bytes/second. If a SCSI drive has 36 sectors/track and runs at 3600 RPM, it can't transfer data in bulk at more than 1105920 bytes/second. If the SCSI drive has 64 sectors/track runs at 5000+ RPM, then it could transfer data in bulk at about 2.7MB/sec. Such drives cost more than IDE drives. >[...] > >Then I am guaranteed that the "unexpected" see will pkace me where I would >have needed to be anyway -- ready to read the requested sector. Most >"modern" SCSI drives do this. It is not uncommon for an IDE drive to do this as well. It tends to be a small factor in the overall performance of the drive. Small, not negligible. I'd be more likely to consider price and size rather than this feature in buying a drive. > >The speed loss comes in from the calculated or "expected" seeks, which will >cause you to miss the rotational latency by one revoloution, since the read >operation is scheduled inappropriately. > > >IDE geometry translation screws with a lot more. In particular, if the >number of "virtual" heads is not evenly divisable by the number of real >heads, and the head controls do not operate independantly (most do not, >to reduce cost, since IDE is the "Yugo" of hard drives), then you have to >move the head *vastly* more than expected. This is the most time costly >operation on the disk drive. If it is evenly divisible, then it's only >*greatly* more than expected. Go over your figuring again :-) In the limit, if the IDE drive only has one track and one head, and 83405 sectors and simulates 977x5x17, then it doesn't have to move the head at all to do a simulated seek. A common failing of programmers is neglecting consideration of limiting cases. In a real world case, an IDE drive with 1040x2x42 (87360 sectors, 84 sectors/cyl), may emulate 977x5x17 (83045 sectors, 85 sectors/cyl). 85/84 more seeks is neither *vastly* more nor *greatly* more. It is more. In terms of bulk throughput, 42 sectors/rotate will transfer more data than the real 17 sectors/rotate. That means that the IDE will be faster than an MFM, even if the MFM has a 1:1 interleave controller. The IDE will also be faster than MFM. This holds, as Terry says, if the controllers and drives aren't stupid. > >Using a Compaq 486/33M with the factory IDE drive, turning off translation >(an operation not for the faint of heart) gave a 16% speed improvement over >the translated geometry. This is significant. Not all IDE drives will This is not necessarily significant. It just tells how that particular drive and controller combination behaves. The combination may be stupid. Who's to know? >let you do this. And this was for DOS (since that's where I happen to >have benchmarks for disk speed). True, I couldn't use the whole drive >under DOS... who cares? The whole drive geometry translation problem has >been foisted on us by DOS anyway... let it suffer. ;-). > >>[...] >> Fast as any of my RLL, ESDI, or SCSI drives under DOS, UNIX, OS/2. Note that Randy is speaking of an experimental result. Experimental, not opinion. >> >> IDE is not the best solution for all hi-performance situations, >> but for the price, and the ease of 386bsd installation, they >> can't be beat. Now that was opinion. It happens to be the same as mine, but it is opinion. >[...] >Drive geometry translation has always felt like in band flow control to >me. Why does a modem say it's 9600 baud if it can't send and recieve 960 >characters a second? If it only does 240 characters a second, but talks to >the computer at 9600 baud, and uses flow control to make sure it's transmit >buffer is not overrun, then I'll be damned if it's anything other than a >2400 baud modem, and saying otherwise is just plain dishonest. Actually it's not dishonest, it's quite useful at times, and the discussion of why is not to the point WRT IDE drives. It may not be suitable for this newsgroup. It certainly is a subject for e-mail :-) > >In the same way, I don't like disk drives lying to me. They either have 64 >heads like they say, or they have 5-9 of them, as in reality. I will damn >well decide what my requests do relative to the real geometry of the disk. Because you know better than the drive makers how to best take advantage of the internal nuances of their drives? Heaven knows that the drive manufacturers don't want the best performance for their drives that they can get. >[...] > >As to your pricing claims, all I have to say is you're buying SCSI drives from >the wrong people. > A SCSI drive may cost just about the same as an IDE drive of the same capacity in the 100-500MB range, though not here in San Diego. Representative prices in San Diego, IDE-213MB:$415US, SCSI-213MB:$575US, IDE-340MB:$720US, SCSI-340MB:$925US. A SCSI drive and controller in the 100-500MB range costs more than an IDE drive and controller in the same range. If that's not the case, and the controller isn't an ST-01 (;-)), then let us know the right people to buy from. You know, if I had the option of a 1.6GB SCSI drive and controller for the same price as a 44MB IDE drive and controller, I'd probably use the 1.6GB SCSI. For folks like me without that choice, IDE drives seem to work fine with 386bsd. They tend to be faster than MFM, faster than RLL, usually about the same speed as lower price SCSI, and slower than high end SCSI. Not surprising. I had a request in e-mail to note which drives and controllers worked with 386bsd. This is what has worked for me, all with several no-name IDE interfaces: Maxtor 80MB, 130MB, 213MB, 535MB, Connor 44MB, 104MB, Seagate 80MB, WD 80MB -- Mike Murphy mrm@Optigfx.COM ucsd!optigfx!mrm +1 619 625 3000 x 265 Optigraphics Corporation 9339 Carroll Park Drive San Diego, CA 92121 The opinion(s) expressed above are mine and not those of my employer.