Having just written a lengthy update, the new web interface tells me that 'a server error occured' - all is gone. Next try.
>Your graphic based on the number of engines online is a pretty clever idea. >But I was thinking that the number of online engines was just one way to >implement CoD. Do I misunderstand? >Plus, as others have pointed out, clock seconds don't give us a feel for how >well that work would run on another type of >box. I'd go with a graphic >plotting MSU's consumed with one or more reference lines for the running CPU >as well as the >next two larger boxes. >Meaningful? Perhaps not. But perhaps the least meaningless :-) At least one >can compare two numbers and get a >rough feel, which should be good enough to >produce a reasonable budget. And that's all managment really wants, I >think. 'Capacity Management' in this installation is done by manually varying logical cps on- and offline at predetermined times and by shifting lpar weights when someone complains. Who gets more mostly depends on who complains loudest. 'Capacity Planning'? What's that? Back in March when Fukushima blew up and the above methods were not sufficient to meet the deadlines, for the first time we employed CoD. First we got one more physical cp (which I think was enough to meet the deadlines), but management did another CoD going to not-slowed-down cps, and adding one more. For 24 hours we had almost double of our usual capacity (with the accompanying bills from the software vendors). At that point management wanted to *see* when we had added the physical cp, which of course is impossible when the usage values are normalized to 100%. 100% wasn't equal to 100% anymore, as the underlying reference had changed. Nobody else had an idea how to graphically present that, so I came up with the idea of using cpu seconds consumed. *Then* management wanted to know how much more than our regular capacity we had needed. I am sure once I show them any new grafic they will ask some new question that cannot be answered from what we have. And asking them to tell ! me *beforehand* what they need is also asking too much. I am usually expected to read minds. <rant off> With the 'capacity per engine' approach I can represent more cps. I don't think that would show if a cp doesn't run slowed down anymore. At that point in one cpu second 'more' can be done, so 1s is not equal to 1s anymore. And that is only the view of the whole box. I also have the added question how much 'capacity' is available per lpar. Currently all I see is a 100% percent value that assumes that all logical cps will always immediately run on a physical cp. (And logical-to-physical ratio is way beyond any recommendation). So 100% cannot be achieved. But where to draw the line? It is going to get worse on the new box. We will have fewer physical cps. We also have at least one more lpar than physical cps per box. On one box we have x physical cps, and two lpars with all x logical cps. Plus some more lpars with fewer logical cps. IBM wanted us to use Hiperdispatch, and I vehemently objected. Given my notoriety, IBM eventually agreed that Hiperdispatch will be a bad idea here. :-) I will mull this over some more. I might have to go the service unit approach, but only if that will also solve the question how much capacity can be achieved on any one lpar that is overspecifed (dare I call it 'misconfigured'?) the way it is. Any thoughts are welcome. :-) Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
