>What has been occurring is that during the RMF interval, the 1st service class >will consume all available CPU and the 2nd will receive none. >A short time later, WLM will adjust the dispatching priority and the 2nd >service class will receive all available CPU, the first none.
This is an unfortunate artifact of the introduction of the WLM, over 10 years ago. Except for DISCRETIONARY, there is no longer Mean-Time-to-Wait. This means that for every priority, the lead job will run until it gives up the CPU, then the next, the next, and so on. It can cause problems if you have both CPU-Bound and I/O-Bound jobs at the same level. The I/O job will pop in, consume a little, pop out, and wait behind the CPU job. If there are a couple of CPU-Bound jobs in the Service Class, your PI's will look good, and the WLM will NOT help the I/O-Bound. The granularity is at the job/priority level, rather than the service class. I discussed this with IBM, 11 years ago, and even presented in (January 1999) as a WLM early experience presentation at CMG Canada. IBM's solution was to introduce a second period. My response was: 1. Where? You can't tell when you are going to have problems with CPU vs I/O-Bound jobs. And, 2. The limited resource with the WLM is active service classes/periods, so let's add more as a half-*ssed solution to an implementation error that IBM made over 12 years ago. They're not going to change it. - Too busy driving to stop for gas! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
