george@vax2.ccs.cornell.edu (George R Boyce) (06/15/87)
In setting up a resource accounting system, I want to consider the feature of allowing a user to select a lower process priority, say 3 instead of the default 4, in exchange for being charged a lower rate. So two questions... 1) Will VMS schedule jobs at two priority levels "fairly" or will the lower priority jobs never get reasonable response? I know the answer depends heavily on what job mix we have, so I guess I want to know if anyone has set up their system to divide their users into two or more priority classes. (I'm running an 8500 with mostly student users, a few large SAS or MACSYMA users.) 2) Is their a way to set a process priority limit downward such that the user can't set it back? The documentation for SET PROCESS/PRIORITY and SYS$SETPRI seem to be misleading. It suggests that the user can't set the base priority higher than the existing base priority when in fact they can set it back to the former (uaf specified) value. It looks like I would have to poke around in a system data structure; does anyone know how to do it? Thanks. George Boyce, Academic Computing, Cornell University george@vax2.ccs.cornell.edu (128.84.252.100), george@crnlvax2.bitnet
carl@CITHEX.CALTECH.EDU.UUCP (06/19/87)
> 1) Will VMS schedule jobs at two priority levels "fairly" or will the lower > priority jobs never get reasonable response? I know the answer depends > heavily on what job mix we have, so I guess I want to know if anyone has > set up their system to divide their users into two or more priority > classes. (I'm running an 8500 with mostly student users, a few large SAS > or MACSYMA users.) What happens is that the computable process with the highest priority get the CPU. VMS gives temporary priority boosts for processes doing substantial amounts of I/O, and as I recall, your priority inches up VERY gradually if your process sits idle. For the most part, however, you can model the scheduling under VMS as follows: The processes with the highest base priority either run as though each is alone on the system (in the event they don't combine to use 100% of the CPU time), or they divide the CPU among themselves. If the latter, processes with lower base priorities don't run. If the former, the processes with the second highest base priority repeat the above, using whatever fraction of the CPU is left over from the first group, and so on. On CITHEX, we tend to use four priorities 1: This is for batch jobs that you want to defer payment for more than a month. Since the job isn't likely to finish for at least a month, you don't get billed for the first month's time until the end of the month after; 3: This if for normal batch jobs: you typically get a pretty fair amount of CPU time in off hours, and your job might actually do some work during business hours, but it won't get in the way of interactive users (unless of course it allocates both tape drives and continues to use both of them once an hour or so for a week and a half). 5: This is the interactive job priority level, as well as the priority level for batch jobs you're willing to bet will finish in less than a CPU minute. Nobody has a higher default base priority than this. 7: This is the priority the backup job runs at when the disk drives start making funny noises. I also use it for things like running ANALYZE/DISK/REPAIR on the system disk with the system up and running; since ANAL/DISK/REPA writelocks the volume (or at least the index file) it's dealing with, and since there are things (for example, the accounting and error-logging facilities, LOGINOUT, MAIL), and so on) that need to write to the system disk, it's easier on the users to give them virtually no CPU time for a few minutes than to allow them to slowly pile up in various resource wait states. > 2) Is their a way to set a process priority limit downward such that the > user can't set it back? The documentation for SET PROCESS/PRIORITY and > SYS$SETPRI seem to be misleading. It suggests that the user can't set the > base priority higher than the existing base priority when in fact they can > set it back to the former (uaf specified) value. It looks like I would > have to poke around in a system data structure; does anyone know how to do > it? Thanks. Well, one thing you might consider is running an image that: 1) Sets its priority down; 2) Creates a subprocess, either with $CREPRC or with LIB$SPAWN; 3) Waits for the subprocess to die; 4) Immediately logs out. This sort of thing works because, unless the parent process explicitly specifies a priority, the base priority of a given job is equal to the priority at which its parent was running at the time of its creation.
LEICHTER-JERRY@YALE.ARPA.UUCP (06/20/87)
... 1) Will VMS schedule jobs at two priority levels "fairly" or will the lower priority jobs never get reasonable response? ... This isn't easy to answer. Down at the bottom of it all, at any given moment, the runnable process with the highest priority will be run. So in this sense, the answer is no. However, there are two (well, three - more below) priori- ties associated with a job: Its base priority, and its current priority. When you set the priority of a process, you are (mainly) manipulating its base priority, which is the lowest the current priority will ever go. How- ever, all but CPU-bound jobs spend most of their time above their base prio- rity, since various events like I/O completion gain the process a boost. In principle, a priority 3 CPU-bound job will get no CPU time on any system with a fair number of users. In practice, unless the system is very heavily loaded, you'll tend to see short periods of time when, but chance, a couple of people are doing compilations (say) when the priority 3 job will be locked out, but you'll also see long intervals where the priority 3 job chugs away nicely. You can get a quick picture of how well those jobs will do by using MONITOR - any CPU time the priority 3 jobs manage to take from the system will come mainly from the NULL job. (That's not quite true, since a priority 3 job with a priority boost of 3 for an I/O completion will take time from any prio- rity 4 CPU bound job.) Just to make life a little more complex, VMS has a special facility, control- led by the PIXSCAN parameter in SYSGEN, which gives computable processes a special boost every once in a while. This mechanism is there to guarantee that even low priority, CPU-bound processes don't stall indefinately. (The problem with allowing them to is that they may be holding a lock on some resource, like a file, and thus stalling high-priority processes.) 2) Is their a way to set a process priority limit downward such that the user can't set it back? The documentation for SET PROCESS/PRIORITY and SYS$SETPRI seem to be misleading.... Prior to VMS V4, you could not (without ALTPRI) raise your process priority. In V4, processes gained a third priority field, the authorized base priority. You can now lower your priority, or raise it no higher than your authorized base priority (which is also the base priority LOGINOUT sets for you to begin with). Note that a base priority specified for a batch queue overrides any authorized base priority - you can't SUBMIT a job to a low-priority queue, then raise its priority to interactive level, either from within the batch job or from an interactive job. Either you are looking at old documentation, or there is new documentation out there that could use some fixup. Documentation SPR time? -- Jerry -------