Thanks to everybody for their responses to my posting about the existence
of a Sun program that would tie the running of background jobs to the
activity of the screen blanker.
Their were two basic pieces of advice: one to use the package "condor",
the other to set the kernel parameter "maxslp" to approximately 300.
Please note that I have not yet tried either solution and can therefore
make no recommendations regarding them.
I include one representative letter from each camp:
-----------------------------------------------
Advice to use the package "condor"
-----------------------------------------------
>From jpmg@engineering.cambridge.ac.uk Wed May 29 04:22:44 1991
From: Patrick Gosling <jpmg@engineering.cambridge.ac.uk>
To: jimbys@cobalt.cco.caltech.edu
Subject: Re: background jobs/screenblank
Newsgroups: msgs.sun-managers
Cc: jpmg@engineering.cambridge.ac.uk
>...
Take a look at the Condor package, available from an ftp archive near you.
Note that there is a new version promised "sometime this summer" which sounds
much nicer than the current version (which is good, but didn't quite suit our
set-up here). Here is the relevant posting from the newsgroup comp.archives:
----------------------------cut here----------------------------------------
Article 4790 of comp.archives:
From: mike@cs.wisc.edu (Mike Litzkow)
Newsgroups: comp.archives
Subject: [os-research] Condor - Run UNIX jobs on idle workstations
Archive-name: unix/batch/condor/1991-05-17
Archive-directory: shorty.cs.wisc.edu:/condor/ [128.105.2.8]
Original-posting-by: mike@cs.wisc.edu (Mike Litzkow)
Original-subject: Condor - Run UNIX jobs on idle workstations (available via ftp/uucp)
Reposted-by: emv@msen.com (Edward Vielmetti, MSEN)
In his article titled "CMU's Condor process-migration system" Pat Wilson
writes:
> I'm looking for references to CMU's "Condor" process-migration system.
> We're running a bunch of UNIX workstations all on AFS, and I'd like
> to do _something_ with all those idle cycles...
First, to set the record straight, Condor has been under development at
the University of Wisconsin for several years, (not CMU).
Second, to bring things up to date, we are working on a new
distribution which will be available sometime this summer. New
features will include support for direct use of NFS, support for some
new platforms including R6000, increased support for use with FORTRAN
programs, and many other enhancements.
At this time we would like to invite all Condor users to please send us
comments about your present use of Condor and what you would like to
see in the upcoming release. We are especially interested in the size
of your condor pool, what kinds of machines you are running on, what
kinds of applications you are using Condor for, and any anecdotal
stories about particularly interesting applications. Also we would
like to know what new features would be most useful in the future, e.g.
port to a new platform, support for parallel applications, etc.
Finally, for those who are unfamiliar with Condor, (and to answer Pat's
original question), a repeat of an earlier announcement:
Subject: Condor - Run UNIX jobs on idle workstations (available via ftp/uucp)
Brief Description:
Condor is a facility for executing UNIX jobs on a pool of
cooperating workstations. Jobs are queued and executed
remotely on workstations at times when those workstations would
otherwise be idle. A transparent checkpointing mechanism is
provided, and jobs migrate from workstation to workstation
without user intervention. When the jobs complete, users are
notified by mail. No source code changes are required for use
of Condor, but executables must be specially linked. Condor is
especially suited for execution of long running, compute bound
jobs.
Limitations:
There are several restrictions on the type of program which can
be executed by the condor facility. Only single process jobs
are supported, and signals and IPC calls are not implemented.
Copyright:
Condor is copyrighted, but available without any charge or
license agreement. The copyright is not very restrictive, but
requires reproduction of the copyright, and disclaims the
University of Wisconsin from any responsibility for problems
connected with condor.
Currently supported architectures and UNIX variants:
VAX BSD 4.3
VAX Ultrix 3.0 and above
SPARC SunOS4.0 and above
I386 Dynix
MC68020 SunOS3.2 (and probably 4.0 and above)
DECstation 3100 Ultrix 3.0 and above
How to get it:
Ftp to "shorty.cs.wisc.edu", (128.105.2.8), and login as
"ftp". Give anything except the null string as a password.
Fetch the "README" file. Switch your ftp user program to
"binary" mode. Fetch "Condor_4.0.0.tar.Z". The README file
tells what do to from there.
The software is also available via anonymous ftp from uunet.uu.net
in "/networking", and via anonymous uucp from osu-cis in directory
"/pub".
Documentation:
Source for all the documentation is included in the
distribution. The README file explains how to extract just the
source, which you should do first, so you can plan where to
extract everything else. Some of the documents contain
"gremlin" pictures, but the ditroff ready versions are also
included for those who don't have gremlin. If you can't print
the docs, send me your address, and I'll mail you a set.
Write or call if you have any questions or problems.
email: mike@cs.wisc.edu or ucbvax!uwvax!mike
phone: (608) 262-6122
Mike Litzkow
-- comp.archives file verification
shorty.cs.wisc.edu
total 1813
-rw-r--r-- 1 1377 971314 May 16 09:52 tmp.Z
-rw-rw-r-- 1 1377 43580 Jun 11 1990 install.PS
-rw-rw-r-- 1 1377 1931 Jun 11 1990 README
-rw-rw-r-- 1 1377 124336 Jun 11 1990 tech.PS
-rw-rw-r-- 1 1377 673145 Oct 18 1989 Condor_4.0.0.tar.Z
found condor ok
shorty.cs.wisc.edu:/condor/
----------------------------------cut here-------------------------------
hope this is useful,
-patrick.
-- Patrick Gosling, jpmg@eng.cam.ac.uk Cambridge Univ. Engineering Dept., UK.----------------------------------------------------- Advice for changing the value of maxslp in the kernel -----------------------------------------------------
>From stern@sunne.East.Sun.COM Wed May 29 16:18:33 1991 From: stern@sunne.East.Sun.COM (Hal Stern - Consultant) To: jimbys@cobalt.cco.caltech.edu Subject: Re: background jobs/screenblank
better yet, why not just change the maxslp value in the kernel?
the kernel decides that a process is "dead wood" if it has been asleep for N seconds; it gets swapped out after that time.
try making maxslp 300 or so. the default is 20 seconds. 300 seconds is about the time granularity used by the screenblanker.
--hal stern sun microsystems northeast area consulting group
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:14 CDT