Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: 386BSD and IDE drives
Message-ID: <1992Sep30.030143.3446@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Reply-To: terry@icarus.weber.edu
Organization: Weber State University (Ogden, UT)
References: <Bv32LD.K9t@chinet.chi.il.us> <1992Sep25.184045.20768@fcom.cc.utah.edu> <1729@optigfx.optigfx.com>
Date: Wed, 30 Sep 92 03:01:43 GMT
Lines: 188
In article <1729@optigfx.optigfx.com> mrm@optigfx.optigfx.com (Mike Murphy) writes:
>In article <1992Sep25.184045.20768@fcom.cc.utah.edu> terry@icarus.weber.edu writes:
>>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.
The problem isn't that it isn't faster than it should be (in the case that
it doesn't really do a seek), but that the kernel will go off and do other
things because it *expects* a seek latency. Then, when a real seek latency
is imposed when the translated geometry (which the kernel expects to have
nearly immediate response) maps to a cylinder boundry on the physical disk,
the kernel halts for at least one seek latency and maybe (for stupid drives
and controllers) a rotational latency as well... ick.
>>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.
Well, I certainly can't give you the benchmark software I used, since
it's Novell's and not for public consuption. Suffice it to say that the
people who wrote it do know a little bit about PC hardware. The Compaq
results are definitely experimental rather than allegorical.
>>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 :-)
Actually, it's germane to anyone using SLIP over an MNP 5 modem ;-). SLIP
hates inband flow control as much as I do. But the real point was as yet
another example of what followed, which was:
>>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.
Yes; "I" as UNIX do. Most PC hardware manufacturers (with respect to hard
drives, this tends to mean IDE and MFM) concentrate on the DOS market; if
you use 16 DMA buffers to do your I/O, you certainly aren't using the drive
like DOS would. If the manufacturers truly wanted to get the best performance
numbers on a controller/hard drive combination, they'd make you run something
other than the BIOS drivers and DOS.
Everything the drive manufacturer does to "increase speed" is really to
increase benchmarks. He could probably give a damn about speed as long as
he sells drives. The benchmarks are either controller independant (making
them as meaningful as "unformatted capacity") or they are "best DOS numbers"
for the drive or drive and controller. Either way, they aren't particularly
applicable to UNIX, and don't necessarily improve UNIX benchmarks at all,
given UNIX's different method-of-access.
What I measured on the Compaq was transfer rate over the bus. Admittedly, I
am probably measuring something more applicable to UNIX than DOS when I do
this, since Novell drivers are just as promiscous in their use of controller
specific (non-BIOS) code as UNIX.
>>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.
Well, Computer Shopper tends to have some companies that put out at the same
prices for each type (although a little bit less)... are you sure you aren't
quoting for drive+controller? Admittedly, I like a bit higher capacity as a
minimum, and IDE drives start ramping up at the higher Megs, while SCSI tends
to keep a uniform increase in price until about 1.6Gig. I can get a 1.3Gig
11ms SCSI for about $1700 without controller. That's four times the capacity
of where you stopped counting at less than twice the price.
>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.
Most SCSI controllers *do* a bit more than most IDE controllers, so you aren't
really comparing apples and apples. One argument put for pro IDE geometry
translation is that the losses are won back from controller caching. A $10
controller ca'nt be used for this argument. I might as well argue the ST-01
on pricing and the AHA1742 on speed.
>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.
If you find someone with *that* choice, mail me too!
I never said they didn't work fine for 386BSD (either without other partitions
on them or after a great deal of non-novice hacking around). Just that there
are intrinsic difficulties in the use of any translated drive, and that most
IDE drives are translated in such a way as to cause problems while most other
drive types are not.
>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 will probably continue to argue speed from the viewpoints of equivalent
localbus/ISAbus/EISAbus controllers (the Compaq tested was localbus). And
also from the perspective of main-memory cache being faster than non-local
bus cache. Of course, you can always make the point that I'm arguing about
a Ford Fiesta (small SCSI), a Yugo (All IDE), and a Ford Mustang (big SCSI)
and that Yugo's and Mustang's aren't in the same class. I'd agree... and
then I'd tell you I want a Mustang. 8-).
>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
People! Please send this information to Mike for summary!
Drives----------------
SCSI: 5.25 9045
Model 97544SA
330 Meg
ESDI: 5.25 1558 (Micropolis)
382 Meg
IDE: Compaq relabled drive
320 Meg
Controllers------------
SCSI: WD7000-FASST (ASC) [ Can't release driver yet ]
ESDI: WD1007A-WA2 E037
IDE: Compaq Localbus (486/33) [ Can't release boot blocks yet ]
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
terry_lambert@ns.novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------