CPU Useage

[Guest.Visitor]

Tim,

Think about it. An interactive job only needs cpu cycles when a function key is entered; most of the time the job is waiting for input. Whereas a batch job should never be waiting - thus the differences in priorities, we would always want our screens to return to us as soon as possible and let the batch jobs run whenever they can.

Bill

Q: What determines how much CPU a job is allocated? I know the answer will not be as simple as the question. lol)

[tim.shafar@fiserv.com]

CPU Useage

I understand why interactive is set to a priority of 20 and batch is set to a priority of 50. What I don't understand is what determines how much CPU each is given to each job. I thought that the 20 level jobs would be given more CPU but that is not always true. Is there a set of docs that explain how CPU resources are given?

[cwscholbe@dstsystems.com]

CPU Useage

It depends on what the interactive job is doing. If it is doing a lot of disk I/O then it has to wait on the databse to deliver the record(s). The jobs timeslice will effect how long the job has the CPU once it gets it. All other things being equal the Priority 20 jobs will get serviced faster than Priority 50 jobs.

[tim.shafar@fiserv.com]

CPU Useage

Q: What determines how much CPU a job is allocated? I know the answer will not be as simple as the question. lol) I was using WRKACTJOB the other day and I noticed that some batch jobs were using more CPU than the interactive jobs. I had just always thought of the job priority (20 for interactive 50 for batch) as also determining how much CPU is used. I was obviously wrong! Then I started wondering what does determine the amount of CPU that is allocated to a job? Does anyone have an answer or a direction for some good documentation? Thanks in advance. Tim

[Guest.Visitor]

CPU Useage

Tim, the level 20 jobs are effectively given as much as they want to take. That's why it's generally a bad idea to run a batch program interactively. Because they spend most of their time waiting for a human being to do something interactive jobs take less than batch ones although they're on a higher prioriry. When OS/400 gives control of the CPU to a job it doesn't say "OK, you get 10%" it just says "here you go". The job itself determines when to give it back by saying "here's your screen, fill it in and press Enter" or "get me the next customer record". These requests are handled by OS/400 which then looks at its queue of jobs clamouring for the CPU and allocates it to the top one. The queue itself is ordered mainly by the RUNPTY of the jobs. It's actually a "bit" more complicated than that. For a start the jobs and the OS don't really chat to each other in English, and there are also timeslices, pools and the concept of ineligibility to keep the whole thing running sweetly and give the illusion that all the jobs are running continuously; but it sometimes helps to think in these terms. You can certainly get a better idea of what would happen if you let a CPU hog continually barge to the front of the queue or made a CPU efficient one always stand at the back of the line. You can also visualise how the OS has a harder time keeping everyone happy when the total CPU utilisation gets high. The Work Management Guide (SC41-5306) is the one to read for a rather more formal explanation. :-) Dave...