speck@cit-vlsi (Don Speck) (08/16/85)
(Summary: itty bitty microcomputers slow way way down if asked to run a
pipeline to perform a function instead of one monolithic program).
True, the business world cannot afford vaxen. But 68k boxes are as
capable as vax/750's, and a whole lot cheaper. On integer problems
a 68010 Sun will even *outrun* a 750, and is not bad on floating point
(I do all my SPICE simulations on Suns). We have the vaxes mainly
because we got them years ago, for half price.
Your itty bitty micro is slow mainly because it has a toy 5 1/4 inch
disk, instead of a Real Disk like an Eagle. (Chauvinist of me, I
know, but Unix does live & die by its disk). Floppy-disk OS's like
CPM & MSDOS sacrifice a lot to live with that *slow* little disk -
but why should Unix do so too? Especially when fast 8-inch disks
like Fuji's and Maxtor's are fairly cheap (especially compared to
the cost of your Unix license itself)?gabriel@anl-mcs (John Gabriel) (08/16/85)
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
peter@baylor.UUCP (Peter da Silva) (08/20/85)
> True, the business world cannot afford vaxen. But 68k boxes are as > capable as vax/750's, and a whole lot cheaper. I heard this rumor too, it just aint true. A mini will beat a micro, all other things being equal, on i/o bandwidth alone. > Your itty bitty micro is slow mainly because it has a toy 5 1/4 inch > disk, instead of a Real Disk like an Eagle. That's true. This 68010 with an Eagle does a great job. It also costs damn near as much as a little vax (or at least it costs more than my yearly salary... which comes to the same thing). > (Chauvinist of me, I > know, but Unix does live & die by its disk). Floppy-disk OS's like > CPM & MSDOS sacrifice a lot to live with that *slow* little disk - > but why should Unix do so too? Because those slow little disks are the only way to go, today. Us plebes have to put up with whatever the manufacturer likes... see below for why. > Especially when fast 8-inch disks > like Fuji's and Maxtor's are fairly cheap (especially compared to > the cost of your Unix license itself)? Only if you're talking about a source license. Most of us don't have one of those things. Also, don't you mean Maxtor 5.25"? Last I heard 8" hard drives were pretty much a loss. Yeh. I's LOVE a system with a Maxtor whateveritis (the 380Meg 5.25" drive), unfortunately nobody seems to be using them. Anyone have any idea why not? -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
sob@neuro1.UUCP (Stan Barber) (08/22/85)
In article <488@baylor.UUCP> peter@baylor.UUCP (Peter da Silva) writes: >> True, the business world cannot afford vaxen. But 68k boxes are as >> capable as vax/750's, and a whole lot cheaper. > >I heard this rumor too, it just aint true. A mini will beat a micro, all >other things being equal, on i/o bandwidth alone. > Wrong! WRONG! >WRONG!!!< For the sake of arguement, let's define a micro as a computer with a standard semiconductor chip-set (68000-series, 32032, 80286, NCR-32, etc.) and a mini as something like a VAX, a RISC machine and others.... Machines with high speed memory buses and SMD disks will run FASTER than a VAX 780 and certainly faster than a VAX 750 (not to mention a PDP-11 running V7 :-)) I have run benchmarks on many machines from CONVEX to PDP-11/23 and I KNOW that for computation the VAX is bad in price/performance. In terms of I/O bandwidth, it becomes of function of controllers, buses, and disks as well as memory and CPU. With the wide variety of all those things in the mini market, there are machine that optimize all those things and beat the vax hands down. >Also, don't you mean Maxtor 5.25"? Last I heard 8" >hard drives were pretty much a loss. > >Yeh. I's LOVE a system with a Maxtor whateveritis (the 380Meg 5.25" >drive), unfortunately nobody seems to be using them. Anyone have any idea >why not? The 8" are. The OEM's I work for on occasion use the 140 version which is VERY reliable. They are still waiting on the 380 to evaluate. This implies to me that they are available yet, so people CAN'T use them. >-- > Peter (Made in Australia) da Silva -- Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed Olan ARPA:sob@rice.arpa here are ONLY mine & Barber CIS:71565,623 BBS:(713)660-9262 noone else's.
sob@neuro1.UUCP (Stan Barber) (08/22/85)
In article <562@neuro1.UUCP> sob@neuro1.UUCP (Stan Barber) writes: > >The 8" are. The OEM's I work for on occasion use the 140 version which is >VERY reliable. They are still waiting on the 380 to evaluate. This implies to >me that they are available yet, so people CAN'T use them. ^^^ are not... Sorry. -- Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed Olan ARPA:sob@rice.arpa here are ONLY mine & Barber CIS:71565,623 BBS:(713)660-9262 noone else's.
peter@baylor.UUCP (Peter da Silva) (08/22/85)
> Wrong! WRONG! >WRONG!!!< > For the sake of arguement, let's define a micro as a computer with > a standard semiconductor chip-set (68000-series, 32032, 80286, NCR-32, etc.) > and a mini as something like a VAX, a RISC machine and others.... I like the definition of a micro as anything with a 1-chip CPU, and a mini as anything from several chips to a board for a CPU (thus allowing the LSI-11 chipsets in as micros), but I see no conflict here. > Machines with high speed memory buses and SMD disks will run FASTER than > a VAX 780 and certainly faster than a VAX 750 (not to mention a PDP-11 > running V7 :-)) I have run benchmarks on many machines from CONVEX to > PDP-11/23 and I KNOW that for computation the VAX is bad in price/performance. True. And an 11/70 outperforms it in multiuser benchmarks. > In terms of I/O bandwidth, it becomes of function of controllers, buses, and > disks as well as memory and CPU. > With the wide variety of all those things > in the mini market, there are machine that optimize all those things and > beat the vax hands down. In the mini market. How many *micros* running UNIX would you trust with 35 users doing cs-project type stuff at once? > >Also, don't you mean Maxtor 5.25"? Last I heard 8" > >hard drives were pretty much a loss. > > > >Yeh. I's LOVE a system with a Maxtor whateveritis (the 380Meg 5.25" > >drive), unfortunately nobody seems to be using them. Anyone have any idea > >why not? > > The 8" are. Pretty much a loss? > The OEM's I work for on occasion use the 140 version which is > VERY reliable. They are still waiting on the 380 to evaluate. This implies to > me that they are [not] available yet, so people CAN'T use them. Damn. they've only been advertised for a zillion years. -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
sob@neuro1.UUCP (Stan Barber) (08/22/85)
In article <508@baylor.UUCP> peter@baylor.UUCP (Peter da Silva) writes: >> I have run benchmarks on many machines from CONVEX to >> PDP-11/23 and I KNOW that for computation the VAX is bad in price/performance. > >True. And an 11/70 outperforms it in multiuser benchmarks. > Show me. I have yet to see ANYONE produce such results. I have run two copies of what I use for benchmarks and in many cases, the VAX is still slower.... Celerity is an excellant example. Of course, it should be realized that multiuser benchmarks are hard to do since the memory/swap issue becomes very important when multiple invocations are concerned. I am not sure that there is a good standrard metric for multiuser benchmarks that takes all these things into account (cache, memory, swap, FPA, etc.). > >In the mini market. How many *micros* running UNIX would you trust with 35 >users doing cs-project type stuff at once? > Not many, but the real point is that you can buy a bunch of small computers that run faster than a VAX for the price of a VAX. What is the difference between 3 micros with 10 users each and one vax with 35 users? The cost and perfomance (higher throughput with the 3 computers) are the main ones. > Peter (Made in Australia) da Silva -- Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed Olan ARPA:sob@rice.arpa here are ONLY mine & Barber CIS:71565,623 BBS:(713)660-9262 noone else's.
peter@baylor.UUCP (Peter da Silva) (08/23/85)
> >In the mini market. How many *micros* running UNIX would you trust with 35 > >users doing cs-project type stuff at once? > > Not many, but the real point is that you can buy a bunch of small computers > that run faster than a VAX for the price of a VAX. What is the difference > between 3 micros with 10 users each and one vax with 35 users? The cost and > perfomance (higher throughput with the 3 computers) are the main ones. Right, but what does that have to do with my original point that not every UNIX system in the world has sufficient power that you can throw it away in 'ls|foo|bar|zot|baz' every time you want a directory listing without feeling it. I think we've digressed just a mite, no? And I can think of few micros I'd trust with 10 users each. Certainly none in the personal-computer range. Maybe a few 20-grand-or-more supermicros like baylor or neuro1. Certainly not 7-grand-or-less machines like datafact, cathou, holmes, or (speaking in terms of what it would cost for an equivalent system today) hyd-ptd. -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
henry@utzoo.UUCP (Henry Spencer) (08/27/85)
> ... What is the difference > between 3 micros with 10 users each and one vax with 35 users? Don't forget having to keep three separate machines in synchronization when software changes. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
tanner@ki4pv.UUCP (Tanner Andrews) (08/30/85)
] diff between (1 vax @ 30 users ea) and (3 small machines @ 10 users ea) ] is keeping software updates in sync. The other difference is that when you have 1 failure, you get either (0 vaxen @ 0 users) or (2 small machines @ 15 slower-running users ea). -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner