nl.nikhef.pdp.dynsched/trunk/vomaxjobs-generic.txt

$Id$
Source: $URL$

The 'vomaxjobs' program is one of the two LRMS-dependent
programs that need to be provided as plugins to the
dynamic-scheduler info provider.

The program is quite simple: it should be constructed so that, when
it is run, it generates output that looks like the following:

{'biome': 132, 'users': 50, 'geant': 100, 'vlibu': 132, \
 'DEFAULT': 330, 'ops': 32, 'pvier': 4, 'cmssgm': 1, \
 'vlemed': 132, 'vlefi': 132, 'tutor': 40, 'phicosgm': 1, \
 'emutd': 132, 'asci': 132, 'ncf': 132, 'phicos': 132, \
 'vldbi': 132, 'dteam': 32, 'cms': 10, 'vledut': 132, 'esr': 32}

Note that the line breaks and '\' characters have been added
in this doc file for clarity, but they should not be in the
real program output.

The meaning of the lines is very simple.  The above output says

 unix group 'biome' is allowed to have 132 active processors
 unix group 'users' is allowed to have 50 active processors
 [ ... ]

Note that the above output includes a DEFAULT group; this is coming
from the scheduler, the information provider does not use this!

Note as well that the number provided (i.e. 132 for 'biome') is
the _total allowed_.  At a given instant you may have say 102
active biome jobs, each using 1 cpu ... you still report 132
since this is the TOTAL you are ALLOWED to have, not the
additional number you are allowed to start (in the current example
that would be 30).

The version provided with lcg-info-dynamic-pbs queries the
MAXPROC attribute from Maui.  Some sites use "max running"
limits for specific queues via torque, I am sure BQS, LSF,
Condor also have mechanisms like this.  vomaxjobs-maui
is not intended to cover all possible cases; it should be
adapted or replaced as needed to fit the site scheduling
policy.

1	$Id$
2	Source: $URL$
3
4	The 'vomaxjobs' program is one of the two LRMS-dependent
5	programs that need to be provided as plugins to the
6	dynamic-scheduler info provider.
7
8	The program is quite simple: it should be constructed so that, when
9	it is run, it generates output that looks like the following:
10
11	{'biome': 132, 'users': 50, 'geant': 100, 'vlibu': 132, \
12	'DEFAULT': 330, 'ops': 32, 'pvier': 4, 'cmssgm': 1, \
13	'vlemed': 132, 'vlefi': 132, 'tutor': 40, 'phicosgm': 1, \
14	'emutd': 132, 'asci': 132, 'ncf': 132, 'phicos': 132, \
15	'vldbi': 132, 'dteam': 32, 'cms': 10, 'vledut': 132, 'esr': 32}
16
17	Note that the line breaks and '\' characters have been added
18	in this doc file for clarity, but they should not be in the
19	real program output.
20
21	The meaning of the lines is very simple. The above output says
22
23	unix group 'biome' is allowed to have 132 active processors
24	unix group 'users' is allowed to have 50 active processors
25	[ ... ]
26
27	Note that the above output includes a DEFAULT group; this is coming
28	from the scheduler, the information provider does not use this!
29
30	Note as well that the number provided (i.e. 132 for 'biome') is
31	the _total allowed_. At a given instant you may have say 102
32	active biome jobs, each using 1 cpu ... you still report 132
33	since this is the TOTAL you are ALLOWED to have, not the
34	additional number you are allowed to start (in the current example
35	that would be 30).
36
37	The version provided with lcg-info-dynamic-pbs queries the
38	MAXPROC attribute from Maui. Some sites use "max running"
39	limits for specific queues via torque, I am sure BQS, LSF,
40	Condor also have mechanisms like this. vomaxjobs-maui
41	is not intended to cover all possible cases; it should be
42	adapted or replaced as needed to fit the site scheduling
43	policy.
44
grid.support@nikhef.nl	ViewVC Help
Powered by ViewVC 1.1.28