Re: Fw: Re: 308x Processors - was "Mainframe articles"
>3033 and 3081 in 370 mode were 24bit 16mbyte) addressing (real & virtual). We had 40M on our 3081 in 370 mode. Virtual was 16, but the OS could use the extra 24M, not as efficiently as XA, but it was used. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Fw: Re: 308x Processors - was "Mainframe articles"
steve_thomp...@stercomm.com (Thompson, Steve) writes: > > > 3033 and 3081 in 370 mode were 24bit (16mbyte) addressing (real & > virtual). > > > > Didn't the 30xx machines have 26 bit addressing (the "3033 mode") when > operating in S/370 mode? Starting with the 3033MP? re: http://www.garlic.com/~lynn/2009g.html#71 308x Processors - was "Mainframe articles" ... the 3033 had special page table entry definition for 14-bit real page number (16384 4096byte real pages or 64mbytes). the internal 3033 hardware could address more than 16mbites ... but instructions (both real and virtual) were limited to 24bits. 3033 hardware hack for >16mbytes ... supported >16mbyte "effective" addresses from (31bit) IDALs or as output of virtual address translation (using 14bit page number in the page number entry). however instruction addressing (whether running in virtual addressing mode or running w/o virtual address translation turned on) was still limited to 24bit addressing. the "32mbyte" option was independent of 3033mp. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Fw: Re: 308x Processors - was "Mainframe articles"
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Anne & Lynn Wheeler Sent: Tuesday, May 12, 2009 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Fw: Re: 308x Processors - was "Mainframe articles" 3033 and 3081 in 370 mode were 24bit (16mbyte) addressing (real & virtual). Didn't the 30xx machines have 26 bit addressing (the "3033 mode") when operating in S/370 mode? Starting with the 3033MP? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Fw: Re: 308x Processors - was "Mainframe articles"
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. patrick.falco...@verizon.net (Patrick Falcone) writes: > Correction they were 3081K 32's, one of the other posts jolted my > memory back into focus. Sorry for the drift. re: http://www.garlic.com/~lynn/2009g.html#66 Mainframe articles http://www.garlic.com/~lynn/2009g.html#67 Mainframe articles http://www.garlic.com/~lynn/2009g.html#68 IT Infrastructure Slideshow: The IBM Mainframe: 50 Years of Big Iron Innovation http://www.garlic.com/~lynn/2009g.html#70 Mainframe articles 3033 and 3081 in 370 mode were 24bit (16mbyte) addressing (real & virtual). issue was that disk thruputs weren't keeping pace with the rest of the system infrastructure ... i.e. processing & memory performance was increasing faster than disk performance. I had started pontificating in the 70s about the growing performance mismatch. what was happening was that increasing amounts of electronic storage (starting with real memory on the processor and then disk controller cache) was being used to cache disk information to compensate for the increasing disk thruput bottleneck. this is referencing comparing 360/67 to 3081k (separated by almost 15 yrs) running similar (virtual machine) CMS workload ... and claiming that relative system disk thruput had declined by a factor of ten times in the period. http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door some disk division executives took some offense with the claims and assigned the division performance group to refute my statements. after a few weeks, the group came back and effectively said that I had slightly understated the problem. That study eventually turned into a SHARE (63) presentation (B874) recommending how to configure/manage disks to improve system thruput. old post with reference: http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?) in any case, it was starting to become a real issue in the 3033 time-frame. it was possible to configure vm clusters of 4341s with higher aggregate thruput than 3033 at a lower cost. furthermore, each 4341 could have 16mbytes (and six i/o channels) compared to 3033's with 16mbytes (and 16 i/o channels). to somewhat address/compensate ... there was a hardware hack to have 3033 configured with 32mbytes of real storage (even though the processor was restricted to both real & virtual 16mbytes addressing). the hack involved 1) using (31bit) IDALs to being able to do I/O for real addresses above 16mbyte "line" (most importantly being able to read/write pages above the line) 2) page table entry was defined as 16bits, 12bit page number (4096 4096byte pages or 16mbytes), 2 defined bits and 2 undefined bits. the two undefined bits were re-allocated for prepending to the page number allowing up to 16384 4096byte pages or up to 64mbytes real storage, but only max. of 16mbytes per virtual address space). ... lots of things would require virtual pages, that were above the (16mbyte) line to be brought into the first 16mbytes of real storage. initially there was a definition where the software would write the (above the line) virtual page out to disk and then read it back into real storage (below the line). I generated some example code that involved special virtual address space and fiddling the real page numbers in two page table entries ... allowing 4k of real storage above the line to be "copied/moved" to 4k of real storage below the line (avoiding having to write to disk and read back in). this hack (for real storage >16mbytes) was carried forward for 3081s operating in 370 (24bit, 16mbyte) addressing mode. a few past posts discussing (3033/3081) >16mbyte http://www.garlic.com/~lynn/2004o.html#59 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370 http://www.garlic.com/~lynn/2006w.html#23 Multiple mappings http://www.garlic.com/~lynn/2006y.html#9 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007b.html#34 Just another example of mainframe costs http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!) http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical http://www.garlic.com/~lynn/2009d.html#48 Mainframe Hall of Fame: 17 New Members Added and some number of past posts mentioning vm/4341 clusters http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005n.html#11 Code density and performance? http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core d
Fw: Re: 308x Processors - was "Mainframe articles"
Correction they were 3081K 32's, one of the other posts jolted my memory back into focus. Sorry for the drift. --- On Tue, 5/12/09, Patrick Falcone wrote: From: Patrick Falcone Subject: Re: 308x Processors - was "Mainframe articles" To: "IBM Mainframe Discussion List" Date: Tuesday, May 12, 2009, 1:59 PM We had 3081's at a time share back in the mid 80's. At one point we took 2 3081G's and had IBM put them together to form a 3084 Q64 w/PIF. --- On Tue, 5/12/09, Martin Packer wrote: From: Martin Packer Subject: 308x Processors - was "Mainframe articles" To: IBM-MAIN@bama.ua.edu Date: Tuesday, May 12, 2009, 9:39 AM 3083 was Uni, 3081 was Dyadic (2 -way Non-Partitionable), 3084 was Partitionable 4-way. Base and X models with almost unrememberable model letters. Interestingly, later on you could get a 1+1 2-way and a 2+1 3-way. The benefits of these were larger caches (as you got 2 of them). I'm not sure who bought these, though. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter ID: MartinPacker "They're figuring out that collaboration isn't a productivity hit, it makes them smarter." Sam Palmisano on BlogCentral, 26 November 2008 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html