The usefulness of this functionality is for when someone only wants to 
see a high level view of when there job ran.  If someone has 100's of 
steps per allocation this makes it easy to see a summary of the jobs 
they ran when they don't really care about the individual step.  If you 
can think of better documentation please submit a patch.

Danny

On 10/17/12 02:03, Björn Torkelsson wrote:
> On 2012-10-16 21:46 Danny Auble wrote:
>
>> sacct -X only shows the allocation information.  What are you expecting
>> to be printed?
> Well, I expected it to print the first line of sacct ... without -X, i.e
> to get a one line summary of the job. However reading the man page again
> and taking into account that -X == --allocations it makes much more
> sense. (though I'm not really convinced of the usefulness of -X). Maybe
> it should be clarified in the man page that it is the allocation
> information that is printed?
>
> /Björn
>
>> On 10/08/12 05:41, Björn Torkelsson wrote:
>>> Hi,
>>>
>>> According to the man page sacct -X should show the cumulative
>>> statistics, however when running sacct -X we never get any statistics,
>>> which we do when running sacct without -X. Am I misunderstanding the
>>> behaviour of sacct -X?
>>>
>>>
>>> sacct -X -j 149177 -o JobID,State,MinCPU,AveCPU,SystemCPU,TotalCPU,MaxRSS
>>>          JobID      State     MinCPU     AveCPU  SystemCPU   TotalCPU
>>> MaxRSS
>>> ------------ ---------- ---------- ---------- ---------- ----------
>>> ----------
>>> 149177        COMPLETED                         00:00:00
>>> 00:00:00
>>>
>>>
>>> sacct -j 149177 -o JobID,State,MinCPU,AveCPU,SystemCPU,TotalCPU,MaxRSS
>>>          JobID      State     MinCPU     AveCPU  SystemCPU   TotalCPU
>>> MaxRSS
>>> ------------ ---------- ---------- ---------- ---------- ----------
>>> ----------
>>> 149177        COMPLETED                         02:53:06
>>> 7-06:26:35
>>> 149177.batch  COMPLETED   00:00:00   00:00:00  00:00.420  00:01.720
>>> 6464K
>>> 149177.0      COMPLETED 7-06:22:53   14:31:54   02:53:06 7-06:26:34
>>> 31787960K
>>>
>>> We just upgraded slurm to 2.4.3 from 2.3.4. However we noticed the same
>>> behaviour on 2.3.4.
>>>
>>> /Björn Torkelsson - HPC2N, Umeå University
>>>
>

Reply via email to