Comentarios (6)

1 JimHorne ha hecho un comentario el Enlace permanente

I just read your blog on this and I found it interesting and informative. I do have a bone of contention with it. You said, “It’s probably fair to use normalized CPU…” I agree that there are a ton of machines where the normalization factor is 1 and for those machines it doesn’t matter. The problem is that it does matter on the small machines. Even a 2817-6xx has a normalization factor of 1.53. Smaller machines are even worse. A 2817-4xx is almost 5 to one. If someone has a 2817-401 with one zIIP, I don’t think they want a report that shows 6 engines in play. Not to blow my own horn (pun unintentional), but if you look at, you can see what I mean. This is a Share presentation I did last month in Orlando talking about reporting zIIPs and zAAPs on sub capacity processors. Confusion is easy; clarity is hard. <div>&nbsp;</div> I’m not trying to knock your post. As I said up top, I found it very interesting and informative. But I did want to point out that you may want to rethink your comment on whether reporting normalized numbers is okay or not. Management may start asking questions such as, “Where did those extra engines come from. I didn’t authorize them!” (Delivered in almost a shriek by my manager the first day we started reporting on our brand new subcapaity Development processor). <div>&nbsp;</div> Keep up the good work!

2 MartinPacker ha hecho un comentario el Enlace permanente

Thanks for your comment, Jim. I particularly liked slides 11 onwards in your presentation. I agree we need to keep straight what we're talking about so couching things in terms of engines is fraught. In my example the phrase "engine equivalent" more or less deals with it. The intention of the graph is to show where the work ends up. So, if a single zIIP did 4.8 engines' worth of work I think it should show that - for THIS graph. On other occasions we're talking about used engines or installed engines. Then we WOULDN'T want to normalise. One other thing: We're using - with R723NFFS and R723NFFI - hard coded numbers. Of course the reality is going to be a little different and a little variable. So we just need to be aware of this - but I think it's a nit.

3 Anton_Britz ha hecho un comentario el Enlace permanente

Feedback: <br /> a) "Much ado about" normally ends with the word "nothing" but I assume, you did not want the readers mind to go to that word <br /> b) Based on the CPU graph shown, I have to conclude the following : <br /> b.1 It's a conservative "All IBM" IT shop because they stop everything for the daily backups and have very little batch <br /> b.2 Not sure if they even needed the ZIIP because if they moved the "daily batch" to after hours, everything <br /> will work fine <div>&nbsp;</div> Note: Not sure why we have to sign on to the Developers Network, before we are allowed to comment but that is not your fault and when I finally "Submit", I get" : <div>&nbsp;</div> Unexpected Exception <br /> Blogs has encountered and logged an unexpected exception.

4 MartinPacker ha hecho un comentario el Enlace permanente

Hi Anton! Not sure why you had to sign up (but it is the rules of the house) but I'm glad you did! Use it well. :-) <div>&nbsp;</div> a) "Much Ado" rhymes with "CPU". :-) <div>&nbsp;</div> b.1 and b.2) Actually this is just the one service class period. The batch isn't shown. And nor are other service classes using zIIP or even GCP. So I'm not sure wherefrom you're commenting. Unless YOU were the customer and I've forgotten. :-)

5 6X87_Graham_Harris ha hecho un comentario el Enlace permanente

Martin, couple of points of consideration from recent observations: <br /> 1. Some vendor products actually check for the presence of zIIPs, before actually deciding to enable their zIIP-enabled code. In such cases, PROJECTCPU is of no use. This scenario probably isnt widespread, but it's 'out there'. <br /> 2. We have experienced some pretty heavy "zAAP on GP" recently, due to some RACF exits getting in the middle of some fairly intensive ICSF calls (1000s a second). Ordinarily, meaty "zAAP on GP" figures tend to signify that you perhaps would benefit from additional specialist engine[s] (especially when IFAHONORPRORITY is set to prevent overflow), but that is not always the case.

6 MartinPacker ha hecho un comentario el Enlace permanente

Hello Graham! Thanks for signing up and for commenting! <div>&nbsp;</div> On 1. That seems to me a bizarre practice - and counterproductive for THEM: Surely they want to show their "plays nice with specialty engines" thing off in the best possible light? :-) <div>&nbsp;</div> On 2. I would expect JNI (and this is what I perceive at least SOME of the SAF stuff to be) to be in the "GCP_on_GCP" category. Actually, as we all know, there is no synchronous force onto GCP (nor the converse) so SOME will flow "laggedly". (And thank goodness there ISN'T else we'd be switching engine pools more frequently than we do.) If you see lots of "zIIP_on_GCP" (or the zAAP analogue) I'd expect to see "Delay_for_zIIP" high. If both "D_on_z" and "Delay_for_GCP" are high I think you're between a rock and a hard place. :-) :-( <div>&nbsp;</div> By the way, I'm aware of your situation: Lennie Dymoke-Bradshaw and I discussed the technical guts at length last week. It's an "interesting" :-) technical case. <div>&nbsp;</div> Thanks again for commenting here.