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
