Re: CF LPAR MIPS Utilisation
On Mon, 7 Dec 2009 09:48:30 -0500, Scott Rowe wrote: >In my experience, GRS-Star with shared CP CFs is still significantly faster >(at least one order of magnitude) than GRS Ring using XCF. For the group's sake, I should have made the "YMMV" disclaimer. Our N.A. systems fared much better with Star than our European systems, but the configurations, workloads and constraints are quite different. >Also, the purpose for the extra CF can be used to upgrade CF code without a Sysplex outage. OK, ya got me. We are spoiled with a second CEC... > I guess it's also remotely possible that a CF code fault could cause a CF failure, though I have yet to see this. I keep a second CF running for this purpose, though I don't currently have any active structures in it. Maybe so in the midst of a CF code upgrade (planned outage), else a code fault on CF1 seems very likely to recur on CF2 in very short order. Any sort of unrecoverable physical failure would most likely throw machine casters up, rendering the second CF moot. Regards, Art Gutowski Ford Motor Company -- 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
Re: CF LPAR MIPS Utilisation
Art, In my experience, GRS-Star with shared CP CFs is still significantly faster (at least one order of magnitude) than GRS Ring using XCF. Also, the purpose for the extra CF can be used to upgrade CF code without a Sysplex outage. I guess it's also remotely possible that a CF code fault could cause a CF failure, though I have yet to see this. I keep a second CF running for this purpose, though I don't currently have any active structures in it. Scott >>> Arthur Gutowski 12/7/2009 9:25 AM >>> I also don't see which LPAR's are part of the Sysplex, and which are not. Dynamic Dispatch with a CF LPAR is not so much a matter of utilization, but as Scott suggests, getting the CPU when the CF needs it. We have found that DynDisp dramatically increases ISGLOCK response times (at least one order of magnitude) - and we have characterized CF engines. I cannot imagine how much worse this would be if we had to share with MVS images, too. IMHO, if A and B are the only ones in the Sysplex, the parallel sysplex does not give you significant advantage in and of itself in this configuration, unless of course, you have it for pricing considerations. Yes, GRS Star (parallel sysplex required) does perform better than Ring, even in a two-system complex, but without dedicated CF engines, my gut tells me you are losing whatever ground Star gives you. If A, B, C and D are all in it together, then IMHO, seriously consider funding and characterizing an ICF CP. Also, if they are, and since you are on a single footprint, I do not see the advantage of two CF LPARs for a single complex. If an internal CF goes down, it's either because your Operators need to be more astute, or there is a serious hardware problem, which probably means the whole machine is down. When our European counterparts tried to implement Star a few years back, they found this out empirically, also notwithstanding the added CPU demand buried their already-taxed z990. FWIW, Art Gutowski Ford Motor Company On Fri, 4 Dec 2009 14:33:18 -0500, Scott Rowe wrote: >Certainly, SYSA can take unused cycles, they are distributed according to weights. What you haven't said is what mode your CFs are running in, so I will assume the are dynamically dispatched. The thing you need to be very careful about here is that the CF partitions can get the cycles they need when they need them. According to your calculations, your CF partitions are promised 100 and 36 MIPS respectively - but is that enough? I prefer to over- weight CFs that run on shared CPs, since it helps ensure that the CF has access to the CPU when it needs it. If there are many CF requests and not enough available cycles to service them you could get in trouble quickly. > John Mitchelle 12/4/2009 11:57 AM >>> >Hi, > >I have 936 MIPS processor Z02-2096 z9BC > >I have 4 LPARS and 2 CF LPARs > >SYSA (Prod) > >SYSB (Dev) > >SYSC (Test) > >SYSD (Maint) > >SYCF1 > >SYCF2 > >Both CPU Engines are online across all LPAR's. > >Wts are in such a way that MIPS Allocation are > >650 for SYSA > >50 for SYSB > >50 for SYSC > >50 for SYSD > >100 MIPS for SYCF1 and > >36 MIPS for SYCF2 , > > >SYSA is UNCAPPED and SYSB, SYSC and SYSD are CAPPED. > >Recently we are having issues related to MIPS capacity. > >I am aware that in case SYSA needs more capacity then it can take from >SYSB,SYSC,SYSD if available. > >However, was wondering whether system will allow to take MIPS from >Coupling Facility LPAR's as well or not if available ? > >These are the structures in use for CF > >ISGLOCK >IXCXCF1 >IXCXCF2 > >Is there any advantage in getting rid of these coupling facility ? >Will that give us comfort ofhaving these additional MIPS ? -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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.
Re: CF LPAR MIPS Utilisation
I also don't see which LPAR's are part of the Sysplex, and which are not. Dynamic Dispatch with a CF LPAR is not so much a matter of utilization, but as Scott suggests, getting the CPU when the CF needs it. We have found that DynDisp dramatically increases ISGLOCK response times (at least one order of magnitude) - and we have characterized CF engines. I cannot imagine how much worse this would be if we had to share with MVS images, too. IMHO, if A and B are the only ones in the Sysplex, the parallel sysplex does not give you significant advantage in and of itself in this configuration, unless of course, you have it for pricing considerations. Yes, GRS Star (parallel sysplex required) does perform better than Ring, even in a two-system complex, but without dedicated CF engines, my gut tells me you are losing whatever ground Star gives you. If A, B, C and D are all in it together, then IMHO, seriously consider funding and characterizing an ICF CP. Also, if they are, and since you are on a single footprint, I do not see the advantage of two CF LPARs for a single complex. If an internal CF goes down, it's either because your Operators need to be more astute, or there is a serious hardware problem, which probably means the whole machine is down. When our European counterparts tried to implement Star a few years back, they found this out empirically, also notwithstanding the added CPU demand buried their already-taxed z990. FWIW, Art Gutowski Ford Motor Company On Fri, 4 Dec 2009 14:33:18 -0500, Scott Rowe wrote: >Certainly, SYSA can take unused cycles, they are distributed according to weights. What you haven't said is what mode your CFs are running in, so I will assume the are dynamically dispatched. The thing you need to be very careful about here is that the CF partitions can get the cycles they need when they need them. According to your calculations, your CF partitions are promised 100 and 36 MIPS respectively - but is that enough? I prefer to over- weight CFs that run on shared CPs, since it helps ensure that the CF has access to the CPU when it needs it. If there are many CF requests and not enough available cycles to service them you could get in trouble quickly. > John Mitchelle 12/4/2009 11:57 AM >>> >Hi, > >I have 936 MIPS processor Z02-2096 z9BC > >I have 4 LPARS and 2 CF LPARs > >SYSA (Prod) > >SYSB (Dev) > >SYSC (Test) > >SYSD (Maint) > >SYCF1 > >SYCF2 > >Both CPU Engines are online across all LPAR's. > >Wts are in such a way that MIPS Allocation are > >650 for SYSA > >50 for SYSB > >50 for SYSC > >50 for SYSD > >100 MIPS for SYCF1 and > >36 MIPS for SYCF2 , > > >SYSA is UNCAPPED and SYSB, SYSC and SYSD are CAPPED. > >Recently we are having issues related to MIPS capacity. > >I am aware that in case SYSA needs more capacity then it can take from >SYSB,SYSC,SYSD if available. > >However, was wondering whether system will allow to take MIPS from >Coupling Facility LPAR's as well or not if available ? > >These are the structures in use for CF > >ISGLOCK >IXCXCF1 >IXCXCF2 > >Is there any advantage in getting rid of these coupling facility ? >Will that give us comfort ofhaving these additional MIPS ? -- 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
Re: CF LPAR MIPS Utilisation
Certainly, SYSA can take unused cycles, they are distributed according to weights. What you haven't said is what mode your CFs are running in, so I will assume the are dynamically dispatched. The thing you need to be very careful about here is that the CF partitions can get the cycles they need when they need them. According to your calculations, your CF partitions are promised 100 and 36 MIPS respectively - but is that enough? I prefer to over-weight CFs that run on shared CPs, since it helps ensure that the CF has access to the CPU when it needs it. If there are many CF requests and not enough available cycles to service them you could get in trouble quickly. >>> John Mitchelle 12/4/2009 11:57 AM >>> Hi, I have 936 MIPS processor Z02-2096 z9BC I have 4 LPARS and 2 CF LPARs SYSA (Prod) SYSB (Dev) SYSC (Test) SYSD (Maint) SYCF1 SYCF2 Both CPU Engines are online across all LPAR's. Wts are in such a way that MIPS Allocation are 650 for SYSA 50 for SYSB 50 for SYSC 50 for SYSD 100 MIPS for SYCF1 and 36 MIPS for SYCF2 , SYSA is UNCAPPED and SYSB, SYSC and SYSD are CAPPED. Recently we are having issues related to MIPS capacity. I am aware that in case SYSA needs more capacity then it can take from SYSB,SYSC,SYSD if available. However, was wondering whether system will allow to take MIPS from Coupling Facility LPAR's as well or not if available ? These are the structures in use for CF ISGLOCK IXCXCF1 IXCXCF2 Is there any advantage in getting rid of these coupling facility ? Will that give us comfort ofhaving these additional MIPS ? John -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: CF LPAR MIPS Utilisation
Yes. Parallel Sysplex. No ICF Engines. During "As-is" migration , Legacy system migrated from 2 z900 Processors (which were in sysplex) to z9BC. John On Fri, Dec 4, 2009 at 5:13 PM, Field, Alan C. wrote: > John, > > The cpus defined as CF (specialty) engines ONLY run the CF code, so > there is no gain to you SYSA/B/C/D lpars. > > Are you running a parallel sysplex? > > Also I think the GP engines are in one pool, and the CF engines in > another so your weights aren't giving you the MIPs you think. > > Alan > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of John Mitchelle > Sent: Friday, December 04, 2009 10:57 > To: IBM-MAIN@bama.ua.edu > Subject: CF LPAR MIPS Utilisation > > Hi, > > I have 936 MIPS processor Z02-2096 z9BC > > I have 4 LPARS and 2 CF LPARs > > SYSA (Prod) > > SYSB (Dev) > > SYSC (Test) > > SYSD (Maint) > > SYCF1 > > SYCF2 > > Both CPU Engines are online across all LPAR's. > > Wts are in such a way that MIPS Allocation are > > 650 for SYSA > > 50 for SYSB > > 50 for SYSC > > 50 for SYSD > > 100 MIPS for SYCF1 and > > 36 MIPS for SYCF2 , > > > SYSA is UNCAPPED and SYSB, SYSC and SYSD are CAPPED. > > Recently we are having issues related to MIPS capacity. > > I am aware that in case SYSA needs more capacity then it can take from > SYSB,SYSC,SYSD if available. > > However, was wondering whether system will allow to take MIPS from > Coupling Facility LPAR's as well or not if available ? > > These are the structures in use for CF > > ISGLOCK > IXCXCF1 > IXCXCF2 > > Is there any advantage in getting rid of these coupling facility ? > Will that give us comfort ofhaving these additional MIPS ? > > > John > > -- > 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
Re: CF LPAR MIPS Utilisation
John, The cpus defined as CF (specialty) engines ONLY run the CF code, so there is no gain to you SYSA/B/C/D lpars. Are you running a parallel sysplex? Also I think the GP engines are in one pool, and the CF engines in another so your weights aren't giving you the MIPs you think. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mitchelle Sent: Friday, December 04, 2009 10:57 To: IBM-MAIN@bama.ua.edu Subject: CF LPAR MIPS Utilisation Hi, I have 936 MIPS processor Z02-2096 z9BC I have 4 LPARS and 2 CF LPARs SYSA (Prod) SYSB (Dev) SYSC (Test) SYSD (Maint) SYCF1 SYCF2 Both CPU Engines are online across all LPAR's. Wts are in such a way that MIPS Allocation are 650 for SYSA 50 for SYSB 50 for SYSC 50 for SYSD 100 MIPS for SYCF1 and 36 MIPS for SYCF2 , SYSA is UNCAPPED and SYSB, SYSC and SYSD are CAPPED. Recently we are having issues related to MIPS capacity. I am aware that in case SYSA needs more capacity then it can take from SYSB,SYSC,SYSD if available. However, was wondering whether system will allow to take MIPS from Coupling Facility LPAR's as well or not if available ? These are the structures in use for CF ISGLOCK IXCXCF1 IXCXCF2 Is there any advantage in getting rid of these coupling facility ? Will that give us comfort ofhaving these additional MIPS ? John -- 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