Hi Lloyd We have what I would call a "Live Multifactor", as it gives priorities only taking into account a number of factors taking place in the present, and disregarding the past. I don't know if this would be useful to you. For the group of users and the resources we have, and how they tend to use them, it seems to work well (unfortunately for now we haven't had a lot of periods with the cluster full and some jobs in the queue, so we can't be sure it's "fair" under very different situations). The main objective when we designed this plugin (based in Slurm's own Multifactor idea) was the usual one: trying to avoid that a small number of users take up the most part of the resources, while having no limits if there are resources available.
So this are the factors we consider (the first two factors are the same that Slurm's Multifactor): - Age: time waiting in the queue. The higher the time, the higher the priority. - Job size: we particulary want higher priority for bigger jobs (size is in nodes). - Walltime: the smaller the time, the higher the priority. Users are forced to always specify the walltime for their jobs. - Number of jobs running by the user: the more jobs, the lower priority. - Number of nodes in use by the user: the more nodes, the lower priority. We have back_fill activated too. Regards, Miguel Méndez On Wed, Feb 6, 2013 at 8:25 PM, Lloyd Brown <[email protected]> wrote: > > > I would love to have some sort of banking/credit mechanism, even if it > didn't actually involve money (eg. proposals get reviewed by a > committee, and get assigned a certain number of "credits"). > Unfortunately that's not going to be possible for several more years at > least, due to university politics and the > not-offending-a-particular-donor effect. > > Lloyd Brown > Systems Administrator > Fulton Supercomputing Lab > Brigham Young University > http://marylou.byu.edu > > On 02/06/2013 11:32 AM, Mario Kadastik wrote: > > Other option is start billing them :D >
