Yep, we use functional tickets to accomplish this exact goal. Every user gets 1000 functional tickets via auto_user_fshare in sge_conf(5), though your exact number will depend on the number tickets and weights you have elsewhere in your policy configuration.
On Mon, Jan 25, 2016 at 11:25:53AM -0800, Christopher Heiny wrote: > > Hi all, > > We've been using GridEngine for several years now, currently OGS > 2011.11p1 on Fedora 20 installed from Fedora RPMs. Our job mix is > mostly embarassingly parallel - we use array jobs to dispatch up to 100 > tasks, each of which might require 1, 16, 32, or 64 cores. Each job > takes up a significant amount of our cluster, so that only a few jobs > are typically active at one time, though there may be a couple of dozen > pending. Up recently, FIFO scheduling has worked fine for us. But now > one of the groups has come to me with a request for a refinement in the > scheduling. Here's the scenario: > > The team has started submitting batches of 10 to 20 such jobs at a time. > While the work isn't done until all 20 jobs complete, analysis of > results can start as soon as the first job completes. With default > scheduling, if Alice qsubs here 10 jobs first, and Bob qsubs his jobs a > minute later, Bob still needs to wait a couple of hours to get the > results from his first job. > > Since there's only so much time Bob can spend at the foosball table > before the Big Cheese starts thinking he's goofing off, the team has > requested is that I implement scheduling such that Bob's first job(s) > will run as soon as possible (probably after one of Alice's early jobs > has completed), and the cluster resources will be (very roughly) split > between the two of them. And if Carol comes along with a similar set of > jobs, that her first job(s) would run as soon as one of Alice's or Bob's > finishes, and then cluster resources would be split three ways (very > roughly) between them. And similarly if David comes along and adds his > jobs to the mix, then resources get roughly split four ways. > > Anyway, I *think* this can be achieved using user functional tickets. > Is that a reasonable assumption? Or is job submission time going to > jump in there and mess things up in some way? > > As a related question, is it possible to set a default number of tickets > per user? Since all users are on a level playing field, this would > eliminate hassles of adding/editing new users as they join the > organization. > > Thanks very much! > Chris > > > > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users -- -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
