View Full Version : Theoretical hard disk data transfer rate and multiple heads

May 11th, 2016, 07:33 AM
I have been researching hard disks in the ST-506/ESDI/Early SCSI era with an emphasis on speed, and various improvements in technology. One thing I find odd is that it appears no hard disk works on the basis of writing to the platters in parallel. The only reason I have been able to find for not doing this is that a "head switch" operation can be slow. But no reasoning was given. It seems a bit unlikely to me. Is there a technical reason why this isn't done, aside from screwing up the C/H/S mapping to some degree/slow external interface.

Surely the C/H/S mapping could be circumvented with some form of translation on the drive itself, particularly applicable with something like SCSI.

What I want to know, or want a pointer to, is if this has never been done is why? and if this scheme has been used, when was it first implemented?

3600rpm /60 * 17s/t * 512 = 522240 Bytes/s 4177920 bits/s (~4.2MHz)

but with multiple heads (say 4) surely the data rate could be quadrupled?
Have I missed something?

May 11th, 2016, 08:14 AM
The bit-skew issues are formidable, but yes, it (or something like it) has been done. The problem is that you'll need R/W amplifiers for each head and some rather involved deskewing logic.

But, as an example, consider the CDC 808 drive--four spindles accessed by two positioners with multiple heads--each head accesses 6 tracks (I posted a photomicrograph of a head the I have some time ago). Capable of transferring 12 bits at a time.


Not practical for the (relatively) cheap microcomputer. After that, RAID took over.

May 11th, 2016, 10:20 AM
The bit-skew issues are formidable, but yes, it (or something like it) has been done. The problem is that you'll need R/W amplifiers for each head and some rather involved deskewing logic.

This is what i like about this forum, people with knowledge. Any other forum it would be "why don't you use a SSD?"

We are getting into an area of hard drive design beyond my knowledge, so forgive me if I sound naive. I would guess that a head amplifier costs less than an actual head or platter, so for the multiple amplifiers, i am assuming the drive wouldn't cost an order of magnitude more to produce. Although I may be way off on this.

As for the bit-skew issues, I dont really know much about this. As I had envisioned it:

Standard Drive: _____________Head 1
+---------------------+ Switch / ____________Head 2
Data Line --------| Controller on drive |----------------o ____________Head 3
+---------------------+ _____________Head 4

My Idea:
+---------------------+_____________Head 1
Data Line --------| Controller on drive |_____________Head 2
| With buffer |_____________Head 3
| |_____________Head 4

The output of the buffer on the bottom of the drive, would wait until it received 4bits, then output 4 bits, 1 to each head simultaneously. OR in an actual implementation, more likely wait for 4 sectors then put one sector, on each platter.

As for comparison I believe there was a tape format that rather than using serpentine recording, just wrote 9 tracks simultaneously. As I said I know very little about this sort of thing. As I understand it, you mean bit-skew in the context of within one cylinder. Rather than sector skew between cylinders. What am i missing?

May 11th, 2016, 11:18 AM
As for bit skew, in a normal hard drive you really weren't absolutely guaranteed that each cylinder would line up exactly when it is read back. Imagine if your 4-head controller was reading bits back and got bit #1 from head 1, 2, and 3, but for various reasons (head flexing, temperature variation, etc) bit #2, or some part of it, was already under head number 4.

The ability to handle that would greatly increase the complexity of the electronics required on the controller.

But doing something like that also would have reduced system flexibility. Most hard drive vendors used the same base hardware to provide drives with 1, 2, 3, 4 or more platters. And no guarantee they even used an even number of heads. It was easier just to use the same controller for all models. Besides, most hardware of the vintage you are talking about was still struggling to keep up with the I/O of a single head as it was. "MFM" or "RLL" drives were regularly formatted with sector interleaves of 2 or more.

May 11th, 2016, 11:52 AM
Perhaps because much of the bottleneck in getting data onto and off of disks is from things other than the actual reading and writing of bits. Things like rotational latency, seek time and head settle time would still be a problem. Early rotating media often had "fixed heads" with one head per track. The drum memory in the Grumman A6 Intruder and the Disk File (catchy name that ;-) ) in the early #1AESS switching systems are two examples. However, when the #1AESS systems were upgraded to allow connections to the SS7 network, the Disk Files and Disk File Controllers were replaced by a 3B20D system that used 160MB and later 340MB "Moving Head Disks" or MHD's. The disks were paired into a form of mirroring and in each pair one disk was 180 degrees out of phase with its twin thereby cutting theoretical rotational latency in half.

