the world is not all vaxen

John Gabriel gabriel at anl-mcs
Sat Aug 17 06:35:45 AEST 1985


Re Disk Drives on Itty Bitty Machines.

This is not to express dissent with all the other (possibly contradictory)
opinions out there, but to mention a few issues in the tarpit between
hardware and software. I run several PC/XT clones at home (supporting
my wife's consulting business). The UNIX implementation is UNISOURCE
(VENTURECOM) VENIX, we do our own hardware maintenance (we don't like
downtime), and I have dabbled in disk controller design.

Here are some of the issues (I apologise for boring those of you who
have heard some or all of this before):-

1. Logically adjacent sectors, i.e. sector 1, sector 2, .... as seen
	by the software are not always physically adjacent on the
	track. This is called "interleave", and it is necessary because
	the I/O bus may not support data transfer rates of 5Mbit/sec,
	the controller may not have a RAM buffer one track long, and
	the controller hardware may need an interval longer than the
	time between sectors to get its act together for reading another
	sector.

2. These issues are going to be important because of the 700,000 IBM
	PC's out there, forthcoming "peripheral boards" carrying
	a 750 equivalent CPU chip and a few megabytes of RAM, which
	relegate the 8088 to work as an I/O channel (sorry for the
	IBM jargon - my almost 30 years in the business shows even
	though I haven't been near a 360/370/3081/... for a decade).
	These "peripheral boards" presently carry mainly 4.2 BSD, but
	will carry version V, and are expected to retail at prices
	roughly that of an XT.

3. The "standard" disk controller on an XT is simlar to the XEBEC 1210A
	and is usually configured for an interleave of 6. A whole track
	is roughly 4K bytes, and takes 6 revolutions to read. At 3600 RPM
	i.e. 60 rev/sec, this is 100 milliseconds, so a fast seek is not
	always as important as some glossy advertising would have you
	think. A caveat on this appears later. Also dont be misled into
	thinking that 35 milliseconds track0 -> track 306 means 2 or 3
	milliseconds to a neighbouring track. 

4. It is possible to reduce the interleave to 2, i.e. every other sector
	on an XT before you overrun the DMA speed of the the I/O channel.
	Other controllers, e.g. the Adaptec 2000 series allow an
	interleave of 1. This is supportable by faster 8086 systems and
	an on board buffer runs as a FIFO. That way you get a whole
	track in 16millisecs, and a whole cylinder in 64 millisecs.
	There is of course 8 millisec of rotational latency.

5. On an inexpensive  5 1/4" drive, it takes about 18 millsec for the head
	to settle after a move to an adjacent track. For top dollar, there
	are said to be drives using voice coil actuators where this figure
	is about 5 millisecs.

6. All the above are relevant considerations in swapping core images. If
	on the other hand, you are demand paging for 512 or 1024 bytes at
	a time, things look slightly different because disk reads are at
	random; if only one process is paging, on close by tracks, if
	several processes paging then across the whole swapping area
	(which still isn't big compared with a full throw seek).
	This makes the head settling time a dominant parameter in actual
	data rates achieved. I'd be interested to know in detail how the
	demand paging special hardware on the AT&T 7300 addresses this.
	

7. Another consideration is use of the 640K of the XT as a staging area
	for disk sectors, again with an LRU replacement algorithm. There
	are disk subsystems for VAXEN with fairly large RAM buffers
	claimed to do VERY well using these kinds of tricks. Some of them
	are said to use a number of small (5 1/4" or 8" drives) and an
	adaptive algorithm to split frequently used disk regions around
	several drives so as to minimise the frequency of contention for
	R/W mechanisms or head motion.

8. In many large hard disk subsystems on 78X Vaxen, the limiting resource
	is R/W mechanisms, if you are working on track 0 and your neigbour is
	on track 600, you are going to get in each other's hair pretty
	badly. A double CPU 11/780 with 40 users and four or five disk
	drives might easily get hammered pretty badly this way.


CONCLUSIONS:-

1. Don't conclude that a Brand X disk and controller will clean up I/O
bottlenecks on itty-bitty systems.

2. These problems are going to get worse as people start plugging boards
with 16032 or 680XX chips into those 700,000 PC's out there.

3. A number of possible solutions exist showing potential for real 11/780
performance out of upgraded IBM PC's (I don't mean to say I like
the IBM PC, but it is an interesting I/O processor having a wide variety
of peripheral devices already available. This makes the job of building
a single user functional equivalent to an 11/780 without floating point
hardware, for a retail price around $5000 or a little more manageable).

4. Don't sell carefully thought out 5 1/4" subsystems short. There is a
means to get 320 megabits/sec out of a large 5 1/4" subsystem. Amdahl's
constant suggests that is enough to support a 320 Mip machine, i.e.
320 11/780's running as a multiprocessor. And 64 5 1/4" 10 Mbyte drives
cost only $16K for the bare drives.

5. The mixture as before in disk subsystem design is a recipe for trouble,
i.e. don't expect a strategy optimised for 600 Mbyte drives and
controllers to work with 30x20 Mbyte 5 1/4" Winchesters. But those 30 5
1/4" drives have 30 R/W heads instead of only one, and this gives
degrees of freedom for problem solving not present in the large
drives. So does the price of 64K DRAM at $1.00 per chip (retail).

6. A whole other document could be written about the combination of R/W
optical disks and large RAM buffers. But elderly codgers like myself
tend to talk too much anyhow. Perhaps somebody out there whose hands
are not tied by non-disclosure agreements or employers trade secrets
would like to write that article.

p



More information about the Comp.unix.wizards mailing list