[email protected] (Paul Gilmartin) writes: > Not in that article, but I see: > http://www.computerhistory.org/revolution/mainframe-computers/7/161 > > ... — six computers with a performance range of 50 to 1, ... > > Did they follow Grosch's Law: "There is a fundamental rule, which I modestly > call Grosch's law, giving added economy only as the square root of the > increase in speed ..." > > What's the "performance range" of currently marketed z models? > > (Just pondering the availability of entry-level systems.) > > -- gil
re: http://www.garlic.com/~lynn/2017d.html#44 360 announce day there tends to be "knee of the (technology/performance, price/performance) curve". These days you see it in the large cloud operations with multiple megadatacenters each with hundreds of thousands of systems ... they tend to very carefully optimize ... price/performance, power/performance, cooling/performance, MTBF, etc (system costs have so drastically dropped that power&cooling is increasingly major factor). as undergraduate in the 60s, I rewrote a lot of CP/67-cms, improving various pathlengths by factor of 100 times, how virtual paging working, ordered seek queueing and multiple i/o requests per sio ... with careful rotational ordering, and dynamic adaptive resource management. other trivia, old post with part of SHARE presentation I made as undergraduate on the pathlength work running OS/360 under CP/67 http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 it also mentions that I manually took apart OS/360 stage-2 sysgen and reordered it to carefully place files and PDS members improving seek access and rotation ... getting nearly three times improvement in (bare machine) throughput. Problem was that several months of PTFs could upset the careful PDS member placement ... and I might have to redo sysgen build ... before next release came along. after joining science center I continued to work on CP/67-CMS ... although a lot of the stuff was dropped in the simplification morph into VM370. During the Future System period, http://www.garlic.com/~lynn/submain.html#futuresys I continued to work on CP67 (including hobby of providing production systems for internal datacenters) and periodically ridiculing the FS activity. Old email about migrating a bunch of stuff from cp/67 to VM370 ... and providing production "CSC/VM" systems for internal datacenters. http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 For whatever reason there was deal cut with AT&T Longlines to make a snapshot copy of CSC/VM (along with with source) available to them. Nearly a decade later, the IBM national account rep for AT&T tracked me down and were still running the same CSC/VM code but had regularly moved it to latest IBM mainframe ... same code continued to run for a nearly a decade across models with performance range of 100. The "problem" was the CSC/VM that longlines had picked up was slightly before the cp/67 SMP support had been moved to CSC/VM. This was in the 3081 period ... where IBM hadn't planned on offering any more single processor models ... while the clone makers still offerring single processor machines (and CSC/VM was now running on quite a few large IBM mainframes inside AT&T). The problem was similar to that facing the ACP/TPF customers ... because ACP/TPF also didn't have SMP support. In any case, the account rep wanted to see if I would help migrate from 70s CSC/VM to a more current vm370 with SMP support. past posts mentioning SMP &/or compare-and-swap instruction http://www.garlic.com/~lynn/subtopic.html#smp other triva: 23Jun1969 unbundling announcement incldued starting to charge for (application) software, but they managed to make the case that operating system software should still be free http://www.garlic.com/~lynn/submain.html#unbundling the lack of 370 offerrings during the FS period is credited with giving the clone makers market foothold. With the demise of FS, there was mad rush to get 370 stuff (hardware & software) back into the product pipelines. There was also a decision to transition to also start charging for kernel/operating system software ... and portion of CSC/VM ... the dynamic adaptive resource manager ... was selected to be the guinea pig. http://www.garlic.com/~lynn/subtopic.html#fairshare Some guy in corporate, said he wouldn't sign-off on release because it didn't have any tuning parameters ... and everybody knew that the current state of the art was (manual) tuning parameters. At the time, MVS had enormous number of manual tuning parameters and extensive SHARE presentations on enormous number of benchmarks involving large variety of tuning parameter combinations. The other characteristic was it had a boot/ipl table of processor model numbers and approx. processor rate (I dynamically determined the values). In any case I had to add some manual tuning parameters, extensively document forumulas (company was deaf to dynamic adaptive resource management). However I managed to pull a joke. In operations research ... there is something about degrees of freedom ... and it turns out that the manual tuning values had less degrees of freedom than the dynamic adaptive resource management ... and the dynamic adaptive resource management could compensate for any manual setting. People could actually see the code corresponded to the documented formulas taking into account the manual tuning parameters ... only if you assumed things were purely static. Almost nobody realized that in a dynamic environment, in the calculations, the dynamic adaptive was offseting the manual values. -- 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: INFO IBM-MAIN
