In article <[log in to unmask]>, Gary Sielaff
<[log in to unmask]> writes
>When you "report" a group..... what does the cpu seconds signify
>exactly?   Yes, 'CPU SECONDS' is a good answer but what part
>of a normal transaction would this consist of?  In other words my
>boss says "They were connected for 2 hours but they only used
>14 cpu seconds, so out of that 2 hours they only did about one
>transaction, or lookup in this case."
>I am trying to explain that they were probably busy most of the
>2 hours.
>Am I clear as mud or what???????????/
>Anybody??????????
>Gary Sielaff
>
They had this much 'mill time', i.e.14 seconds actual use of the CPU,
in the 'wall time', i.e. 120 elapsed time minutes as given by the clock
on the wall..

On, say, a 64-user machine with 60 users working, there is only 1 CPU
second available for each of them in a 'wall' minute, else the machine
gets a bit behind... :-)

But the average user transaction, in a well-coded system, is likely to
use a vanishingly small amount of CPU time, even allowing for MPE and
subsystem overheads; a tiny slice of disk I/O time, as stuff is read
from and written to the disks; a more significant slice of network/comms
I/O time, as the transaction is painted onto and peeled off the user's
screen, and a large slice of 'think time', as the period during which
the app waits for the user to respond is rather misleadingly known.

I say 'misleadingly' as the picture conjured up is of the user gazing
idly at the screen and maybe adding or altering one character before
pressing Enter, if that. Whereas they could actually be inputting a
screenful of data at speeds Mavis Beacon would be proud of....

If your boss wants to know what productivity they were actually getting,
you need to record transaction statistics in your app. Or use
old-fashioned methods, such as asking the supervisor...

Of course, most CPU time gets eaten up by batch jobs, which even when
impeccably written, can gobble up those CPU seconds at a rate online
users can never hope to achieve, which is why MPE keeps batch jobs down
the priority list, only letting them in a slice at a time, and only when
the online users have relinquished the CPU...

A while ago, there was a very interesting discussion on what constituted
an efficient job; was it one which ran the CPU flat out, or maxed out on
disc I/O or what?

E.g., we could rewrite the app above that used 14 CPU seconds in 2 hours
to have used 28 CPU seconds instead, on the same tasks (easily), or to
have used 7 CPU seconds (maybe, and probably only with great
difficulty).

But it sounds like your boss would be more pleased with 28 seconds, and
that would definitely be wrong....

An efficient job, or app, is the one that runs consuming the least
resources, where the resources are CPU time, I/O time *and* (often
forgotten) programming time, amortised over the life of the job/app;
support time, ditto *and* (even more often forgotten) user time in
driving, or waiting for the output from, the job/app.

You can put costs on these, but these can be hard to obtain reliably, so
finding the minimum cost point is not always that easy. But a good
simplifier is to bundle everything but programming and support time into
elapsed time, and say how much elapsed time reduction over the life of
the app is worth how much programming effort up front.

Kind of: does this app (or this chunk of it) need to be a Ferrari - high
build cost, high maintenance, low elapsed time, or an Alero - a little
longer elapsed time, but significant savings in the other areas?

Of course, the equation changes all the time, as machine resources get
cheaper. So we now do things that are quick (in programming terms) and
'quick enough' (in machine terms) that would have been eye-wateringly
slow and expensive, even if possible, on older platforms. And no, I'm
not just thinking Winxxxx, I'm even thinking Classics.
--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris