| SWF field |
PBS field(s)
[ listed in
preference
order ]
|
specification |
| job |
- |
Jobs are sorted by arrival order (major) and partition SWF code (minor).
If jobs are still "equal" (arrived simultaneously to the same partition)
we use the serial from the PBS-ID (see above) to break the tie.
Jobs are then assigned in order 1,2,3.... |
| submit |
ctime |
By 10.12.5 of the
PBS administration guide:
'ctime' is the
"Time in seconds [since the epoch] when a job was created (first
submitted)." |
| wait |
ctime-start |
By 10.12.5 of the
PBS administration guide:
'start' is the
"Time in seconds [since the epoch] when the job execution started".
|
| runtime |
resources_used.walltime,
etime-ctime |
By 11.20.1 of the
PBS administration guide:
"Use the walltime attribute rather than wall time
calculated by subtracting the job start time from end time. The
walltime resource attribute does not accumulate when a job is
suspended for any reason".
However, some records have their 'resources_used.walltime' missing
from their record (in the
LPC log these are the 352 jobs with Exit_status=-4; that is, that
died on signal). In this case, due to no better alternative, the runtime
is computed by subtracting the job's 'ctime' from its 'etime'.
|
| proc_used |
resources_used.ncpus,
resources_used.nodect,
resources_used.nodes,
Resource_List.ncpus,
Resource_List.nodect,
Resource_List.nodes
|
-
The 'resources_used' list is the most appropriate to obtain this data.
The 'ncpus' resource is the most appropriate field, as by 4.8 of
PBS user guide we have:
"'ncpus' is the number of CPUs (processors) required by a job."
.
-
If we don't have 'ncpus', let's try the 'nodect', as by 6.7.1 of
the PBS administration guide:
"It is possible to set limits on queues (and the Server) as to how
many nodes a job can request. The 'nodes' resource itself is a text
string and difficult to limit. Thus, 'nodect' (node count) is set
by the Server to the integer number of nodes desired by the user
as declared in the nodes resource specification. That declaration
is parsed and the resulting total number of nodes is set in
nodect."
-
If we don't have 'nodect': though the value associated with 'nodes'
might be a complex string, it may also a simple number (as is
the case in the
LPC log, so we try to use 'nodes' as is.
-
If we don't have 'ncpus'/'nodect'/'nodes' in the 'resources_used' list
(as is the case in the
LPC log) the _requested_ size will serve as the allocated size
(extracted from the 'Resource_List'), by using the same resources
described above, in the same order.
|
| cpu_used |
resources_used.pcput,
resources_used.cput |
By 4.8 of the PBS administration guide
'pcput' is the
"per_process maximum CPU time (i.e. for any single process in the job)".
and 'cput' is the
"Maximum aggregated CPU time required by all processes in job"
.
We can convert between 'pcput' and 'cput' by dividing / multiplying
them with the processors used, if available.
Note however that if this is not available, and one PBS job uses 'pcput'
while the other uses 'cput' then one of this data fields will be lost
in the conversion (as we can't mix them in one SWF column).
|
| mem_used |
resources_used.pvmem,
resources_used.vmem,
resources_used.pmem,
resources_used.mem
|
By 4.8 of the PBS administration guide:
- 'pvmem' is the "per_process maximum amount of
virtual memory (i.e. for any single process in the job)."
- 'vmem' is the "Maximum, aggregate amount of
virtual memory used by all concurrent processes in the job."
- 'pmem' is the "per_process maximum amount of
physical memory (i.e. for any single process of the job)."
- 'mem' is the "Maximum amount of physical memory
(RAM) required by job."
Naturally, we prefer virtual over physical memory, because the former
really reflects the jobs' needs.
We also prefer the aggregated form over the per-process one (but recall
one can be converted to the other if used-processors are known).
Similarly to proc_used, we can't mix type (physical/virtual) and
quantity (aggregated/per-process) in the same SWF column, so some data
fields might get lost in the conversion.
The converter should probably prefer the specification that results in
more converted data.
|
| proc_req |
Resource_List.ncpus,
Resource_List.nodect,
Resource_List.nodes |
See conversion specification of 'proc_used'. |
| cpu_req |
Resource_List.walltime |
See conversion specification of 'runtime'. |
| mem_req |
Resource_List.pvmem,
Resource_List.vmem,
Resource_List.pmem,
Resource_List.mem |
See conversion specification of 'mem_used'. |
| status |
Exit_status |
By 10.12.5 of the
PBS administration guide:
"The exit status of the job: If the value is less than 10000
(decimal) it is the exit value of the top level process of the job,
typically the shell. If the value is greater than 10000, the top
process exited on a signal whose number is given by subtracting
10000 from the exit value."
We assume that the meaning of exit status values is the same as
that of the shell. Thus, we consider Exit_status=0 as normal termination
(SWF status=1) and other values as indicating failure (SWF status=0,
unless the job was canceled, as indicated by a D/A record, in which
case the SWF status is 5).
|
| uid |
user |
By 10.12.5 of the
PBS administration guide:
user=username is
"The user name under which the job executed."
|
| gid |
group |
By 10.12.5 of the
PBS administration guide:
group=groupname is
"The group name under which the job executed."
|
| executable |
jobname |
By 10.12.5 of the
PBS administration guide:
jobname=job_name is
"The name of the job."
|
| queue |
queue |
By 10.12.5 of the
PBS administration guide:
queue=queue_name is
"The name of the queue in which the job executed."
|
| partition |
id_string |
A job ID string may look like this: 123.par.cnn.com.
The server in this string serves as the partition identifier. |