May 11th, 2016, 12:18 PM
The CDC 7600 had a drum option with (IIRC) 128 heads per unit.

The CDC STAR had a couple interesting proposals, such as the "Scroll" device, a wide tape on two spools, contacted by a spinning head-per-track drum. And then there was the STAR drum--a 100,000 RPM drum in vacuo. Neither ever made it past the proof-of-concept stage as far as I know. The latter was intended as a paging store.

May 11th, 2016, 03:42 PM
I think that the problem is that reading data simultaneously from many magnetic heads would involve much more IC on the controller and raise the cost. AFAIK, the magnetic heads are incapable of reading 1s and 0s right away, but actually act just as instruments that measure the magnetic flux reversal when reading data is the case. Now that process for a single head has to do with measuring the magnetic pollarity transitions (flux reversal) on the magnetic medium and then amplifying the signals (analog) on the drive side. Theese signals are transfered to the controller outside the drive and a complex process of an encoding/decoding scheme takes place. That involves the coding method used, mostly RLL 1,3 (MFM) and RLL 2,7 for that era and some digital to analog and vice versa IC implementations that would take up the majority of the IC's on the controller and all that are related to a single head at a time. I think that for parallelism, a multiplication of all that IC logic by a factor equal to the number of heads on the drive would have to be implyed on the controller along with some synchronization circuits. That would raise the manufacturing cost dramatically and would render each controller applicable only on a specific-fixed number of heads drive (eg for a 4 head drive a 4x signal processor controller etc).

May 12th, 2016, 11:12 AM
I've wondered this too.

It's worth bearing in mind that hard disk prices have been a race to the bottom since at least the mid 90's. In markets this would have been useful for (i.e. attract a price premium, so enterprise) as said already the answer is that RAID arrays do this already and buy availability with it. So just buy 100 4.7GB disks instead of 50 9GB for example (in 1997) to provide the IOPS required. Either way, we need an operation queue to make use of it, again meaning server markets really at that time.

May 12th, 2016, 01:21 PM
Consider why two drives might be better than one...

Suppose, for the sake of argument, you have a disk that spins at 10,000 r/min, or 167 r/sec. or one revolution every 5 msec That means that the average access time for any byte on the disk will be 2.5 msec. Now consider two drives, spinning at the same speed, but asynchronously. If they're 180 degrees out of phase, the latency becomes 1.25 msec. Keep adding drives and the numbers get better and better.

May 12th, 2016, 01:35 PM
I dunno that follows, since the probability of accessing a sector nearer the head of any particular drive is no different to any other. Two heads in one drive at 180-degrees could achieve it though, assuming that the controller could keep track of the disk surface location.

IIRC there is a patent for a driver with that arrangement, I don't know if it ever made it to production though.

May 12th, 2016, 02:08 PM
Actually Conner made this with the Chinook series dual actuator drives according to Wikipedia


May 12th, 2016, 02:34 PM
I dunno that follows, since the probability of accessing a sector nearer the head of any particular drive is no different to any other. Two heads in one drive at 180-degrees could achieve it though, assuming that the controller could keep track of the disk surface location.

IIRC there is a patent for a driver with that arrangement, I don't know if it ever made it to production though.

The MHD's on the AT&T 3B20D did exactly that. The drives were installed in pairs: an even and an odd in each pair. All even numbered drives were daisy chained off of DFC 0 and odd drives were similarly connected to DFC 1. Removing either controller from service would also remove all of the drives connected to it. In the #1APS system that ran on our 3B20D's the system resided on MHD 0 & 1. The actual #1AESS files: the system generic (operating system) and associated data were on MHD 2 & 3. MHD 4 & 5 contained long distance billing records. The important point is that the controllers wrote all of the information to the disk in such a fashion that the even MHD was always 180 degrees out of phase with the odd MHD of that pair. That guaranteed the halving of the rotational latency assuming that both drives in the pair were in service.

