Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!seismo!ll-xn!topaz!root
From: root@topaz.RUTGERS.EDU (Charles Root)
Newsgroups: net.unix-wizards
Subject: Re: 4.2bsd kernel auto-nicing, scheduling (long)
Message-ID: <4516@topaz.RUTGERS.EDU>
Date: Sun, 2-Mar-86 23:57:52 EST
Article-I.D.: topaz.4516
Posted: Sun Mar  2 23:57:52 1986
Date-Received: Tue, 4-Mar-86 04:00:15 EST
References: <1014@brl-smoke.ARPA> <669@frog.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 19

You might be interested in our experience with our DEC-20's.  The
default DEC-20 scheduler sounds a lot like what you have done.  In
particular, it has heuristic boosts for terminal input, and other
things designed to favor interactive jobs.  Like many other
universities, we have a heavily loaded timesharing system used for
students.  What we found was that under heavy load Emacs ran just
great, but the first time you tried to compile, you might as well go
out for dinner (multi-course, in your favorite New York restaurant).
Since all of our students eventually did a compilation, the results
were a disaster.  We finally ended up using the "class scheduler".
This is a scheduler that keeps track of what average share of the CPU
is going to each user.  It gives boosts or penalties depending upon
whether you are getting more or less than your fair share.  Emacs ran
a bit slower (though there was still some interactive boost), but
people got their work done.  Eventually, we ended up moving our two
research machines to the same scheduler, because we started running
into the same thing there, too.  I concluded that what most people
really expect to get out of a timesharing system is 1/N of the
machine, where N is the load average.