To correct one thing: Not all the work is high priority. Three examples:
1) DDF threads selected to be zIIP-eligible. 2) Java - via zAAP on zIIP. 3) System XML Cheers, Martin Sent from my iPad > On 8 Jun 2018, at 22:49, 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 > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN >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 [email protected] with the message: INFO IBM-MAIN
