add users.
On Aug 10, 2024, at 6:21 PM, Drucker, Daniel via slurm-users
wrote:
External Email - Use Caution
Yes, there is 'root' and 'mic', and everyone is under 'mic.
No, I don't know any Steve.
So what you're saying is I *must* at account-creat
res assignments.
With the FairTree mechanism, this gives us...
FairShare between condos (and the default account)...
FairShare within sub-account condos, as part of the parent condo...
FairShare within the leaf condo among users.
One of us obviously needs to diagram this...
regards,
s
s, as part of the parent condo...
FairShare within the leaf condo among users.
One of us obviously needs to diagram this...
regards,
s
On Sat, Aug 10, 2024 at 10:05 AM Drucker, Daniel
mailto:ddruc...@mclean.harvard.edu>> wrote:
And now, a few hours later - with no changes
parent0.991736 00.00
1.00 0.497120
cpu=0,mem=0,energy=0,node=0,b+
I am so confused.
On Aug 10, 2024, at 8:11 AM, Drucker, Daniel
wrote:
Hmm, no. That solved the problem of everyone having the same FairShare, but
even after
wrote:
I just set
PriorityFlags=NO_FAIR_TREE
and this seems to have solved the problem!
On Aug 10, 2024, at 7:45 AM, Drucker, Daniel
wrote:
According to https://docs.rc.fas.harvard.edu/kb/fairshare/ and
https://slurm.schedmd.com/SUG14/fair_tree.pdf :
"The Fairshare score is calcu
I just set
PriorityFlags=NO_FAIR_TREE
and this seems to have solved the problem!
On Aug 10, 2024, at 7:45 AM, Drucker, Daniel
wrote:
According to https://docs.rc.fas.harvard.edu/kb/fairshare/ and
https://slurm.schedmd.com/SUG14/fair_tree.pdf :
"The Fairshare score is calculated
According to https://docs.rc.fas.harvard.edu/kb/fairshare/ and
https://slurm.schedmd.com/SUG14/fair_tree.pdf :
"The Fairshare score is calculated using the following formula.f =
2^(-EffectvUsage/NormShares)"
This is clearly not happening on my system:
AccountUser RawShar
83871
cpu=0,mem=0,energy=0,node=0,b+
mic sgranger parent0.991736 1950800.003138
0.003138 0.983871
cpu=0,mem=0,energy=0,node=0,b+
On Aug 10, 2024, at 7:24 AM, Drucker, Daniel
wrote:
So I'm sti
hough some of the jobs in the
queue were submitted by users who have NEVER submitted a job before, and some
of the jobs are users who have been submitting thousands of jobs a day every
day for weeks.
This seems ... unfair?
> On Aug 9, 2024, at 9:52 PM, Drucker, Daniel
> wrote:
On Aug 9, 2024, at 9:21 PM, Fulcomer, Samuel wrote:
> And note that the high PriorityWeightAge may be complicating things. We set
> it to 0. With it set so high, it allows users to gain priority by flooding
> the queue if you allow high numbers of job submissions and they age up in
> priority w
> On Aug 9, 2024, at 9:15 PM, Fulcomer, Samuel
> wrote:
> ...and what are the top 10-15 lines in your share output?...
See the 4:10PM message in this thread.
The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you i
should work as you desire, modulo your slurm.conf
settings. What are the relevant lines in yours?
On Fri, Aug 9, 2024 at 6:09 PM Drucker, Daniel
mailto:ddruc...@mclean.harvard.edu>> wrote:
Er, user B has never.
On Aug 9, 2024, at 6:08 PM, Daniel M. Drucker
mailto:ddruc...@mclean.harvard.edu&g
-- Paul Raines (http://help.nmr.mgh.harvard.edu)
>
>
>
> On Fri, 9 Aug 2024 5:57pm, Drucker, Daniel wrote:
>
>> Hi Paul from over at mclean.harvard.edu<http://mclean.harvard.edu>!
>>
>> I have never added any users using sacctmgr - I've always jus
ution
I don't think fairshare use is updated until jobs finish...
On Fri, Aug 9, 2024 at 5:59 PM Drucker, Daniel via slurm-users
mailto:slurm-users@lists.schedmd.com>> wrote:
Hi Paul from over at mclean.harvard.edu<http://mclean.harvard.edu/>!
I have never added any users using
Fri, Aug 9, 2024 at 5:59 PM Drucker, Daniel via slurm-users
mailto:slurm-users@lists.schedmd.com>> wrote:
Hi Paul from over at mclean.harvard.edu<http://mclean.harvard.edu/>!
I have never added any users using sacctmgr - I've always just had everyone I
guess automatically join the de
with
sacctmgr -i add user "$u" account=$acct fairshare=parent
If you want users to have their own independent fairshare, you
do not use fairshare=parent but assign a real number.
-- Paul Raines (http://help.nmr.mgh.harvard.edu)
On Fri, 9 Aug 2024 5:20pm, Drucker, Daniel via slurm-us
I got the opposite result. When I submitted a job as bsmith, they got a lower
priority (the number was smaller) than the job submitted as csmith.
bsmith (who has never submitted a job before) got a priority of 98387 (which is
1 times the 0.983871 FairShare), whereas csmith (who is already ru
- Use Caution
I don’t have any 21.08 systems to verify with, but that’s how I remember it.
Use “sshare -a -A mic” to verify. You should see both a RawShares and a
NormShares column for each user. By default they’ll all have the same value,
but they can be adjusted if needed.
From: Drucker
Simple question:
Does FairShare still work if every user is under one account? E.g.:
$ sacctmgr show assoc format=Account,User
Account User
-- --
root
root root
mic
mic asmith
mic bsmith
mic csmith
mic djones
Yes, that makes sense. Thank you!
The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Mass General Brigham
Compliance HelpLine at https://www.m
> All I can say is that this has to do with --starttime and that you have to
> read the manual really carefully about how they interact, including when you
> have --endtime set. It’s a bit fiddly and annoying, IMO, and I can never
> quite remember how it works.
Oh, I think I understand. --start
What am I misunderstanding about how sacct filtering works here? I would have
expected the second command to show the exact same results as the first.
[root@mickey ddrucker]# sacct --starttime $(date -d "7 days ago" +"%Y-%m-%d")
-X --format JobID,JobName,State,Elapsed --name zsh
JobID
22 matches
Mail list logo