W dniu 2011-04-17 01:11, Gerhard Adam pisze:
Well, I disagree with such definition. IMHO CPU busy is "pattern" of
NOPs (No OPeration) and "usable" instructions. 1% busy simply means that
99% of cycles were filled with NOP, and only 1% of cycles were other
instructione were executed.
You can disagree with it all you like, but a job that is dispatched on a CPU
is of no interest from a performance perspective. What matters is how long
dispatchable work has to wait in the queue.
You assumed queue existence. Good assumption for z/OS and most other
systems, but has no meaning from CPU perspective.
HOWEVER, this depends explicitly on the relative
dispatching priority of the work, so the 80% utilization would only be
relevant to the lowest priority work in the system.
In fact dispatching priority denies you statement above or at least
distorts it.
No, because it means that any work at DP=255 will not be delayed by lower
priority work (beyond that work completing its dispatch interval).
Therefore it is completely erroneous to assume that work at that high
dispatching priority "sees" the overall utilization of the processor. Its
dispatching priority ensures that only competitors at the same dispatching
priority are relevant in establishing delays. A job at DP=245 will have to
compete with all units of work at higher dispatching priorities, and
therefore a higher utilization represents a higher probability of such lower
priority work being subject to queuing delays.
Again, there are systems, where there are no such thing like DP (or they
are more or less similar), but those systems still have to do with CPU
and their workload. For example I believe there were no such gismo in
MS-DOS, but DOS used processor and the processor had some utilization,
usually between 0 and 100%.
The overall CPU utilization represents the ongoing demand,
while the relative utilization at each dispatching priority represents the
level of competition experienced by the workload.
You can agree with the above as CPU busy definition, you ca even assume
z/OS constructs in general CPU-computer world ;-)
--
Radoslaw Skorupka
Lodz, Poland
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, e-mail: [email protected]
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych.
----------------------------------------------------------------------
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
