Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!cernvax!chx400!urz.unibas.ch!doelz
From: doelz@urz.unibas.ch
Newsgroups: comp.sys.sgi
Subject: <None>
Message-ID: <1990Dec3.140432.1202@urz.unibas.ch>
Date: 3 Dec 90 13:04:31 GMT
References: <1990Nov28.163415.14317@odin.corp.sgi.com> <1539@contex.UUCP> <1990Dec2.181344.20040@cunixf.cc.columbia.edu> <4146@network.ucsd.edu>
Organization: University of Basel, Switzerland
Lines: 28

In article <4146@network.ucsd.edu>, slamont@network.ucsd.edu (Steve Lamont) writes:
> In article <1990Dec2.181344.20040@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
>>Finally, another way to go would be to implement a batch queue, as Convex
>>has done.
> 
> Small point of information.  The batch queue system (NQS) was developed, to the
> best of my knowledge, at NASA Ames Research Center Numerical Aerodynamics
> Simulation Facility for their Crays.  Convex has taken that system, which is
> pretty nifty, by the way, and packaged it up for use on their systems.  NQS is
> also available on Crays from Cray Research.  There is also a PD version, I
> believe that you can get fropm either NASA or COSMIC -- I don't recall which.


Also available on SGI's - ask your sales rep for the Network Queuing System 
option. Bad news first: It wont talk to Convexes CXbatch. Good news: Works 
as expected, with much more comfort around than the nice'ing stuff. Supports
various limits (as from 3.3 on, the rlimit calls are implemented), including
per-proc CPU time, working set, core file size, data segment size, per-proc
permanent file size, and some others. I did not encounter problems so far, 
and am rather happy with it. The problem is the memory; once you have a 
large number of queues doing some jobs, the swapper turns on and will 
block your system rather heavily even if the priorities of the jobs has been
niced to a very low valye. 

Regards 
Reinhard 
.