Martin, Yeah, what he said :-)
Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > Anne & Lynn Wheeler > Sent: Wednesday, April 20, 2011 7:05 AM > To: [email protected] > Subject: Re: [IBM-MAIN] Dyadic vs AP: Was "CPU utilization/forecasting" > > [email protected] (Martin Packer) writes: > > Ron, care to remind us of the modelling difference? It's been a while. :-) > > 360 & 370 dual-processors shared memory but each processors had its own > dedicated channels ... and the configuration could be split and run as > two separate processors. > > 370AP ... was a two processor configuration where only one of the > processors had channels ... the second processor purely did compute > bound work. it was less expensive and could be applicable to more > compute intensive work. it was also applicable in large loosely-coupled > environment when running out of controler interfaces for all the > channels ... aka with four channel dasd controller with string-switch > (for each disk connected to two controllers) ... giving 8 channel paths > to each disk ... it would be possible to have eight two-processor > complexes (for 16 processors total). > > DYADIC was term introduced with 3081 ... where it wasn't possible to > split the configuration and run as two separate independent processors > (wanted to draw distinction between past 360/370 multiprocessor that > could be split and run independently and the 3081 which couldn't be > split). 3081 had both processors being able to address all channels and > also introducted 31-bit virtual addressing. > > trivia ... 360/67 had 32-bit virtual addressing, all processors could > address all channels *AND* configuration could be split into independent > running single processors. 360/67 was desgined for four-processor > configuration, but I know of only a couple three-processor configuration > that were actually built (and no four processor configurations) ... all > the rest multiprocessor configurations were simply two-processors. > > other 3081 trivia ... 370 (& 3081) dual-processor slowed machine cycle > down by ten percent to help with multiprocessor processor cache > interaction ... so a two-processor machine started out at only 1.8 times > a single processor machine. Multiprocessor software and actual > multiprocessor cache interactions tended to add additional overhead so > that dual-processor tended to have 1.4-1.5 times the throughput of > single processor. > > 3081 originally never intended to have single processor version ... but > largely because ACP/TPF didn't have multi-processor support, there was > eventually a 3083 introduced. The easiest would have been to remove 2nd > processor from the 3081 box ... however, processor0 was at the top of > the box and the 2nd processor1 was in the middle of the box ... which > would have left the box dangerously top heavy. > > eventually 3083 was introduced with single processor ... it was possible > to turn-off the ten percent machine cycle slowdown (done for > multiprocessor cache interaction) ... and eventually there was a special > microcode load tuned for the ACP/TPF workloads that tended to be more > I/O intensive. > > in the late 70s, the consolidated internal online US HONE operation (US > HONE and the various HONE clones providied online world-wide sales & > marketing support) was the largest single-system operation in the world. > It was large loosely-coupled operation with "AP" multiprocessors ... > most of the sales&marketing applications were implemented in APL and the > workload was extremely compute intensive. I provided them with their > initial multiprocessor support ... highly optimized kernel > multiprocessor pathlengths and games played to improve cache hit > locality ... could get slightly better than twice single processor (i.e. > cache games offset the machine running at only 1.8times single processor > and the optimized multiprocessor pathlengths). misc. past posts > mentioning multiprocessor support (&/or compare&swap instruction) > http://www.garlic.com/~lynn/subtopic.html#smp > > as mentioined in previous post > http://www.garlic.com/~lynn/2011f.html#41 CPU utilization/forecasting > > the science center had done a lot of the early work in performance > monitoring, reporting, simulation, modeling, workload&configuration > profiling ... that evolves into capacity planning. misc. past posts > mentioning science center > http://www.garlic.com/~lynn/subtopic.html#545tech > > One of the APL models was packaged in the mid-70s as the "performance > predictor" on HONE ... so that sales&marketing could take customer > workload&configuration specification and ask "what-if" questions about > workload &/or configuration changes. another version of the "model" was > modified and used to decide (online) workload balancing across the > loosely-coupled configuration (which processor complex would new logon > be directed to, part of single-system operation). > misc. past posts mentioning HONE > http://www.garlic.com/~lynn/subtopic.html#hone > > -- > virtualization experience starting Jan1968, online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
