Discussion:
question on multifactor priority plugin - fairshare basics
Blosch, Edwin L
2014-10-14 22:26:39 UTC
Permalink
I must be misunderstanding a basic concept here.

What conditions would have to exist to cause a Fairshare value greater than 0.5?


[***@maruhpc5 ~]$ sshare -a
Account User Raw Shares Norm Shares Raw Usage Effectv Usage FairShare
-------------------- ---------- ---------- ----------- ----------- ------------- ----------
root 1.000000 11376527 1.000000 0.500000
root root 0 0.000000 0 0.000000 0.000000
cfd 1 1.000000 11376527 1.000000 0.500000
cfd bendeee 1000 0.076923 0 0.076923 0.500000
cfd bloscel 1000 0.076923 712296 0.134718 0.297027
<more users under same group>
Ryan Cox
2014-10-14 22:59:44 UTC
Permalink
I assume you are using the default fairshare algorithm since you didn't
specify otherwise. F=2**(-U/S) where U is Effectv Usage (often
displayed in documentation as UE) and S is Norm Shares. See
http://slurm.schedmd.com/priority_multifactor.html under the heading
"The SLURM Fair-Share Formula".

Basically, Effectv Usage needs to be less than Norm Shares for Fairshare
to be greater than 0.5.

Ryan
Post by Blosch, Edwin L
I must be misunderstanding a basic concept here.
What conditions would have to exist to cause a Fairshare value greater than 0.5?
Account User Raw Shares Norm Shares Raw Usage Effectv Usage FairShare
-------------------- ---------- ---------- ----------- ----------- ------------- ----------
root 1.000000 11376527 1.000000 0.500000
root root 0 0.000000 0
0.000000 0.000000
cfd 1 1.000000 11376527
1.000000 0.500000
cfd bendeee 1000 0.076923 0
0.076923 0.500000
cfd bloscel 1000 0.076923 712296
0.134718 0.297027
<more users under same group>
Blosch, Edwin L
2014-10-15 02:05:51 UTC
Permalink
Thanks for the reply Ryan,

Yes, I’m using the basic fairshare. I am trying to use fairshare across a flat listing of users only, with a placeholder parent account called ‘dev’, but for now, it has no siblings. All users are under ‘dev’.

I think the way it is calculated, in my configuration, the largest fairshare I will ever see is 0.5.

F = 2**(-Ue/S), where in my case S = 1000 / 16000 (1000 per user, 16 users (who each have 1000))
and I have Ue =S for a user who never submit a job yet because Ue = 0 (Uactual) + (1.0 – 0.0)*1000/16000 (1.0 is parent usage, which is always 1.0 in my case because dev is the only parent account for any user)

I was expecting/hoping/wishing the values would be between 0.0 and 1.0, but I can work with 0.5 as the max value. It just means that I need to double the PriorityWeightFairshare factor in order to achieve the intended relative weighting between Fairshare, QOS, Partitions, JobSize, Age.

Ed


From: Ryan Cox [mailto:***@byu.edu]
Sent: Tuesday, October 14, 2014 6:00 PM
To: slurm-dev
Subject: EXTERNAL: [slurm-dev] Re: question on multifactor priority plugin - fairshare basics

I assume you are using the default fairshare algorithm since you didn't specify otherwise. F=2**(-U/S) where U is Effectv Usage (often displayed in documentation as UE) and S is Norm Shares. See http://slurm.schedmd.com/priority_multifactor.html under the heading "The SLURM Fair-Share Formula".

Basically, Effectv Usage needs to be less than Norm Shares for Fairshare to be greater than 0.5.

Ryan
On 10/14/2014 04:27 PM, Blosch, Edwin L wrote:
I must be misunderstanding a basic concept here.

What conditions would have to exist to cause a Fairshare value greater than 0.5?


[***@maruhpc5 ~]$ sshare -a
Account User Raw Shares Norm Shares Raw Usage Effectv Usage FairShare
-------------------- ---------- ---------- ----------- ----------- ------------- ----------
root 1.000000 11376527 1.000000 0.500000
root root 0 0.000000 0 0.000000 0.000000
cfd 1 1.000000 11376527 1.000000 0.500000
cfd bendeee 1000 0.076923 0 0.076923 0.500000
cfd bloscel 1000 0.076923 712296 0.134718 0.297027
<more users under same group>
Ryan Cox
2014-10-16 14:37:57 UTC
Permalink
Ed,

Your math looks correct. In 14.11 you can achieve what you want by
setting Fairshare=parent on your dev account with sacctmgr.
Fairshare=parent on accounts (only defined on users prior to 14.11)
makes it so that accounts effectively disappear for fairshare
calculations but still exist for limits and organizational purposes.
Children are effectively reparented to their account's parent (root in
your case) for fairshare.

Ryan
Post by Blosch, Edwin L
Thanks for the reply Ryan,
Yes, I’m using the basic fairshare. I am trying to use fairshare
across a flat listing of users only, with a placeholder parent account
called ‘dev’, but for now, it has no siblings. All users are under
‘dev’.
I think the way it is calculated, in my configuration, the largest
fairshare I will ever see is 0.5.
F = 2**(-Ue/S), where in my case S = 1000 / 16000 (1000 per user,
16 users (who each have 1000))
and I have Ue =S for a user who never submit a job yet because Ue
= 0 (Uactual) + (1.0 – 0.0)*1000/16000 (1.0 is parent usage, which
is always 1.0 in my case because dev is the only parent account for
any user)
I was expecting/hoping/wishing the values would be between 0.0 and
1.0, but I can work with 0.5 as the max value. It just means that I
need to double the PriorityWeightFairshare factor in order to achieve
the intended relative weighting between Fairshare, QOS, Partitions,
JobSize, Age.
Ed
*Sent:* Tuesday, October 14, 2014 6:00 PM
*To:* slurm-dev
*Subject:* EXTERNAL: [slurm-dev] Re: question on multifactor priority
plugin - fairshare basics
I assume you are using the default fairshare algorithm since you
didn't specify otherwise. F=2**(-U/S) where U is Effectv Usage (often
displayed in documentation as UE) and S is Norm Shares. See
http://slurm.schedmd.com/priority_multifactor.html under the heading
"The SLURM Fair-Share Formula".
Basically, Effectv Usage needs to be less than Norm Shares for
Fairshare to be greater than 0.5.
Ryan
I must be misunderstanding a basic concept here.
What conditions would have to exist to cause a Fairshare value greater than 0.5?
Account User Raw Shares Norm Shares Raw Usage
Effectv Usage FairShare
-------------------- ---------- ---------- ----------- -----------
------------- ----------
root 1.000000 11376527 1.000000 0.500000
root root 0 0.000000 0 0.000000 0.000000
cfd 1 1.000000 11376527 1.000000 0.500000
cfd bendeee 1000 0.076923 0 0.076923
0.500000
cfd bloscel 1000 0.076923 712296 0.134718
0.297027
<more users under same group>
--
Ryan Cox
Operations Director
Fulton Supercomputing Lab
Brigham Young University
Loading...