SUMMARY background jobs/screenblank

From: James V. Bys (
Date: Mon Jun 03 1991 - 18:10:02 CDT

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 Wed May 29 04:22:44 1991
From: Patrick Gosling <>
Subject: Re: background jobs/screenblank
Newsgroups: msgs.sun-managers


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 Litzkow)
Newsgroups: comp.archives
Subject: [os-research] Condor - Run UNIX jobs on idle workstations

Archive-name: unix/batch/condor/1991-05-17
Archive-directory: []
Original-posting-by: (Mike Litzkow)
Original-subject: Condor - Run UNIX jobs on idle workstations (available via ftp/uucp)
Reposted-by: (Edward Vielmetti, MSEN)

In his article titled "CMU's Condor process-migration system" Pat Wilson
> 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

        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.

        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 "", (, 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
        in "/networking", and via anonymous uucp from osu-cis in directory

        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: or ucbvax!uwvax!mike
        phone: (608) 262-6122

Mike Litzkow

-- comp.archives file verification
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

----------------------------------cut here-------------------------------

hope this is useful,

Patrick Gosling,                               
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: 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