[BProc] Re: New Version of BJS (was Re: bjs job id)

[Daniel G. <dg...@ti...>]

On Fri, Mar 19, 2004 at 04:48:56PM -0700, er...@he... wrote:
> On Fri, Mar 19, 2004 at 02:02:32PM -0500, Daniel Gruner wrote:
> > On Fri, Mar 19, 2004 at 11:01:53AM -0700, er...@he... wrote:
> > > On Wed, Mar 17, 2004 at 11:12:08PM -0500, Daniel Gruner wrote:
> > > > Thanks, Erik.  It works just fine.  The issue with the interactive
> > > > jobs is also fixed.
> > > > 
> > > > I guess it is worth at least a minor revision number... :-)
> > > 
> > > Ok, it's up on sourceforge as BJS 1.5.  There's only one tiny little
> > > change.  I changed "BJS_JOBID" to just JOBID since other schedulers on
> > > BProc might want to emulate the interface.
> > > 
> > > http://sourceforge.net/project/showfiles.php?group_id=24453&package_id=55872&release_id=224841
> > > 
> > > - Erik
> > 
> > Great!  It seems to be working fine for me.  Both for interactive and for
> > batch jobs.  I will get the latest from sourceforge.
> > 
> > I have a question:  How does bjs deal with multiprocessor nodes?  I have so
> > far only run it on clusters of uniprocessors, but I would like to install
> > it on my other clusters, which have dual-cpu machines.
> 
> As far as BJS and BProc are concerned "we're renting rooms."  The room
> in this case is the node.  You ask for nodes, if it's got multiple
> CPUs, it's up to you to do something sensible with both.

It would be really nice if we could specify "how big the rooms are", so that
the scheduler could send more than one job per machine if it is defined
as having several cpus.  One way could be to think of repeated nodes out
of a list, or a variant on the simple or filler policies that take a 
variable of "jobsPerNode", or whatever.  Is this feasible (easily feasible,
I mean)?

> 
> > I am using the simple policy, since I don't ever want more processes running
> > on the nodes than there are processors (well, at least for now).  Can you tell
> > me a bit more about the filler policy?
> 
> Filler is a simple back filler.  It will let later jobs run first if
> there's a big enough hole.  For example job A is running using 30/32
> nodes and has 100 sec left.  job B wants 32/32.  Job C after that one
> only wants 2 for 90 sec.  "filler" will see that that fits in the hole
> and start it.  "simple" only starts stuff in order.

Ok, neat!  Sounds like the one to use if you have a mixture of serial
and parallel jobs.


-- 

Dr. Daniel Gruner                        dg...@ti...
Dept. of Chemistry                       dan...@ut...
University of Toronto                    phone:  (416)-978-8689
80 St. George Street                     fax:    (416)-978-5325
Toronto, ON  M5S 3H6, Canada             finger for PGP public key