Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!gabriel@anl-mcs From: gabriel@anl-mcs (John Gabriel) Newsgroups: net.unix-wizards Subject: Re: the world is not all vaxen Message-ID: <772@brl-tgr.ARPA> Date: Fri, 16-Aug-85 16:35:45 EDT Article-I.D.: brl-tgr.772 Posted: Fri Aug 16 16:35:45 1985 Date-Received: Tue, 20-Aug-85 21:33:49 EDT Sender: news@brl-tgr.ARPA Lines: 116 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