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]
