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 <cblaic...@syncsort.com> 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: cblaic...@syncsort.com > > 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Hunkeler > Sent: Friday, June 8, 2018 3:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ________________________________ > > > > ATTENTION: ----- > > The information contained in this message (including any files transmitted > with this message) may contain proprietary, trade secret or other > confidential and/or legally privileged information. Any pricing information > contained in this message or in any files transmitted with this message is > always confidential and cannot be shared with any third parties without prior > written approval from Syncsort. This message is intended to be read only by > the individual or entity to whom it is addressed or by their designee. If the > reader of this message is not the intended recipient, you are on notice that > any use, disclosure, copying or distribution of this message, in any form, is > strictly prohibited. If you have received this message in error, please > immediately notify the sender and/or Syncsort and destroy all copies of this > message in your possession, custody or control. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
