hobbit@AIM.RUTGERS.EDU ("*Hobbit*") (12/23/87)
Someone may have dealt with this before -- is there a circumstance wherein the base priority of a batch queue is ignored, and a job submitted thereto runs at the normal UAF base priority of the user? Or something in between? With a batch queue /baspri=3 and different users whose default priorities are 5, I've seen jobs run at 4 and 5 but never 3. This is microvms 4.1, so it may just be an old bug that I never noticed. _H* ------
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (12/23/87)
> Someone may have dealt with this before -- is there a circumstance wherein > the base priority of a batch queue is ignored, and a job submitted thereto > runs at the normal UAF base priority of the user? Or something in between? > With a batch queue /baspri=3 and different users whose default priorities > are 5, I've seen jobs run at 4 and 5 but never 3. > > This is microvms 4.1, so it may just be an old bug that I never noticed. Sounds like you've generally got at least one computable job running at a base priority greater than three. As a job sits idle, VMS slowly raises its current priority (as I understand it, this is to prevent a low-priority job from permanently locking a resource due to inability to get enough CPU time to release it). The first boost comes fairly quickly, which means that if your system has an executable job with higher base priority, your low-priority jobs will nearly always have a current priority higher than their base priority. Once the current priority of a job reaches the base priority of the higher-priority jobs, the job gets some CPU time and its priority falls back to the base priority, where it soon gets a priority boost again.