That is consistent with Ed Jaffe's explanation of there being a short-period (4µsec), periodic millicode CPU loop to eat up the excess, un-bought CP capacity. That would have the effect of making a program running on a subcapacity CP run slower and longer with a lower average instructions/sec rate than on a full speed CP, even though individual instructions when doing productive work would run at full clock speed.
With a reduced effective execution rate on a subcapacity CP, the balance between CPU and I/O speeds is shifted, and one would expect reduced I/O wait time when running on the effectively-slower CP. Joel C. Ewing On 06/08/2018 05:26 PM, Mike Schwab wrote: > I have seen press stories where Full speed CPs see a lot of wait time > (waiting for data, interrupt, etc.), where slower CPs credit the > delays to the reduced capacity so they will see little to no wait > time. > On Fri, Jun 8, 2018 at 4:48 PM Christopher Y. Blaicher > <[email protected]> wrote: >> I wish Peter Relson would comment on this so we all can get the straight >> answer, but he may not be able to. >> >> From what little I know and most that I summarize and guess at, it seems the >> following to be what is happening. >> >> First of all, the dispatcher code for ZIIP processing is not the same as the >> GP dispatcher. >> >> I think the queuing process is basically FIFO and once unit of work is >> dispatched, it runs to the end or a program break point happens. A program >> break point could be some form of PAUSE or a IEAVXTSW wait. >> >> Some of this dispatcher design by IBM could be based on the assumption that >> all the work is SRB and will be high priority work and of short duration. >> >> There is the ZIIPAWMT parameter in IEAOPTxx which affects how often idle >> zIIPs get woken up to see if there is work. This has two effects. A unit >> of work put on the zIIP queue has to wait up to that long to get dispatched >> on a zIIP, or if at the end of that interval all zIIPs are busy, only then >> will the unit of work be dispatched on a GP. To be fair, when a zIIP >> completes a unit of work, it checks for more work to process, so not >> everything waits a dispatch cycle. >> >> So what does this all mean? In a low activity environment, your mean time >> to dispatch is around half the ZIIPAWMT time. In a high activity >> environment it means the mean time to dispatch on a GP because all he zIIPs >> are busy is ZIIPAWMT. >> >> This starts to get into queuing theory, but if a single zIIP processor is >> over 30% busy, about 30% or more of the work to run on a zIIP will wind up >> waiting the ZIIPAWMT time and then get dispatched on a GP, thus adding the >> insult of delaying the processing of the work to the injury of running on a >> GP that can cost real money. >> >> If you add more zIIP engines, there is a greater chance of a unit of work >> ending on one of the engines and thus the work getting dispatched on a zIIP >> without waiting the full ZIIPAWMT. >> >> A reasonable set of indicators can be gotten from the SMF type 30 record. >> The SMF30_TIME_ON_ZIIP and SMF30_TIME_ZIIP_ON_CP are valuable indicators. >> >> If SMF30_TIME_ZIIP_ON_CP is 30% or more of SMF30_TIME_ON_ZIIP, then you >> probably need another zIIP engine. Because type 30 records are job centric, >> I would suggest using the SMF 30 SUBTYPE 2 and 3 records for all the jobs in >> a time interval and totaling the data. Using data from a single job or >> group of jobs may not provide a complete picture. Also, the 30% value >> mentioned maybe more or less than your environment can tolerate. YMMV, so >> only use it as a starting point. >> >> As I said, most of this is just a guess at what is happening with zIIP >> dispatching. None of this information has been validated and neither >> Syncsort or I are implying or stating any course of action a user should >> pursue. Each user must evaluate their own needs and requirements and make >> decisions based solely on their own research and evaluation of their >> circumstances. >> >> Chris Blaicher >> Technical Architect >> Mainframe Development >> P: 201-930-8234 | M: 512-627-3803 >> E: [email protected] >> >> Syncsort Incorporated >> 2 Blue Hill Plaza #1563 >> Pearl River, NY 10965 >> www.syncsort.com >> >> Data quality leader Trillium Software is now a part of Syncsort. >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Peter Hunkeler >> Sent: Friday, June 8, 2018 3:42 PM >> To: [email protected] >> Subject: AW: Re: Why are highly busy zIIPs worse than highly busy CPs? >> >>> How prevalent are installations today where the CPs run at top speed, in >>> other words at the same speed as zIIP engines? >> >> >> I haven't got the faintest idea. We do, but that doesn't matter for this >> discussion. I thought this is complex enough, so I take one part of >> complexity out first: Different speed engines. >> >> >> -- >> Peter Hunkeler >> >> >> -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
