> -----Original Message----- > From: Bill Wichser [mailto:[email protected]] > Sent: Wednesday, January 21, 2015 8:23 AM > To: slurm-dev > Subject: [slurm-dev] RE: fairshare allocations > > > > > On 01/21/2015 11:07 AM, Lipari, Don wrote: > > > > > >> -----Original Message----- > >> From: Bill Wichser [mailto:[email protected]] > >> Sent: Wednesday, January 21, 2015 5:20 AM > >> To: slurm-dev > >> Subject: [slurm-dev] fairshare allocations > >> > >> > >> The algorithm I use is fairtree under 14.11 but I believe that my > >> question relates to any method. > >> > >> As a University, we have many investments into a given cluster. At the > >> most simplistic level, lets assume there are but two two allocations. > >> The method I have been using is to assign a value, as a percentage of > >> ownership, to the various ACCOUNTs such that when summed across all > >> accounts, they add to 100. > >> > >> So chemistry might have a fairshare value of 20 as they contributed 20% > >> of the funding. Physics has a value of 10. And so forth, with many > >> having a fairshare value of 1 since no money was contributed. > >> > >> In the past, I simply assigned either a fairshare value of parent to > the > >> users or assigned them a value of 1. > >> > >> So lets take a user, call him Bill, who has a fairshare value of 1 > under > >> the account=chem. It appears to me that this 1 share is actually a 1 > >> share of the total and not a 1 share of what the account=chem owns. Am > >> I reading this correctly here? > > > > A share of 1 for Bill is a share of the total shares assigned to users > > (or accounts) under the chem account. Chem can have 1000 users, each > with > > 1 share, but chem users' combined usage of the system will be throttled > > to 20% based on job priorities calculated by the fair-share factor. > > > > That works both ways: if only one user from chem is submitting jobs, > that > > user can receive 20% of the resources of the cluster, even though they > have > > only one share of chem. > > > > The most common practice is to assign a share of 1 to every user in an > > account. You can assign greater share values to users who are entitled > > to more than their peers. > > > > Don Lipari > > > >> > >> Thanks, > >> Bill > > So that was my expectation. But lets look at this account, truncated, > with a user with a fairshare of 20 (using sshare -a -l -A ee -p) > > Account|User|Raw Shares|Norm Shares|Raw Usage|Norm Usage|Effectv > Usage|FairShare|Level FS|GrpCPUMins|CPURunMins| > ee||261|0.218227|189272064|0.047197|0.047197||4.623757||50912| > > ee|user1|1|0.009091|24151307|0.006022|0.127601|0.771261|0.071245||24605| > ee|user2|1|0.009091|652289|0.000163|0.003446|0.780059|2.637872||0| > ee|user3|25|0.227273|15684228|0.003911|0.082866|0.781525|2.742652||0| > ... > > > > > > > So ee as an account gets fairshare=261 and gets a 0.218227 normalized > share count. > > A user underneath gets the expected 0.009091 normalized shares since > there are a lot of fairshare=1 users there. The user3 gets basically > 25x this value as the fairshare for user3=25 > > Yet the normalized shares is actually MORE than the normalized shares > for the account as a whole. What should I make of this?
That looks like a bug. I don't see that behavior on our systems running slurm 14.03.11. Don > Bill
