rs@eddie.mit.edu (Robert E. Seastrom) (12/02/90)
In article <PST.90Dec1131440@ack.Stanford.EDU> pst@ir.Stanford.EDU (Paul Traina) writes: > >Back when there were REAL(tm) computers like 780, a lot of time and >energy went into designing efficient I/O from the CPU bus to the >electrons going to the disk or tty. > Damn right, but even the 780 was a step down. Get your KL-10 documentation set out and read about *them*. Front-end PDP-11s that did Tops-20's command completion. Seperate I/O and memory buses. 8-ported (that's eight, son) memory that talked to the I/O front-end machines for *real* DMA, not cycle stealing! >Sure OS's and apps have gotten bloated, but when you put a chip like >the MIPS R3000 on a machine barely more advanced than an IBM-AT you >end up with a toy that can think fast but can't do anything. I can't >really blame companies like DEC and Sun for producing mismatched >hardware, because their marketing drones are constantly trying to >undercut each other in price. It's a hell of a lot more expensive to >ship a product with a well designed I/O system than to drop in a >"killer bitchen" CPU chip; occasionally someone makes the attempt do >design a great piece of hardware, and you end up with something not >half bad (like the DECstation 5000, which is only crippled by Ultrix You left out the worst offender of them all - IBM. The RS-6000 may crank out 27 MIPS, but it can't context switch or handle interrupts worth shit. You can lower machine performance to the point of unusability by FTPing a file from another machine on the same ethernet segment! Next time get a chance to play with an RS-6000, try this: Pop about a dozen xterms, iconify them, put the icons in a row, and wave the pointer back and forth over them as fast as you can. Astounding, no? The highlighting on the icons will keep bouncing back and forth long after you stop waving the pointer. My personal record is 20 seconds. Makes a Sun-2 running display Postscript seem astoundingly fast. RS-6000s also have an annoying tendency to "lock up" for a few seconds (5 < x < 15) and then return to normal - I'm told that this is normal and due to paging activity. The microchannel card cage design is pretty bad too - sure, you can put cards in, but God help you if you have to take them back out! And you better tighten down the retaining screws all the way... or the first time you look at the card funny it will pop out. To its credit, I must say it compiles GNU Emacs faster than any other machine I've used, but I do more with a workstation than just run compiles. And, if you think Ultrix is bad, it's only because you haven't tried AIX. ---Rob -- Internet: rs@eddie.mit.edu | Copyright: Protecting your right to Bitnet: RS@SESTAK | copy software. X.25: PSI%0240200101905::KICKI::RS | ---gumby@cygnus.com
kdq@demott.COM (Kevin D. Quitt) (12/03/90)
In article <1990Dec2.154303.17105@eddie.mit.edu> rs@eddie.mit.edu (Robert E. Seastrom) writes: >In article <PST.90Dec1131440@ack.Stanford.EDU> pst@ir.Stanford.EDU (Paul Traina) writes: >> >>Back when there were REAL(tm) computers like 780, a lot of time and >>energy went into designing efficient I/O from the CPU bus to the >>electrons going to the disk or tty. >> > >Damn right, but even the 780 was a step down. Get your KL-10 >documentation set out and read about *them*. Front-end PDP-11s that >did Tops-20's command completion. Seperate I/O and memory buses. >8-ported (that's eight, son) memory that talked to the I/O front-end >machines for *real* DMA, not cycle stealing! Which in turn was a step down from the Sigmas, with 12 ported memory. (lots of little wires in those donuts). Every major device got its own port - the CPU was just another device. (You could plug a slave CPU into the bus while the system was running; after its self-test, the system would "find" it and start assigning it tasks). Lot of nice touches on that machine, like a line printer (not the driver) that kept track of hills and valleys. The CPU couldn't have been as powerful as a 68030 or 486, but it'd do real-time flight simulation without a hitch, or timeshare more than 90 users before it started to get annoying. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
wcs) (12/04/90)
In article <1990Dec2.154303.17105@eddie.mit.edu>, rs@eddie.mit.edu (Robert E. Seastrom) writes: > RS-6000s also have an annoying tendency to "lock > up" for a few seconds (5 < x < 15) and then return to normal - I'm > told that this is normal and due to paging activity. AAARGH! My VAX 11/780 used to behave in this pathological manner, which is much more annoying when you have a dozen people doing vi than one person. We were trying to do a 12MB process on a 4MB VAX, and had used 4.1BSD for a while. We got about the third copy of VAX Paging SVR2 to leave Summit - it wasn't a beta copy (which implies support), it was just a favor (thanks, Doris!) VAX OS's were somewhat flaky then because of the brain-damaged DEC UDA-50 disk controllers and suicidal-to-install DEC patchware, and our machine had a giMongous amount of memory compared to the average VAX or 3B2 of its day. Since our major application (a simulation which spent most of its time thrashing memory) was radically different from Summit's intended applications (vi/troff/cc with maybe a few 1/2MB user programs), their tuning advice for "big" systems only made things worse. Eventually, by doing the opposite of what they said, and using a VERY large swap area on disk, we were able to get a livable system. After a year or two, the price of memory finally came down to the point that we could afford 16MB (about $50K). RAM really is 100 times faster than disk :-) -- Pray for peace! Bill --- # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
rs@eddie.mit.edu (Robert E. Seastrom) (12/05/90)
wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: >rs@eddie.mit.edu (Robert E. Seastrom) writes: >> RS-6000s also have an annoying tendency to "lock >> up" for a few seconds (5 < x < 15) and then return to normal - I'm >> told that this is normal and due to paging activity. > >AAARGH! My VAX 11/780 used to behave in this pathological manner, >which is much more annoying when you have a dozen people doing vi >than one person. We were trying to do a 12MB process on a 4MB VAX, >and had used 4.1BSD for a while. We got about the third copy of >VAX Paging SVR2 to leave Summit - it wasn't a beta copy (which >implies support), it was just a favor (thanks, Doris!) Well, I was talking about running one X server and one Emacs in a machine with 16 MB of memory. I wasn't abusing the poor thing with a process that was 3 times as big as my physical memory (probably 4 times as big as available memory once you take out space for the kernel). >VAX OS's were somewhat flaky then because of the brain-damaged DEC >UDA-50 disk controllers and suicidal-to-install DEC patchware, >and our machine had a giMongous amount of memory compared to the >average VAX or 3B2 of its day. What, you were paging to a Unibus disk? UBAs weren't designed to do heavy-duty I/O. You'd probably have been much better off with a Massbus disk (find an RM03, hang it off a massbus adaptor of its own, and dedicate the whole disk to swap). I'm not saying that you had any choice (you probably had one of the early memory controllers that would only support 4 MB maximum anyway), but poor performance is to be expected on a system which you've seriously overloaded. I should think that a workstation that is billed as being blazingly fast would be able to handle running X and Emacs at the same time. ---Rob -- Internet: rs@eddie.mit.edu | Copyright: Protecting your right to Bitnet: RS@SESTAK | copy software. X.25: PSI%0240200101905::KICKI::RS | ---gumby@cygnus.com
v116kznd@ubvmsb.cc.buffalo.edu (David M Archer) (12/05/90)
In article <1990Dec4.164231.10291@eddie.mit.edu>, rs@eddie.mit.edu (Robert E. Seastrom) writes... >expected on a system which you've seriously overloaded. I should >think that a workstation that is billed as being blazingly fast would >be able to handle running X and Emacs at the same time. You've apparently never heard what Emacs stands for... <grin> --- Speaking of paging and those wonderfull things, we've recently been playing with a 3rd-party product which sortof lets a Macintosh II with an '030 processor have virtual memory. Problem is, it seems to require that the entire active application, along with the system, needs to reside in memory, and any other applications which might have been working in the background are more or less halted. And to think we thought a product that advertised that it gave one virtual memory could run a 7MB application with roughly 2MB of system memory in an 8MB machine. How foolish of us. One wonders if System 7 will handle virtual memory any better, although most sane people have given up wondering about System 7.