May 12th, 2016, 03:28 PM
Factor in not only rotational latency but seek time and multiple drives look better and better, particularly when you're multi-programming. On the old mainframe systems, you could get a huge speedup by adding more channels and drives.

May 12th, 2016, 04:51 PM
Ok I meant to post this last night, since then there have been multiple posts. Thank you for all the responses.

While there are a multitude of various ways of increasing disk access speed, multiple actuators, one head for every cylinder, huge drive, lots of drives, RAID etc, my suggestion seems by comparison, economical.

Firstly I can see that my idea would be very complex with an embedded servo-track.

My area of interest here is when the new technologies such as SCSI and ESDI took over from ST-506. Sort '85 to '88. Also bear in mind that these sort of drives were used in small minis and workstations. A drive that has 2, 4 or 8 times the data rate, I would have thought would have an application.

If we work on the basis of a drive with a dedicated servo track, we are already reading data from one platter, to position the head on another platter. A stepper motor drive is point-and-hope. Both systems have their problems with thermal recalibration, however they are built with enough slop to avoid different expansion contraction under normal circumstances.

As an example, Say you took a drive like the 4 head MFM ST-225. You can set this up on a standard Controller and tell the controller it has only one head, (head 1). AFAIK Possible.

If you were to then take another logic board off another ST-225, make it think it is controlling the spindle, and make it think it is controlling the stepper motor. In actuality, it is acting as a slave, and just reads/writes where-ever the head is located. However this logic board is connected to head 2.

You do the same for heads 3 and 4. Now you have 4 logic boards connected to one drive.

Yes it is a Frankenstein creation, and i would guess that there would need to be some kind of sync between the logic boards. And it would need a LLformat.

However from a hypothetical standpoint i don't see what is preventing this from working. Essentially to the controller it appears as 4 separate one platter(side) drives just with a connected spindle.

-Expansion-contraction issues between cylinders, should not be altered.
-Expansion-contraction issues between sectors within a track, should not be altered.
-Expansion-contraction issues between sectors directly above each other, should not be altered.

-With regard to skew of sectors, (within a cylinder), "head-skew" as explained here: http://www.pcguide.com/ref/hdd/geom/tracksSkew-c.html would not be needed, as far as i can tell. This is a function of the time
required to change heads.

-Bit-skew, is something i am NOT familiar with. Chuck(G), Would you care to elaborate?

Now yes, a 4-drive ST-506 controller that can simultaneously send data to 4 drives is custom also. However it is not beyond the possibility of even a skilled hobbyist to modify say a SCSI-to-ST506 bridge board to do this.

If you then look at this from the perspective of a HDD manufacture, we can throw away a lot of redundant logic. We only need the read/write logic on logic boards 2, 3 and 4. and likewise for the controller.

Yes we have increased the cost of the head-amplifier circuits by 4, however we still have the same number of actuators, heads, motors, and platters, all high cost items. With regard to economies of scale, I don't think it is unreasonable to assume that if this technological avenue had been taken, a 4 head amplifier, chip/circuit would have come down in cost to a point where 2 could be included on say an integrated logic board on the bottom of a SCSI drive, and if only 4 heads were used in a particular configuration, one of the chips was removed/left as redundant.

Yes I know the ST-225 has a slow access time, it is just an example.

May 12th, 2016, 08:22 PM
"Bit skew" is encountered quite often in parallel-head technologies.

At its simplest, consider a 9 track tape (8 bits + parity) moving past a head. You assume that transitions on parallel tracks will occur at precisely the same time, but this is rarely the case--each track/surface will have its own unique characteristics. If you're going to pack your bits densely, you need to have some sort of synchronizing mechanism to compensate for this. That's why, for example, the CDC 808 I cited keeps 6 tracks to a single drive head, rather than dispersing the 6 tracks on 6 heads over the various platters. At high track densities, all you need is a thermal gradient across the stack and parallel cross-platter recording goes out the window.

May 13th, 2016, 01:53 AM
Sorry to come in late, but the DRUM on the original Ferranti Pegasus used two heads to speed up the data transfer. However it uses pairs of staggered heads on adjacent tracks so the bit stream comes off twice as fast as its recorded. Its also low density and a slow transfer rate (333Khz)