Hi Peter,

   The script should return the maximum number of jobs that a VO can run.  It's ok if this number changes, but it should not be adjusted to take into account the number of currently running jobs *of that VO*.  That statement is probably ambiguous so let me illustrate.

At Nikhef we use maui process caps on unix groups, so for example we may have group "patlas" (mapped to generic atlas proxies) limited to 1500 jobs.  What vomaxjobs should then print is 1500.  This is regardless of whether we have zero running ATLAS jobs, 450, 1500, or 1600.  the dynamic scheduler program prints "available slots" by taking the number printed by vomaxjobs, and subtracting from this the number of running jobs belonging to this unix group.  It also accounts for the total number of slots free in the LRMS (not taking into account standing reservations!) So for VO "atlas" if we have

max processes : 1500
running atlas jobs : 623

then vomaxjobs should print 1500 for atlas, running jobs printed by the dynamic scheduler will be 623, and available slots printed will be 877.

It may be that because of some standing reservation, you realize that atlas will not be able to run 1500 jobs but only 700 in total, it's then fine to print that number.  It's helpful to remember that in normal circumstances, the number printed by vomaxjobs should be greater than or equal to the number of running jobs for that VO.  It can be lower but this is because of exceptional circumstances, like

- you may have done "qrun" to manually run jobs that the scheduler refused to schedule due to process caps
- you have just recently lowered the process cap

One more thing : you won't be able to get it completely right, if you support per-queue caps AND you have queues that support more than one VO.  In that case, you are interested in the following feature request

   https://savannah.cern.ch/bugs/?23586

and you could make a comment there "me too" to help increase the priority, if you are really interested.  The request obviously does not have incredibly high priority, it's three years old :-)

										JT

On Nov 4, 2010, at 15:02 , Öttl Peter wrote:

> Hi Jeff,
> 
> here at CSCS we are using Moab instead of Maui and have limits on queues rather than groups.
> Therefore I wanted to write our own vo_max_jobs_cmd but I'm not fully sure what output is expected.
> 
> Should it return the maximum number of jobs that a VO can run at any time or at the very moment the script runs?
> 
> The latter would be better for us because we could uses Moab's showbf command to determine the number
> of job slots available at the moment:
> 
> Nov 04 14:47 [root@lrms01:~]# showbf -c atlas
> Partition     Tasks  Nodes      Duration   StartOffset       StartDate
> ---------     -----  -----  ------------  ------------  --------------
> ALL               6      2      INFINITY      00:00:00  14:56:22_11/04
> 
> This would also take into account standing reservations and nodes that are down or offline.
> 
> Cheers,
> 
>  Peter
> 
> -- 
> Ing. Peter Oettl | CSCS Swiss National Supercomputing Centre
> Systems Engineer | HPC Co-Location Services
> Via Cantonale, Galleria 2 | CH-6928 Manno
> [log in to unmask] | www.cscs.ch | Phone +41 91 610 82 34
>