From: mrm@optigfx.optigfx.com (Mike Murphy)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD and IDE drives
Date: 28 Sep 92 21:39:49 GMT
Organization: Optigraphics Corporation, San Diego

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.