Hi, much as I'd be sad to see "my baby" go, I agree with you that fair-tree is a better choice. So, +1.
Furthermore, could the fair-tree algorithm be made the default when priority/multifactor is used? Is there any case where the current default is objectively better than fair-tree? -- Janne Blomqvist ________________________________________ From: Brian Christiansen [[email protected]] Sent: Friday, May 22, 2015 0:32 To: slurm-dev Subject: [slurm-dev] RE: multifactor2 priority weighting Is there anyone using the multifactor2/ticket based fairshare? Are there any objections to removing it in a later release in favor of the fair-tree algorithm? Our feeling is that the fair-tree algorithm provides the same benefits as the ticket-based algorithm plus more. Thanks, Brian On 05/21/2015 12:10 AM, [email protected] wrote: > 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]
