<div dir="ltr"><div>I have not had a chance to play with the newest Slurm, but I would suggest looking at GrpTRESRaw, which is supposed to gather the usage by TRES (in TRES-minutes).<br></div>So if there is a billing TRES in GrpTRESRaw, that might be what you want.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 27, 2018 at 11:21 AM, Roberts, John E. <span dir="ltr"><<a href="mailto:jeroberts@anl.gov" target="_blank">jeroberts@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'm testing the newest version of Slurm and I'm seeing an issue when using the newer billing TRES to charge for cpu time on a partition. I've seen that billing should be used now instead of cpu in order to properly use the "TRESBillingWeights" option on a partition. <br>
<br>
In my test case, I gave an account 2 hours of billing time. I used 1 hour of this while setting the partition to TRESBillingWeights="CPU=1.0". It seemed to have billed properly.<br>
Next, I set on the same partition TRESBillingWeights="CPU=0.5". I ran several jobs, but the billing never seemed to increase. RawUsage, however, did increment correctly.<br>
<br>
Here's an examples of sshare reporting no billing run minutes, when CPU=0.5 and I start a job with a walltime of 1 hour. Even though the RawUsage is well past 2 hours, a job can still run when it shouldn't.<br>
<br>
# sshare -A test -l -o RawUsage,GrpTRESMins,<wbr>TRESRunMins%60<br>
   RawUsage                    GrpTRESMins                                                  TRESRunMins <br>
----------- ------------------------------        ------------------------------<wbr>----------------------- <br>
      11068                    billing=120                      cpu=60,mem=0,energy=0,node=60,<wbr>billing=0<br>
<br>
If I set CPU=1.0 and start say a job for 2 hours, I get this in the logs:<br>
debug2: Job 32 being held, the job is at or exceeds assoc 239(test/(null)/(null)) group max tres(billing) minutes of 120 of which 60 are still available but request is for 120 (plus 0 already in use) tres minutes (request tres count 1)<br>
<br>
This makes sense because I previously ran a job at the weight of 1.0 for an hour so it "billed" for 1 hour at that time. How can I query the "available" billing hours if it's not RawUsage?<br>
<br>
Going back to setting billing CPU weight to 0.5, the logs seem to be inconsistent too. In this first line, it shows the right thing:<br>
debug:  TRES Weight: cpu = 1.000000 * 0.500000 = 0.500000<br>
<br>
but not a few lines down:<br>
debug2: acct_policy_job_begin: after adding job 45, assoc 239(test/(null)/(null)) grp_used_tres_run_secs(<wbr>billing) is 0<br>
<br>
Again, RawUsage increases correctly, but Slurm is using some other field for billing to determine if a job can run.<br>
<br>
My questions are: How can I set CPU billing to be less than 1 and how can I make sure jobs don't run if they are out of time in this case? What is Slurm using for billing, because it's clearly not RawUsage? Am I simply misunderstanding the billing and/or weights fields?<br>
<br>
Thanks for any help...<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Tom Payerle <br>DIT-ACIGS/Mid-Atlantic Crossroads        <a href="mailto:payerle@umd.edu" target="_blank">payerle@umd.edu</a><br></div><div>5825 University Research Park               (301) 405-6135<br></div><div dir="ltr">University of Maryland<br>College Park, MD 20740-3831<br></div></div></div></div></div></div>
</div>