From: atbowler@thinkage.on.ca (Alan Bowler) Newsgroups: alt.folklore.computers Subject: Mainframe vs. supermini Date: 4 Jan 1999 19:34:59 GMT Organization: Thinkage Ltd. Lines: 28 Message-ID: <76r553$22s$1@nntp1.uunet.ca> References: <76p5o4$l8u@netaxs.com> <76qvdp$67g$2@teabag.demon.co.uk> NNTP-Posting-Host: 192.102.11.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!sunqbc.risq.qc.ca!torn!news.uunet.ca!atbowler In article <76qvdp$67g$2@teabag.demon.co.uk> cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) writes: > >Going off on a slightly different tack, I have unrelated question to /360s >which has been discussed to some extent in the NG in the past, but a comprehensive >answer still seems to be missing (unless I just missed it!) That is, since I >mentioned the VAX, "why isn't a VAX classed as a mainframe?" (Although people >often refer to them as such, they're often quickly corrected on the matter in >NGs such as this) I'd assumed it was something to do with physical size, but >the CPU and overall installation of a VAX system can be larger than the a /360 >or /370 site; I'd thought it was perhaps design concepts, but both beasts (the >larger models anyway) both offer enormous I/O throughput in comparison with their >CPU speeds, both have virtual memory, advanced batch-processing and time sharing. >The only other things I can think of is that either it was a deliberate marketing >decision on DEC's part, or that "only EBCDIC systems are mainframes." :) Any >comments, anyone? > I think its was because DEC prided itself as the inventor of the mini. I asked the same question once of a computer science prof that I has heard giving a tour of our computer room. He blithely dimissed the Honeywell DPS-8/49 as a mainframe, and proudly showed the visitors the VAX-780 which he called a supermini. The VAX cost the same as Honeywell, ran at about the same speed and took the same amount of floor space. There was the difference that the Honeywell did support about 2 to 3 times the number of concurrent online users ( partly by applying more restrictions on what 1 individual could do.). ###### From: eugene@cse.ucsc.edu (Eugene Miya) Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: 8 Jan 1999 01:54:50 GMT Organization: UC Santa Cruz CIS/CE Lines: 39 Message-ID: <773oha$2so@darkstar.ucsc.edu> References: <76p5o4$l8u@netaxs.com> <76qvdp$67g$2@teabag.demon.co.uk> <76r553$22s$1@nntp1.uunet.ca> NNTP-Posting-Host: arapaho.cse.ucsc.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!news.ucsc.edu!eugene In article <76r553$22s$1@nntp1.uunet.ca>, Alan Bowler wrote: >In article <76qvdp$67g$2@teabag.demon.co.uk> cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) writes: >>mentioned the VAX, "why isn't a VAX classed as a mainframe?" >>(Although people >>often refer to them as such, they're often quickly corrected on the matter in >>NGs such as this) I'd assumed it was something to do with physical size, but Those people are ignorant and not to be trusted. >>the CPU and overall installation of a VAX system can be larger than the a /360 >>or /370 site; I'd thought it was perhaps design concepts, but both beasts (the >>larger models anyway) both offer enormous I/O throughput in comparison with their >>CPU speeds, both have virtual memory, advanced batch-processing and time sharing. >>The only other things I can think of is that either it was a deliberate marketing >>decision on DEC's part, or that "only EBCDIC systems are mainframes." :) Any >>comments, anyone? > >I think its was because DEC prided itself as the inventor of the mini. This is somewhat true. But they quickly found themselves in a technical limitation: address space. >I asked the same question once of a computer science prof >that I has heard giving a tour of our computer room. He blithely >dimissed the Honeywell DPS-8/49 as a mainframe, and proudly showed the >visitors the VAX-780 which he called a supermini. Individual VAXen were rarely larger than 370s in size. You have to have clusters. The UNIBUS and MASSBUS had a lot of limitations compared to the IBM Channel architecture. Physical comparisons aren't necesarily good ones. Virtual memory is not necessarily seen as a plus. I work with Gordon Bell these days about once a month. He'd be amused. But the reality was that the best VAXens (9000s for instance) never matched comparably times 370s (3090s and later). ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: 9 Jan 1999 11:30:49 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777el9$vtu$5@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <76qvdp$67g$2@teabag.demon.co.uk> <76r553$22s$1@nntp1.uunet.ca> <773oha$2so@darkstar.ucsc.edu> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915883305 nnrp-04:24048 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 61 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!news.idt.net!woodstock.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <773oha$2so@darkstar.ucsc.edu>, eugene@cse.ucsc.edu (Eugene Miya) writes: > Those people are ignorant and not to be trusted. Which ones; the pros or antis? And why? > This is somewhat true. > But they quickly found themselves in a technical limitation: address space. How so? The architecture physically supported a "large" (can't remember how much exactly, but the last Vax I used had 3/8 GB core per cluster member) amount of memory, and it had the usual 4GB of virtual address space per memory map (although this was split into 4 x 1GB chunks for user, system etc from what I remember) I thought that this would be about the same amount of a mid-size mainframe of the same era, although I acknowledge that MVS allowed a process to use multiple memory maps (hence the name, I guess) > Individual VAXen were rarely larger than 370s in size. > You have to have clusters. The installations I've seen of S/370s and the larger Vax hardware (from the elderly 11/7XX series to the 6000s and 8000s) have typically been of comparible "size" in terms of CPU power, storage and physical floorspace, but perhaps that's just my limited experience. > The UNIBUS and MASSBUS had a lot of > limitations compared to the IBM Channel architecture. Physical > comparisons aren't necesarily good ones. I'd be interested what the limitations were (seriously, I'm not being argumentative here) The newer XMI bus was supposed to be pretty quick; I can't remember the figures, although ISTR that overall transfer rates per CPU were in the region of hundreds of MB per second (okay, not that Earth-shattering today, but for contemporary systems I understand that it was okay performance) Would this compare to a few dozen bus'n'tag channels? Where would ESCON fit into things (ie performance-wise, peak and sustained throughput etc) > Virtual memory is not > necessarily seen as a plus. Why do you say that? I know that swapping and paging can be a bugger on PC-type systems because the I/O is normally so pants in comparison with the CPU speed, but the bigger systems were always better-balanced so I thought that wasn't so much of an issue? > I work with Gordon Bell these days about once a month. > He'd be amused. But the reality was that the best VAXens (9000s for > instance) never matched comparably times 370s (3090s and later). In what way would he be amused? And in what ways did the Vaxes not match the contemporary S/370s (or the early S/390s)? Although I perhaps sound like a "doubting Thomas" here, I'm really just trying to obtain as much info as possible to satisfy my own curiousity. I know a fair amount about DEC systems, but not a lot about their IBM counterparts (if I'm allowed to call them that!) other than some dribs and drabs I've picked up along the way, and would like to find out more. Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: 9 Jan 1999 18:23:38 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <7786ra$8r4$6@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <76qvdp$67g$2@teabag.demon.co.uk> <76r553$22s$1@nntp1.uunet.ca> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915908447 nnrp-09:27984 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 112 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76r553$22s$1@nntp1.uunet.ca>, atbowler@thinkage.on.ca (Alan Bowler) writes: > I think its was because DEC prided itself as the inventor of the > mini. I asked the same question once of a computer science prof > that I has heard giving a tour of our computer room. He blithely > dimissed the Honeywell DPS-8/49 as a mainframe, and proudly showed the > visitors the VAX-780 which he called a supermini. > > The VAX cost the same as Honeywell, ran at about the same speed > and took the same amount of floor space. There was the difference > that the Honeywell did support about 2 to 3 times the number of > concurrent online users ( partly by applying more restrictions > on what 1 individual could do.). Actually, I dug up an old post covering this topic by Tom Harrington a couple of years ago (hope nobody minds me reposting it) Chris. From: tph@longhorn.uucp (Tom Harrington) Newsgroups: alt.folklore.computers Subject: Re: What's a VAX Date: 5 Feb 1997 20:11:16 GMT Organization: Mechanist Industries Matthew Crosby (crosby@nordsieck.cs.colorado.edu) wrote: : These days, it seems "mainframe" has come to mean "any computer I do not : sit at the console of" in popular parlace. : I've also heard HP 9000/400s and Sun 3s described as mainframes. Sigh. Oh, good. Now I have an excuse to repost my "It might be a mainframe if..." list (once again with absolutely no apologies to Jeff Forworthy). It might be a mainframe if... ----------------------------- If you could kill someone by tipping it over on them, it might be a mainframe. If the only "mouse" it has is the one living inside it, it might be a mainframe. If you need earth-moving equipment to relocate it, it might be a mainframe. (thanks to Tor Sjowall) If you've ever lost an oscilloscope inside of it, it might be a mainframe. (thanks to Tim Shoppa) If it's big enough to be used as an apartment, it might be a mainframe. If it has ever had a card-punch designed for it, it might be a mainframe. If it weighs more than an RV, it might be a mainframe. If lights in the neighborhood dim when it's powered up, it might be a mainframe. If it arrived in its own moving van, it might be a mainframe. If its disk platters are big enough to cook pizzas on, it might be a mainframe. If Michael Jordan would need his entire annual salary to buy one, it might be a mainframe. If keeping all of the manuals together creates a fire hazard, it might be a mainframe. If it's so large that a dropped pen will slowly orbit it, it might be a mainframe. If it's ever been mistaken for a refrigerator, (or if the disk drive has ever been mistaken for a washing machine), it might be a mainframe. If anyone has ever frozen to death in the room where it's kept, it might be a mainframe. If it has a power supply that's bigger than your car, it might be a mainframe. If it has its own postal code, it might be a mainframe. If the operators considered the addition of COBOL to be an upgrade, it might be a mainframe. If it was designed before you were born, it might be a mainframe. If its main power cable is thicker than your neck, it might be a mainframe. If the designers have since died from old age, it might be a mainframe. : In fact, it seems modern usage goes something like: : "WWW" - Their ISPs computer And of course "WWW", "web", and "internet" are synonyms, right? -- Tom Harrington ------- tph@rmii.com ------- http://rainbow.rmii.com/~tph "I would like to nominate Tom Harrington for Usenet sainthood!" -Leo G. Simonetta (arclgs@langate.gsu.edu) -> Fractal Kit: http://rainbow.rmii.com/~tph/fractalkit/fractal.html <- ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: 10 Jan 1999 09:21:39 GMT Organization: Daedalus Consulting Lines: 85 Message-ID: <779rf3$ajn$1@news.wlg.netlink.net.nz> References: <76p5o4$l8u@netaxs.com> <773oha$2so@darkstar.ucsc.edu> <777el9$vtu$5@teabag.demon.co.uk> <23o877.geb.ln@really.bogus.com> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don In article <23o877.geb.ln@really.bogus.com>, wrote: >> member) amount of memory, and it had the usual 4GB of virtual address >> space per memory map (although this was split into 4 x 1GB chunks for >> user, system etc from what I remember) > >Nope... What I think you're refering to is the CPU mode. ie. USER, EXEC, >SUPER and KERNEL. Memory is memory is memory and can be used by anyone >up to the values specified in the users profile. He's right. The VAX architecture originally split virtual address space into four 1GB regions, P0 from 0-1G, P1 from 1G to 2G, S0 from 2G-3G and S1 from 3G to 4G. In practice, S1 was never actually implemented, and in the late 80s the architecture documents were amended to define S0 as the 2GB from 2G to 4G. The 11/780 actually has reserved system registers at the addresses where you'd kinda expect a fourth address space base and length registers to be (ie P0 base at 24, P1 base at 25, system base at 26 and reserved at 27, and a similar patter among the length registers). P0 space starts from 0 and grows upwards. Usually that's where your program, data and heap live. P1 starts at 2G (7FFFFFFF) and grows downward; typically there's a bunch of per-process systemy stuff up there, with the user stack on the bottom pushing downward toward the 1G boundary. P0 and P1 are per-process spaces, that is, each hardware process context has its own copies of the P0 and P1 size and base registers (base points to the array of page descriptors, size determines how many there are). When you context switch, the previous process's memory becomes invisible, and the switched-in process's memory which was formerly invisible to the system becomes visible. (Of course individual pages may be mapped to more than one process, but each process is not aware of how other processes may have mapped a geven page unless they go grovelling around in the other process's page table.) S0 space is common to all processes, and is the realm of the operating system. Usually, the pages in S0 are off-limits to user-mode code, simply through the user/super/exec/kernel page protection, but the address space is always visible. >The _only_ thing that I know for sure about the IBM Channel architecture is >that it is quite a bit faster that Digitals UNIBUS which was essentially a >serial bus. The MASSBUSS was still slower that IBM but a quite a bit faster >than Digitals UNIBUS. Basically at the tim the go was that if you wanted >to do heavy compute bound work a VAX was the way to go. If, however, I/O was >your poison then IBM got the job. Generalizing to buggery here...:) Of course >now that we've got fibre channel SCSI..... Those old DEC mini busses were not very fast. UNIBUS could get up to 5 MB/s on a good day with a following wind and favrourable sea, but in real life tended to float around 2-3 MB/S. MASSBUS was faster, but not a heck of a lot. Serial bus? UNIBUS is 16 data bits wide (and 18 address bits). MASSBUS was 32 data bits. But it is a bus, not discrete channels. The VAX 11/780 used the SBI (Synchronous Bus Interconnect) which attached the CPU (or even two if you held your mouth right and didn't mind making the OS work yourself!), memory, MASSBUS adapters (MBAs) and UNIBUS adapters. (The latter give rise the the infamous Failed UniBus Address Register, or FUBAR. Yes, it's really called that. 8-) So you could get extra I/O bandwidth by hanging more than one MBA off the SBI. For large disk farms you really had to look at CI, which is serial, at about 70 Mb/s per channel, and each CI node had two channels. Again, you could hang several of these off one CPU. You'd attach CPUs and HSCs (Hierarchical Storage Controller -- allegedly HSC originally stood for "Hot Shit Controller" and the name HSC was well ingrained before Marketing noticed) onto the CI, and disks onto the HSCs. You'd talk to them using MSCP. MSCP (Mass Storage Control Protocol) is basically the DEC's answer to the channel program, at least for disks. MSCP controllers work by processing lists of instructions from memory, and doing the necessary abstractions to deal with whatever hardware was actually out there, from SDI disks attached to HSCs down to grotty little MFM disks attached to the utterly appalling RQDX1 (which needed a 3:1 interleave on slow crap peecee-style disks because it couldn't keep up, never mind its other brokennesses). I've seen MSCP controllers talking to MFM, ESDI, SCSI, SMD, SDI, LESI & standard floppy drives. Same driver for all types of hardware. -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### Mime-Version: 1.0 X-Newsreader: knews 1.0b.0 References: <76p5o4$l8u@netaxs.com> <76qvdp$67g$2@teabag.demon.co.uk> <76r553$22s$1@nntp1.uunet.ca> <773oha$2so@darkstar.ucsc.edu> <777el9$vtu$5@teabag.demon.co.uk> From: mforsyth@really.bogus.com () Subject: Re: Mainframe vs. supermini Newsgroups: alt.folklore.computers Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jan 1999 10:17:54 +1059 Message-ID: <23o877.geb.ln@really.bogus.com> NNTP-Posting-Host: 203.40.56.55 X-Trace: 10 Jan 1999 09:34:26 +1000, 203.40.56.55 Lines: 96 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!news.maxwell.syr.edu!newsfeed.berkeley.edu!intgwpad.nntp.telstra.net!nsw.nntp.telstra.net!139.134.5.33!really.bogus.com!nobody In article <777el9$vtu$5@teabag.demon.co.uk>, cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) writes: > In article <773oha$2so@darkstar.ucsc.edu>, > eugene@cse.ucsc.edu (Eugene Miya) writes: > > How so? The architecture physically supported a "large" (can't remember > how much exactly, but the last Vax I used had 3/8 GB core per cluster VAX address space is 32 bit AXP address space is 64 bit. That's the only real memory size limitation. A cluster is made up of a number ( max 63 ) VAXen or Alphas running Openvms. Each node can support up to it's max amount of memory. Memory can't be shared between cluster nodes. Disks tapes etc can be. The idea of a cluster is that you can have a number of systems running off the same system disk using common system files. All disks and tapes from all machines acan be seen and mounted adn used on all other systems in the cluster. If logins are via terminal servers the load balancing can be done for interactive logins. > member) amount of memory, and it had the usual 4GB of virtual address > space per memory map (although this was split into 4 x 1GB chunks for > user, system etc from what I remember) Nope... What I think you're refering to is the CPU mode. ie. USER, EXEC, SUPER and KERNEL. Memory is memory is memory and can be used by anyone up to the values specified in the users profile. > I thought that this would be > about the same amount of a mid-size mainframe of the same era, although > I acknowledge that MVS allowed a process to use multiple memory maps > (hence the name, I guess) > >> Individual VAXen were rarely larger than 370s in size. >> You have to have clusters. > > The installations I've seen of S/370s and the larger Vax hardware (from > the elderly 11/7XX series to the 6000s and 8000s) have typically been of > comparible "size" in terms of CPU power, storage and physical floorspace, > but perhaps that's just my limited experience. No that's about right...:) > >> The UNIBUS and MASSBUS had a lot of >> limitations compared to the IBM Channel architecture. Physical >> comparisons aren't necesarily good ones. > > I'd be interested what the limitations were (seriously, I'm not being > argumentative here) The newer XMI bus was supposed to be pretty quick; > I can't remember the figures, although ISTR that overall transfer rates > per CPU were in the region of hundreds of MB per second (okay, not that > Earth-shattering today, but for contemporary systems I understand that > it was okay performance) Would this compare to a few dozen bus'n'tag > channels? Where would ESCON fit into things (ie performance-wise, peak > and sustained throughput etc) The _only_ thing that I know for sure about the IBM Channel architecture is that it is quite a bit faster that Digitals UNIBUS which was essentially a serial bus. The MASSBUSS was still slower that IBM but a quite a bit faster than Digitals UNIBUS. Basically at the tim the go was that if you wanted to do heavy compute bound work a VAX was the way to go. If, however, I/O was your poison then IBM got the job. Generalizing to buggery here...:) Of course now that we've got fibre channel SCSI..... > >> Virtual memory is not >> necessarily seen as a plus. > > Why do you say that? I know that swapping and paging can be a bugger > on PC-type systems because the I/O is normally so pants in comparison > with the CPU speed, but the bigger systems were always better-balanced > so I thought that wasn't so much of an issue? > >> I work with Gordon Bell these days about once a month. >> He'd be amused. But the reality was that the best VAXens (9000s for >> instance) never matched comparably times 370s (3090s and later). > > In what way would he be amused? And in what ways did the Vaxes not > match the contemporary S/370s (or the early S/390s)? The only real problem was I/O throughput. There IBM excelled. The VAX 9000 was a complete lemon. Worse than an Edsel. I think they only sold about 0.3 or them. Tehy erquired a different version of VMS, enough power to supply a third world country and enough money to buy aforementioned third world country. > > Although I perhaps sound like a "doubting Thomas" here, I'm really just > trying to obtain as much info as possible to satisfy my own curiousity. > I know a fair amount about DEC systems, but not a lot about their IBM > counterparts (if I'm allowed to call them that!) other than some dribs > and drabs I've picked up along the way, and would like to find out more. > > Chris. ###### From: jmfbahciv@aol.com Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: Sun, 10 Jan 99 12:58:48 GMT Organization: UltraNet Communications, Inc. Lines: 25 Message-ID: <77a9qn$pos$3@strato.ultra.net> References: <76p5o4$l8u@netaxs.com> <773oha$2so@darkstar.ucsc.edu> <777el9$vtu$5@teabag.demon.co.uk> <23o877.geb.ln@really.bogus.com> <779rf3$ajn$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: d16.dial-16.mbo.ma.ultra.net X-Complaints-To: abuse@ultra.net X-Ultra-Time: 10 Jan 1999 13:26:47 GMT X-Newsreader: News Xpress Version 1.0 Beta #4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!feeder.qis.net!newsfeed.xcom.net!news.ultranet.com!d16 [Caveat: Thread drift]In article <779rf3$ajn$1@news.wlg.netlink.net.nz>, don@news.daedalus.co.nz (Don Stokes) wrote: >In article <23o877.geb.ln@really.bogus.com>, > wrote: >You'd attach CPUs and HSCs >(Hierarchical Storage Controller -- allegedly HSC originally stood for >"Hot Shit Controller" and the name HSC was well ingrained before >Marketing noticed) onto the CI, and disks onto the HSCs. I can't verify that allegedly but I can tell you that we did that kind of naming often. Then, after everything was set in concrete, SPDs and getting sold, we could tell our customers, unofficially, of course, what the real acronym was. They enjoyed the hoodwinking of the marketing types, and had a great story to carry back to their colleagues. It was our tiny little way to rebel and thumb our noses at Miss Manners :-). /BAH Subtract a hundred and four for e-mail. ###### From: "Gareth Alun Evans" Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: Mon, 11 Jan 1999 10:30:44 -0000 Message-ID: <916051810.24088.8.nnrp-03.9e98250c@news.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <773oha$2so@darkstar.ucsc.edu> <777el9$vtu$5@teabag.demon.co.uk> <23o877.geb.ln@really.bogus.com> <779rf3$ajn$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: cemetery.demon.co.uk X-NNTP-Posting-Host: cemetery.demon.co.uk:158.152.37.12 X-Trace: news.demon.co.uk 916051810 nnrp-03:24088 NO-IDENT cemetery.demon.co.uk:158.152.37.12 X-Complaints-To: abuse@demon.net X-Newsreader: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Lines: 19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newshub.bart.net!bullseye.news.demon.net!demon!news.demon.co.uk!demon!cemetery.demon.co.uk!not-for-mail Don Stokes wrote in message <779rf3$ajn$1@news.wlg.netlink.net.nz>... >Those old DEC mini busses were not very fast. UNIBUS could get up to 5 >MB/s on a good day with a following wind and favrourable sea, but in >real life tended to float around 2-3 MB/S. MASSBUS was faster, but not >a heck of a lot. >Serial bus? UNIBUS is 16 data bits wide (and 18 address bits). MASSBUS >was 32 data bits. But it is a bus, not discrete channels. On the first PDP-11 I worked on (1971), ISTR that the Unibus could be up to 56 feet in length. It was two white ribbon cables which dragged across the floor, got bent when chair legs ground into them. I suppose that at with the speed of light in cables about 5nsecs per foot, that made the bus quite slow (200-ish nanosecs) by modern standards! ISTR that the slowest instruction (except for RESET) was BICB op, @(Rx)+ which took about 18 microseconds. ###### From: "The XO" Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <773oha$2so@darkstar.ucsc.edu> <777el9$vtu$5@teabag.demon.co.uk> <23o877.geb.ln@really.bogus.com> <779rf3$ajn$1@news.wlg.netlink.net.nz> Subject: Re: Mainframe vs. supermini Date: Wed, 13 Jan 1999 00:04:53 +1030 Lines: 70 Organization: Headquarters X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 NNTP-Posting-Host: netcafe.pirie.mtx.net.au Message-ID: <369b4f92.0@news.mtx.net.au> X-Trace: 13 Jan 1999 00:05:14 -1050, netcafe.pirie.mtx.net.au Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news.mel.connect.com.au!news.syd.connect.com.au!nsw.nntp.telstra.net!news1.mpx.com.au!news1.optus.net.au!optus!yorrell.saard.net!duster.adelaide.on.net!news.saix.saia.asn.au!news.mtx.net.au!netcafe.pirie.mtx.net.au Don Stokes wrote in message <779rf3$ajn$1@news.wlg.netlink.net.nz>... >In article <23o877.geb.ln@really.bogus.com>, >Those old DEC mini busses were not very fast. UNIBUS could get up to 5 >MB/s on a good day with a following wind and favrourable sea, but in >real life tended to float around 2-3 MB/S. MASSBUS was faster, but not >a heck of a lot. Some of the (not much) later ones were a LOT quicker. The 8500 & 8800 series had VAXBI (Backplane Interconnect) buss as well as UNIBUS. The 32 bit BI ran at around 13 Mbytes per second. Later Vaxen like the 6000 series, (Circa 1988-89) had XMI (Xtended Memory Interconnect) which ran at around 100 Mbytes per second. Some of these could mount 4 or even 6 CPU's. VMS supports Symmetrical Multiprocessing "out of the box" pretty well. >For large disk farms you really had to look at CI, which is serial, at >about 70 Mb/s per channel, and each CI node had two channels. Again, >you could hang several of these off one CPU. Mostly to improve reliability, you could connect an RAxx series drive, which had two SDI channels, to two HSC's, this could improve throughput if you had lots of disc access, from different nodes, and also gave redundancy in the event of a HSC failure. The discs could be set up as shadow sets of several drives appearing as one virtual drive (sorta like RAID) to give redundancy at disk level. The HSC could do other fancy tricks without the host computer involved too, even backups. >(Hierarchical Storage Controller -- allegedly HSC originally stood for >"Hot Shit Controller" and the name HSC was well ingrained before >Marketing noticed) onto the CI, and disks onto the HSCs. You'd talk >to them using MSCP. The HSC's were/are (I still have some in use) PDP-11's running a special mass storage handling operating system called CRONIC (Colorado Rudimentary Operating Nucleus for Intelligent Controllers - really!) >MSCP (Mass Storage Control Protocol) is basically the DEC's answer to >the channel program, at least for disks. MSCP controllers work by >processing lists of instructions from memory, and doing the necessary >abstractions to deal with whatever hardware was actually out there, from >SDI disks attached to HSCs down to grotty little MFM disks attached to >the utterly appalling RQDX1 (which needed a 3:1 interleave on slow crap >peecee-style disks because it couldn't keep up, never mind its other >brokennesses). I've seen MSCP controllers talking to MFM, ESDI, SCSI, >SMD, SDI, LESI & standard floppy drives. Same driver for all types of >hardware. This is the heart of clustering from multiple, different platforms. You can have a cluster with a "big" Vax with it's HSC or two, a collection of RA drives hanging therefrom, a Microvax with a crappy little MFM RD54 also served to the cluster, and a Vaxstation with its SCSI drives available to the cluster as well. Take a bow MSCP. Cheers Geoff Roberts Computer Room Internet Cafe Port Pirie South Australia Spam countermeasures netcafe at pirie dot mtx dot net dot au ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: Mainframe vs. supermini Date: 14 Jan 1999 09:40:11 GMT Organization: Daedalus Consulting Lines: 99 Message-ID: <77ke1r$f0v$1@news.wlg.netlink.net.nz> References: <76p5o4$l8u@netaxs.com> <23o877.geb.ln@really.bogus.com> <779rf3$ajn$1@news.wlg.netlink.net.nz> <369b4f92.0@news.mtx.net.au> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.wli.net!newsfeed.berkeley.edu!newsfeed.concentric.net!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don In article <369b4f92.0@news.mtx.net.au>, The XO wrote: > >Don Stokes wrote in message <779rf3$ajn$1@news.wlg.netlink.net.nz>... >>Those old DEC mini busses were not very fast. UNIBUS could get up to 5 >>MB/s on a good day with a following wind and favrourable sea, but in >>real life tended to float around 2-3 MB/S. MASSBUS was faster, but not >>a heck of a lot. > >Some of the (not much) later ones were a LOT quicker. I did say the old ones. >The 8500 & 8800 series had >VAXBI (Backplane Interconnect) buss as well as UNIBUS. The 32 bit BI ran at >around 13 Mbytes per second. The Nautilus machines (8800, 8700, 8550, 8530, 8500) and Polarstar (88n0, where n > 0 -- basically an upgraded 8800 with up to four processors instead of maxing out at two) machines had their own fast system bus (NBI?). From that hung one or two VAXBI adapters. The 82x0 & 83x0 machines used the BI as a system bus. Both approaches could also take the dreaded DWBUA VAXBI to almost UNIBUS adapter. (There was a bunch of stuff that worked fine on a 780 or 750's UBA, but choked when faced the DWBUA got involved.) >Later Vaxen like the 6000 series, (Circa 1988-89) had XMI (Xtended Memory >Interconnect) which ran at around 100 Mbytes per second. Some of these >could mount 4 or even 6 CPU's. VMS supports Symmetrical Multiprocessing >"out of the box" pretty well. Yep. The XMI supported multiple BIs, from which you could attach DWBUAs. And then the 7000 series boxes came out which had a new system bus, which could support multiple XMIs, which could... VMS never supported really large numbers of CPUs -- 6 or thereabouts was usually the upper limit. The limitation was generally system bus throughput -- as long as the things were built with CPUs accessing a common memory pool via a shared bus, the maximum number of CPUs was never going to get much out of single digits. Large scale multiprocessing requires more imaginative hardware and software than those systems offered. >Mostly to improve reliability, you could connect an RAxx series drive, which >had two SDI channels, to two HSC's, this could improve throughput if you had >lots of disc access, from different nodes, and also gave redundancy in the Only one SDI channel is active at a time on RAxx disks. Typically, what you'd do is connect two HSCs sharing the same allocation class (so the disk appears as the same device name regardless of which HSC claims it as its own). >event of a HSC failure. The discs could be set up as shadow sets of several >drives appearing as one virtual drive (sorta like RAID) to give redundancy >at disk level. The HSC could do other fancy tricks without the host >computer involved too, even backups. Yep. 'course the backups were only image copies of the disks -- you could copy (say) and RA81 to another RA81, or an RAxx to tape. But not an RA81 to an RA82, as the HSC had no concept of VMS filesystems. (CRONIC used the RT11 filesystem on floppies or TU58s for its own stuff.) Shadowing was a bit more complicated. The HSC would do the grunt work in shadowing (which meant that both (all) drives in a shadow set needed to be "claimed" by the same HSC), but you still saw discrete device names for each shadow member, plus a new device name for the shadow set. You could drop a disk out of a shadow set and access it as a normal drive, then poke it back in and the HSC would do the shadow copy. The HSC was smart enough to do seek optimisation between both members of the shadow set, which gave a good read performance boost for, eg, system disks. Unfortunately, DEC then brought in "Phase-II" shadowing, where the shadowing is done by the hosts. "Phase-I" or HSC based shadowing was unceremoniously dumped. To add insult to injury, if you had a mixed (CI and ethernet) cluster with a bunch of satellite workstations out on the ethernet sharing the HSC disks from the CI machines, DEC insisted that you buy a shadowing licence for all machines that accessed the shadowed disks, whereas with Phase-I only the machines doing the serving needed shadowing licences. Most sites doing HSC based shadowing stuck with the old Phase I shadowing and told DEC where they could stick their new whizbang Phase II stuff, right up until DEC pulled the product, and then just learned to live without shadowing after that. Not one of DEC's finest hours. >The HSC's were/are (I still have some in use) PDP-11's running a special >mass storage handling operating system called CRONIC (Colorado Rudimentary >Operating Nucleus for Intelligent Controllers - really!) Ah, I was trying to remember what the R in CRONIC stood for, thanks! The HSCs were only sorta pdp11s. They had F-11 (HSC50) and J-11 (HSC70 and others) processors, but the bus wasn't Qbus or UNIBUS. Basically, the CPU just played traffic cop; all the action between the interface cards (requestors) and memory was DMA. The result was that even with a dozen disks going flat tack, even the little F-11 wasn't breathing hard. ('course the TU58s got a bit tiresome on the HSC50.) -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724