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