On Wed, Jun 29, 2011 at 09:43:33AM -0400, Vic wrote:
You can set limits per user as well via RQS.
Yes, but I don't want to set limits per user; I want to set limits *per
invocation*.
Each user must be able to submit jobs after his Quartus jobs have been
queued, and have those jobs start immediately (subject to resource, of
course). Additionally, users might sometimes need to run multiple Quartus
runs and have those run independently of each other - so, for example, we
might have one user running two instances, with four jobs executing from
each instance and 12 jobs from each queuing.
Sure, that makes sense. I don't think your situation is all that rare.
They can *submit* as many jobs as they want, in that they are sent to
SGE (up to the limits set by max_u_jobs, max_jobs, and other limits),
but only a certain number of them will run at a given time.
Indeed - but if I limit the total number of jobs a user can run to a
sensible level, then that user can't do any work after submitting a
Quartus run. We might as well send him home...
Not quite. Create two queues: one called "Quart" for Quartus jobs and
one called "Gallon" for non-Quartus. Both queues exist on all hosts.
Make Quart subordinate to Gallon. Set the scheduler to use the lowest
loaded systems first.
Thus, you can run as many Quartus jobs as you want, but when someone
wants to run something else, it will go to the Pint queue, and suspend
the Quartus jobs if it needs to.
Or you could buy more compute nodes.
3) We encourage the users to submit "more, smaller" jobs to SGE when
possible. This creates a higher job throughput, and a faster "churn"
rate, which leads to a more fair distribution of CPU cycles (we mostly
use functional shares for this).
This isn't something over which I have any control; we're using commercial
tools, and they submit jobs that are the size they are. Typically, we
expect 4hrs+ per job, but 24 hours isn't unknown.
Sure, we've the same issue here as well. Not all jobs are "short," but
we try.
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
