No trade-off. We would just request that users only use Tier3 when a job is
really pressing. It's definitely possible that inconsiderate users would be
impolite, but for various reasons I don't think that would be a big problem
for our cluster if Tier2 was available as an alternative.

In our current setup, we have Tiers 1 & 3 implemented entirely by QOS.
There is a "Tier 1" QOS which anyone can use, plus a high priority QOS for
each group which has a group-specific GrpTRES limit and can preempt the
normal QOS. The problem we've run into is that people who would otherwise
be happy to run their jobs in the normal QOS have been frustrated when
their jobs are preempted, which has had the effect of escalating the use of
the high priority QOSs by users who just don't want their jobs preempted.
Hence the desire for three options: one Tier for users with many low
priority jobs, one for jobs that are high priority but not urgent, and one
for jobs that need to run right away.

On Sun, Aug 6, 2017 at 4:14 PM dani <d...@letai.org.il> wrote:

> What's the trade-off for using tier3? It would seem inconsiderate users
> would never use tier2, bypassing it completely, as there is no advantage to
> using it over tier3.
>
>
> On 04/08//2017 17:30, Evan Remington wrote:
>
> Hello,
>
> I'm looking for some feedback on a scheme I've come up with to configure
> priority tiers on our cluster which is used by a few dozen groups.
>
> The desired behavior is that users can submit jobs to one of three
> priority tiers:
>
>    - Tier 1: Lowest priority; any user can use as many resources as are
>    available (priority subject to Fairshare).
>    - Tier 2: Higher priority; users can use up to a certain amount of
>    resources which are shared by their group.
>    - Tier 3: Higher priority AND the ability to preempt jobs in Tier 1.
>    The available resources in this tier are shared between those of Tier 2.
>
> The way I've thought to do this is to set up three QOSs with the behavior
> described above (but without TRES limits), and then for each group, three
> corresponding accounts. The first account would only be allowed to submit
> to the Tier 1 QOS, the second to Tier 2, and the Third to Tier 3. Tier 2
> would have GrpTRES configured, and then Tier 3 would be a child of Tier 2
> and therefore share the available TRES.
>
> Jobs would default to the Tier 1 account, going to the Tier 1 QOS. Anyone
> who wants to submit a higher priority job just adds --account=Tier2 or
> --account=Tier3.
>
> I've tested this configuration for a single user and it seems to produce
> the desired result. Is there a more straightforward way to achieve the same
> behavior? Or is there some reason this configuration would be problematic?
>
> Thanks,
> Evan
>
>
>

Reply via email to