We running on z10 with 16 processors (1264 MSUs), however our LPAR just has 2 logical processors with 40 MSUs.
Werner Kuehnel IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> schrieb am 29.01.2010 17:02:32: > Werner, > > I'm curious, how many CPU's? > > > --- On Fri, 1/29/10, Werner Kuehnel <werner.kueh...@mannheimer.de> wrote: > > > From: Werner Kuehnel <werner.kueh...@mannheimer.de> > Subject: Antwort: Re: Antwort: Re: WLM and TCPIP > To: IBM-MAIN@bama.ua.edu > Date: Friday, January 29, 2010, 2:30 PM > > > The "normal" delay is under 10%. I can't think of another address space > than TCPIP > to handle the PING. Probably OMPROUTE, but it's also defined as SYSSTC and > is > delayed for a much higher percentage than at normal times. > > Werner Kuehnel > > > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> schrieb am 29.01.2010 > 15:11:24: > > > Ignorant questions: > > Does TCPIP handle the Ping itself, so no other adress space is involved? > > What is the delay % under normal (good) response situations? > > > > Kees. > > > > "Werner Kuehnel" <werner.kueh...@mannheimer.de> wrote in message > > news:<ofe4dc5618.b4211958-onc12576ba.004c69dc-c12576ba.004d3...@mannheim > > er.de>... > > > Tried already to shift TCPIP into SYSTEM, but is not allowed. WLM can > > not > > > starve STCs defined in SYSSTC. Why does WLM not cut the processor for > > the > > > batch jobs which are defined DISCRETIONARY? > > > > > > Werner Kuehnel > > > > > > > > > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> schrieb am > > 29.01.2010 > > > 14:49:44: > > > > > > > Given the situation I would say, probably, NO. You *might* be able > > to > > > > move TCPIP to SYSTEM but ISTR some changes made a few releases back > > to > > > > force certain system critical tasks into IBM assigned SCLASSes. > > > > > > > > The problem is not the TCPIP is not high enough on the food chain, > > but > > > > that the food chain has been shortened when the soft cap kicks in. > > This > > > > is the most likely causes of CPU delay. > > > > > > > > Possible Performance improvements for TCPIP > > > > Segmentation Offload. Not sure of the current status. A long history > > of > > > > trys, retrys, and try agains. Check the archives. > > > > There are a couple of TCPIP performance Inoforamation APARS the also > > > > might help II11710, II11711, II11712. None of these "address" CPU > > > > directly, but the net effect will be to reduce the CPU overhead per > > byte > > > > when implemented. > > > > > > > > HTH, > > > > > > > > <snip> > > > > Our box is running at 90-100% under soft capping. > > > > TCPIP is defined with service class SYSSTC. > > > > When capping starts the PING response times explode from approx. > > 15ms to > > > > > > > > 400 - 1000ms. Looking with RMF3 delay monitor at TCPIP, it shows a > > delay > > > > > > > > up to 70% because of processor. > > > > SYSSTC is the highest service class I can assign, it runs with > > > > dispatching > > > > prio of FE. Nevertheless TCPIP is delayed at such a high degree. > > > > Is there anything I can do to improve the performance of TCPIP? > > > > </snip> > > > > > > > > > > ---------------------------------------------------------------------- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ********************************************************************** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee > > only. If you are not the addressee, you are notified that no part > > of the e-mail or any attachment may be disclosed, copied or > > distributed, and that any other action related to this e-mail or > > attachment is strictly prohibited, and may be unlawful. If you have > > received this e-mail by error, please notify the sender immediately > > by return e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > and/or its employees shall not be liable for the incorrect or > > incomplete transmission of this e-mail or any attachments, nor > > responsible for any delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > ********************************************************************** > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
