Thanks for your response. We'll consider making fair-tree the default in
later releases.
Thanks,
Brian
On 05/28/2015 12:08 AM, Blomqvist Janne wrote:
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]
