<None>

[doelz at urz.unibas.ch]

In article <4146 at network.ucsd.edu>, slamont at network.ucsd.edu (Steve Lamont) writes:
> In article <1990Dec2.181344.20040 at cunixf.cc.columbia.edu> shenkin at 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 
.