Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!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: <1992Sep25.184045.20768@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Reply-To: terry@icarus.weber.edu
Organization: Weber State University (Ogden, UT)
References: <19r0h6INNp42@aludra.usc.edu> <1992Sep24.022400.19483@fcom.cc.utah.edu> <Bv32LD.K9t@chinet.chi.il.us>
Date: Fri, 25 Sep 92 18:40:45 GMT
Lines: 136
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. Main reason is that, like
> SCSI, they hide bad sectors from the OS. Never a need to run bad144
> or worry about bad sectors. Second, for a 1 or 2 drive system, IDE
> is a non-negligable amount less cost than SCSI. I can get 425 meg
> IDE drives for $825. Controllers are just about free, and include
> a pair of serial ports and a parallel port.
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.
As has been pointed out, most SCSI does geometry translation. I will say
to this "Yes, but not the bad kind". The geometry translation on SCSI
drives is based on drives with a non-uniform radial bit density -- that
is, either a variable spindle speed or a variable write frequency. The
important thing to note here is that the *number of heads is not changed
in translation*. This is because the SCSI translation is on the order
of number of sectors per cylinder. Drives which do this can expect about
a 3% loss in performance if they arrange their sectors "right" so as
to minimize the impace of track-to-track seek time over an effectively
(due to translation) "contiguous track". In addition, If N1 is the number
of physical sectors per track on the track closest to the hub, N2 is the
number of actual sectors per track, and N3 is the number of sectors per
track farthest from the hub, as long as the "virtual" number of sectors per
track is <= N2, there is no performance loss. We can think of it as
amortizing a smaller than expected number of head movements than expected
to get to where we need to be.
What is the 3% loss, then? It's the loss due to rotational latency being
incorrectly calculated. If I have a disk with an increasing number of sector
per track:
---
----
-----
------
-------
But I arrange my virtualization such that a crossing from "sector 3" on one
track to another incurs little or no rotational penalty as a result of the
"unexpected" seek to "sector 3" on an adjacent track, like so:
---
----
-----
------
-------
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.
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.
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
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. ;-).
> My main UNIX system, chinet, has a pair of 425 meg IDE's and a 600
> meg SCSI on an adaptek 1542b. The IDE's are as fast, if not faster
> than the SCSI. I have 5 different 386bsd systems sitting around
> for playing with, including a laptop, and they all use IDEs ranging
> from 40 meg to a pair of 425s. Never a problem with bad sectors.
> Fast as any of my RLL, ESDI, or SCSI drives under DOS, UNIX, OS/2.
>
> 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.
Try a DOS partition and a 386BSD partition on the same IDE drive. You *must*
either find a matching cylinder boundry between the two geometries, or you
*must* do the CMOS hack. This is not impossible, but it's inconvenient as
all get out.
You can also make it run most of the time without the hack if you are
willing to give up DOS entirely. But not always. It's wonderfully
inconsistant. And the translation tends to be "optimised" to have the
"least impact" on the performance of the drive as a DOS drive.
Compared to this, SCSI drives open the case and install themselves.
My problem is that a change is required from the default configuration, and
if this isn't done, you eat your performance or can't even run at all, and
it's anyones guess as to which it will be on any new drive.
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.
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.
Some of this isn't a problem in DOS, which is not known for it's disk
optimization anyway. For high performance file systems, they are changing
the assumptions, and in the case of IDE, they are changing them so much that
they are no longer valid. I hate that.
As to your pricing claims, all I have to say is you're buying SCSI drives from
the wrong people.
Terry Lambert
terry_lambert@npd.novell.com
terry@icarus.weber.edu
---
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
-------------------------------------------------------------------------------