Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!ogccse!blake!uw-beaver!tektronix!zephyr.ens.tek.com!orca!radio_flyer!paulsc
From: paulsc@radio_flyer.WV.TEK.COM (Paul Scherf;685-2734;61-028;692-4142;orca)
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Summary: job size queues can sometimes be cheated
Keywords: job scheduling
Message-ID: <4327@orca.WV.TEK.COM>
Date: 24 Aug 89 21:14:03 GMT
References: <3332@blake.acs.washington.edu> <2394@unisoft.UUCP> <3357@blake.acs.washington.edu
Sender: nobody@orca.WV.TEK.COM
Reply-To: paulsc@radio_flyer.WV.TEK.COM (Paul Scherf)
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 17

Much of my computing, during the time I was an undergraduate student, was on a
batch system, with job size queues, etc. ....  The job sizes were based on the
maximum number of CPU seconds, maximum memory size, ... requested on the "job
card" (the first line/card in the input file).  Every time the computing center
published a change to the scheduling algorithm or the job size categories, some
of my friends and I would come up with an "un-scheduling" algorithm for the
best job size, based on the current job mix.  (There were several terminals
around campus, solely for checking on the status of a particular job or the
current job mix.)  We found that often we could get better service than our
classmates, by forcing our jobs into larger job sizes, by telling the system we
were going to use more CPU time, memory, ... than we would really use.  Some of
the most complex scheduling algorithms, let us come up with the most effective
"un-scheduling" algorithms.

Sure made it easier to learn queueing theory,
Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA
paulsc@orca.WV.Tek.com     503-685-2734     tektronix!orca!paulsc