informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/computers/disks2

297 lines
16 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ͻ
<20> <20>
<20> A Hard Disk Drive <20>
<20> for <20>
<20> Steve's Dream Machine <20>
<20> <20>
<20> by <20>
<20> Steve Gibson <20>
<20> GIBSON RESEARCH CORPORATION <20>
<20> <20>
<20> Portions of this text originally appeared in Steve's <20>
<20> InfoWorld Magazine TechTalk Column. <20>
<20> <20>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>ͼ
I love hard disk storage, it's elegant, amazing, tricky,
logical, and completely understandable. So let's begin by
discussing one of my favorite aspects of modern personal
computer architecture, and some critical components of Steve's
Dream Machine... the Hard Disk Storage Sub-System.
We all want several things from our hard disk systems: High
Speed, High Capacity, Low Cost, and High Reliability. I've found
a unique combination of hard disk and controller, for any
machine with a 16-bit I/O bus, which delivers all four in
spades.
The performance of a hard disk system is determined by two
simple and separate things: The average time required to begin a
data transfer and the speed of that transfer once it begins.
In my opinion the world is completely seek-performance crazy.
When someone asks "How FAST is that drive?" they're speaking
only of the average seek performance. Sure it's a factor, but
it's FAR from being the most important issue. What matters much
more is the CONTROLLER's data encoding format, minimum
achievable sector interleave, head switching behavior, and
believe it or not, the number of heads on the drive!
DOS numbers a disk's sectors sequentially from the outside
inward. When it wants to read or write a sector, it first
determines where the sector is located on the drive then sends
the heads to that location. This means that the issue is not
how long it takes a drive to move its heads to cylinder 100, but
rather how long it takes to move them to SECTOR NUMBER X. For
different drives these can be very different questions.
For example, let's take the ubiquitous Seagate ST225 20 megabyte
hard disk drive as our baseline. It can't handle RLL encoding,
so it's limited to 17 sectors per track. It also has four heads
for four tracks per cylinder. Therefore this drives has a
CYLINDER DENSITY of 17 times 4, or 68 sectors per cylinder.
Now let's compare this with the Steve's Dream Machine drive, the
MiniScribe 3650. This lovely half-height drive handles RLL
encoding without a hiccup for 26 sectors per track, and its 6
heads combine to deliver a cylinder density of 156 sectors per
cylinder.
In other words, the 3650 packs 2.29 times more sectors into each
cylinder than the ST225. DOS's sector numbering scheme means
that the 3650 needs to move its heads 2.29 times less far, or
about 44% the distance of the ST225!
So while the Miniscribe drive might appear to be slow, with its
head positioner rated at 61 milliseconds average access time, if
we compare apples to apples, using the ST225's 65 millisecond
speed as a reference, the 3650 is equivalent to a ST225 drive
with a 26 millisecond actuator!
In order to correctly compare hard drive access times, I
designed an index which takes all of these factors into account
and which can be used to correctly rate any drive. I call it the
Real Sector Access Factor, or RSA Factor.
To determine it for any drive simply multiply the sectors per
track (17 for MFM encoding, 26 for RLL) by the drive's head
count, then divide by the drive's average seek time. This yields
an index which is completely compensated to account for cylinder
density and allows drives to be correctly compared.
The RSA Factor for the ST225 is 1.04, versus 2.55 for the
Miniscribe 3650. The Seagate ST238 with its RLL encoding comes
in with a 1.60 and the ST251 with its 40 millisecond average
access ranks an RSA Factor of only 1.70. As these numbers
demonstrate, it's important to compare apples to apples when
evaluating drive specifications. The "sluggish" 3650 even beats
out the "swifter" ST251 when compared correctly.
In the case of average sector access times, the actual distance
the heads must move is really determined by the number of
sectors the drive and controller are able to stuff onto each
cylinder, not by shaving milliseconds from average access times.
The Miniscribe 3650 is not quite officially RLL certified,
though I hear rumors that it's about to be, simply because it
works so well. I've tested many of them myself, and the bright
boys at Northgate Computer Systems (who turned me on to this
drive in
the first place) are shipping thousands with RLL controllers in
their 286 AT compatibles. They've had no problems. I'm quite
comfortable with the 3650 and RLL encoding.
Finally, the 3650 is rated as having 809 cylinders, though it
actually has 852. I've been low-level formatting mine out to 842
cylinders. Then, under DOS 3.3 with RLL encoding, you get two
MAXIMUM SIZE 33.4 megabyte DOS partitions! They couldn't be any
bigger! Sixty-seven fast megabytes in an inexpensive half-height
drive is hard to beat!
Okay, so we've defined the real performance of a hard disk sub-
system to be: The average time required to begin a data
transfer, and the time required to preform the transfer once it
has started. We then examined the first of these terms and saw
that the data encoding technology (MFM or RLL) and the drive's
head count both dramatically affect the system's actual head
seek performance since they determine the average distance the
head must move to get to the proper DOS sector. Now we'll examine
the second determiner of hard disk system performance, the actual
data throughput.
Many tricky and interacting issues determine a hard disk
system's delivered data throughput, but none of them are very
tough to understand.
The raw data that rotates underneath our hard disk's heads
moves at quite a clip. Data bits that are encoded with Modified
Frequency Modulation (MFM) technology flow to and from the
drive's head at 5 million bits per second, and Run Length
Limited (RLL) encoding moves its data at 7.5 million bits per
second. After subtracting the inter-sector gap intervals and
sector addressing overhead, this translates to 522,240 bytes of
real data per second for MFM and 798,720 bytes per second for
RLL.
Unfortunately the hard disk controllers and motherboards used in
PC, XT, and most current generation AT computers are completely
unable to keep up with data flowing at this rate. So the
practice known as SECTOR INTERLEAVING was invented to slow
things down to a rate which our computers can handle. Sector
interleaving spaces successively numbered sectors out around the
disk so that our slower hard disk controllers and computers can
digest the prior sector before the next one begins. Failing to
space the sectors far enough apart incurs the substantial delay
of waiting for the disk to spin all the way around again.
The original IBM XT's hard disk was interleaved at 6-to-1 (6:1)
which meant that 1/6th of the track's sectors were read during
each revolution of the disk and that six revolutions were
required to read a single 17-sector track. This also meant that
the original XT's effective data transfer rate was 522,240
divided by 6, or 87,040 bytes per second. Not very exciting.
Even today things are frequently not much better. I have upset
Western Digital in the past by reporting that most of the
machines I had tested were not fast enough for the default 3:1
sector interleave they were using on their MFM controller with
the result that only one sector was being transferred for each
revolution of the disk. This of course resulted in horrible
30,720 byte per second throughput. The fact is that most of
today's XT and AT machines are using MFM encoding with an
interleave of 3:1 or 4:1 and delivering unexciting throughputs
of 174,080 or 130,560 bytes per second respectively.
When I wrote a series of columns on hard disk performance, I
reported that RLL encoding was "not here yet" but that I was sure
it would be a good thing and that we were only premature, rather
than wrong, about its ultimate viability. Well, I'm delighted to
report that RLL encoding is FINALLY
REALLY HERE! The controllers have their acts together and
reliable and robust RLL drives are readily available. If
horrible experiences set you forever against RLL, I strongly
advise you to re-address the issue. As long as you
choose your drive and controller carefully, you won't have any
trouble.
Aside from cramming more data into a drive, RLL also increases
the real seek performance of any drive. Remember our discussion
of Real Sector Access (RSA) Factor. Raising the drive's cylinder
density by 150% drops its average seek times to just 66% of what
they would be with MFM encoding. And since the drive's data is
encoded at 150% density, the raw data rate from the drive is 150%
higher.
However, a higher data rate from the drive doesn't help us much
if we must immediately water it down with a large sector
interleave. Western Digital's latest 1002A-27X 8-bit RLL
controller defaults to an unexciting interleave of 4:1,
delivering 199,680 bytes per second throughput which beats an
MFM controller with 3:1... but not by much.
The great news is that we're just beginning to see some really
hot (and inexpensive) hard disk controllers which are fully able
to keep up with a 1-to-1 interleaved disk for the delivery of
screaming 798,720 byte per second data transfer rates! That's
just shy of 0.8 megabytes per second!
I've explained my choice of hard disk drive for Steve's Dream
Machine. The Miniscribe 3650 is very inexpensive (several booths
at a recent Southern California swap meet were selling them for
between $290 and $300), it's half height (so you can have a pair
of them!), utterly capable of handling RLL encoding, and places
six heads under the control of a 61 millisecond (average seek)
stepping motor positioner.
Twenty-six sectors per track and six tracks per cylinder give the
3650 a cylinder sector density which is 2.29 times higher than a
typical four head MFM drive, so it actually performs like a
drive with a 26 millisecond average seek time because the heads
only need to move 44% as far to get to the same sector.
Even though Miniscribe says the drive has only 809 cylinders it
actually has 852 physically and I've been formatting all of mine
out to 842. Northgate Computer accepted my suggestion and has
been doing the same to hundreds of theirs also without hitch, so
I'm quite comfortable suggesting this to everyone.
I run under DOS version 3.3 because it's able to split the drive
into two MAXIMUM SIZE 33.4 megabyte partitions WITHOUT the need
for any messy third-party partitioning software. This yields a
"C" and "D" partition of 33.4 megabytes respectively or 67
megabytes overall!
So what about a hard disk controller? Well in this day and age
there's no excuse for NOT going with RLL and a 1:1 sector
interleave. So let me make this point quite clear. First, even
though disks seem to be spinning quite fast, they're really
quite slow. 3600 RPM is only 60 revolutions per second, which is
16.67 milliseconds per revolution.
Now imagine that we wish to read or write a moderate size file
of 26K bytes. Since sectors are 512 bytes, 26K bytes requires 52
sectors. On an MFM format drive with 17 sectors per track this
fills 3 tracks. A typical interleave of 4:1 requires 12 disk
revolutions, for a total transfer time of 0.2 seconds. However
an RLL controller with 26 sectors per track and 1:1 interleaving
moves the same 52 sectors in just two revolutions or 0.033
seconds. Two revs versus twelve... or SIX TIMES FASTER!
I'm delighted to tell you that choosing a hard disk controller
was quite simple, because nothing even comes remotely close to
Adaptec's model 2372 masterpiece. In the first place, it REALLY
handles a SUSTAINED 1:1 interleave. Other 1:1 controllers may
grab an entire track in one revolution, but they're then unable
to continue with the next track immediately afterward.
Consequently the system's performance drops by half to that of a
2:1 interleaved drive. The Adaptec sustains 798K bytes per
second across multiple tracks.
Secondly, you don't need a 16 megahertz 386 system. Any AT
compatible can achieve screaming 800,000 bytes per second
transfers with this controller. It comes in two flavors, the
2372 handles two hard drives as well as two high or low density
floppy drives and the 2370 just handles two hard drives.
The built-in low-level formatting software has to be seen to be
believed. It's the cleanest and most comprehensive of any I've
ever seen. If you want to run with multiple partitions, or a
partition larger than 33 megabytes it will actually create the
required CONFIG.SYS driver by "downloading" it from its own ROM
onto the root directory of the hard disk! Unbelievable.
Finally, and most incredibly, it is so compatible with the
standard AT hard disk MFM-style chip sets that it DOESN'T
REQUIRE ANY ROM BIOS WHATSOEVER up there in the high memory
"twilight zone!" After booting and initializing itself, the ROM
is never again used. This means that the "twilight zone" region
is not reduced in size and fragmented. Then utilizing Steve's
Dream Machine's memory manager, 386-to-the-Max, 225K of
completely free contiguous "twilight zone" memory is available
for loading TSRs and other resident software!
Finally, by using a non-RLL capable Seagate ST225 drive and some
ruthless worst-case data pattern testing software I've
developed, I was able to quantitatively compare the robustness
of the RLL data separators used in all of the contending
controllers. The Adaptec 2372 is absolutely up at the top of the
heap of RLL reliability because it makes the Seagate ST225,
which is totally worthless for RLL in any case, look BETTER than
any of the other RLL controllers do. So I'm more confident of
the Adaptec with a real RLL drive than I would be with any of the
others.
- The End -
Copyright (c) 1989 by Steven M. Gibson
Laguna Hills, CA 92653
**ALL RIGHTS RESERVED **