Copy Link
Add to Bookmark
Report

A Hard Disk Drive for Steve's Dream Machine

Steve_Gibson's profile picture
Published in 
Steve Gibson articles
 · 11 Aug 2019

 
…ÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕª
∫ ∫
∫ A Hard Disk Drive ∫
∫ for ∫
∫ Steve's Dream Machine ∫
∫ ∫
∫ by ∫
∫ Steve Gibson ∫
∫ GIBSON RESEARCH CORPORATION ∫
∫ ∫
∫ Portions of this text originally appeared in Steve's ∫
∫ InfoWorld Magazine TechTalk Column. ∫
∫ ∫
»ÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕÕº

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 **

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT