Thanks Janne, We are at 14.03.0 so no fair-tree yet.
I interpret that I do _not_ see any user with fair-share priority 1.0 as the priority factor I have been capturing by running 'sprio', never reach the set value of PriorityWeightFairshare=10000. Often the largest value is well under 1000 Perhaps we should drop back to the default scheme and try fair-tree when we update far enough - but if there are ticket based fairshare users out there, this may be a bug worth fixing. BTW I also put in a support request that references this thread. I was hoping that I might find the author or interested sites so I'm glad I posted here and am very grateful for your work and response. Gareth > -----Original Message----- > From: Janne Blomqvist [mailto:[email protected]] > Sent: Thursday, 21 May 2015 4:04 PM > To: slurm-dev > Cc: Lipari, Don > Subject: [slurm-dev] RE: multifactor2 priority weighting > > > Hi, > > I'm the author of the multifactor2 algorithm. The multifactor2/ticket > based fairshare algorithm, in the end, produces fair-share values > normalized between 0 and 1, like the other available algorithms. The > algorithm has 3 phases: > > 1. Mark which users have jobs in the queue 2. Starting from the root of > the account tree, distribute tickets, weighted by a fair-share factor > (which is between 0 and 100, as Don mentioned). > 3. Calculate the final fair-share priority, such that the user with the > most tickets gets the priority 1.0, the others proportional to that > depending on how many tickets they have. > > The goal of the algorithm was to better balance fair-share in an > account hierarchy than the original fair-share algorithm. If there is > no hierarchy, I don't think it provides much benefit. > > Also, if the OP is already on 14.11, I recommend looking at the "fair- > tree" algorithm > > http://slurm.schedmd.com/fair_tree.html > > This is what we currently are running. It solves some issues with the > ticket based algorithm, and I think currently it's the best choice for > ensuring fairness between account hierarchies. > > On 2015-05-13 18:21, Lipari, Don wrote: > > I need to retract my comments below. While what I wrote is > consistent with some of the text from the priority_multifactor2.html > page, the writers introduced a secondary term, "fair-share priority" > which looks to be a normalized "fair-share factor". And I am not > directly familiar with this nuance. > > > > Don > > > > > -----Original Message----- > > > From: Lipari, Don [mailto:[email protected]] > > > Sent: Wednesday, May 13, 2015 7:56 AM > > > To: slurm-dev > > > Subject: [slurm-dev] RE: multifactor2 priority weighting > > > > > > The original multi-factor plugin generated fair-share factors > > > ranging between 0.0 and 1.0. Under this formula, 0.5 was the > factor > > > a user/account would see if their usage was commensurate with their > > > shares. The multi-factor2 plugin fair-share factors range between > > > 0.0 and 100.0, with 1.0 indicating a perfectly serviced > user/account. > > > > > > Don > > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:[email protected]] > > >> Sent: Tuesday, May 12, 2015 10:05 PM > > >> To: slurm-dev > > >> Subject: [slurm-dev] multifactor2 priority weighting > > >> > > >> > > >> Hi All, > > >> > > >> We've just switched to multifactor2 priority as it seemed like a > > > good > > >> idea (and low risk) and it is working but the priority factors are > > >> much lower (maybe 100x). The final paragraph on > > >> http://slurm.schedmd.com/priority_multifactor2.html says we might > > > need > > >> to reweight but this magnitude seems odd. > > >> > > >> Does anyone have any insight that they might like to share? > > >> > > >> Regards, > > >> > > >> Gareth > > >> > > >> BTW. The following may matter. > > >> We currently do not have a tree as such, all users are direct > > > children > > >> of root. This probably makes using the ticket based algorithm less > > >> compelling. > > >> Also, we have set FairShareDampeningFactor=40 as we have many > > >> relatively inactive users and this may have an impact though I'd > > >> expect it to be ignored with the multifactor2 scheme. > > >> We have PriorityWeightFairshare=10000 > > > -- > Janne Blomqvist, D.Sc. (Tech.), Scientific Computing Specialist Aalto > University School of Science, PHYS & NBE > +358503841576 || [email protected]
