Xref: utzoo comp.unix.questions:11090 comp.os.vms:11107
Path: utzoo!attcan!uunet!lll-winken!ames!pacbell!att!ihlpb!gregg
From: gregg@ihlpb.ATT.COM (Wonderly)
Newsgroups: comp.unix.questions,comp.os.vms
Subject: Re: Do OS's slow down with age?  (was: DDJ article / UNIX vs BS/2)
Message-ID: <9401@ihlpb.ATT.COM>
Date: 13 Jan 89 15:42:01 GMT
References: <7172@batcomputer.tn.cornell.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 77

From article <7172@batcomputer.tn.cornell.edu>, by riley@batcomputer.tn.cornell.edu (Daniel S. Riley):
> In article <12938@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>>In article <1472@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>>|   There is a lot of process creation overhead in VMS.  On the other
>>| hand, you don't need to create a process every time you do anything
>>| (as UNIX does).  In fact, most "basic" users (edit/compile/link) will
>>| log in and use only their one process (or maybe two, if they have a
>>| background editing process).
>>
>>  I talked to a few VAX support people again, and they agree about
>>process creation. Unfortunately VMS does what's called "image
>>activation" which still results in reading a program from disk,
>>establishing an environment (in the VMS sense) and all the things UNIX
>>calls a subprocess, except accounting. This happens when you start the
>>editor, compiler, linker, run the program, etc. It still isn't cheap in
>>terms of system resources.
> 
> The image activation overhead is tiny compared to the process creation
> overhead.  Image activation is like process creation on a UN*X system--
> cheap and fast.  Process creation, on the other hand, is miserably
> expensive under VMS.

I once had this feeling, but believe it actually depends on what kind of
process you create.  Using LIB$SPAWN is expensive because DCL is along
for the ride.  If you use SYS$CREPRC directly, you can rid yourself of
a lot of bagage.

> 
> I tend to think that the process creation overhead is a bigger problem
> than previous posters have admitted.
> ...
> An 8600 makes a great one or two-user system, but put
> any more on it, and the process creation overhead starts to get very
> annoying.

I was really annoyed by the response time of the 750 that I used to
manage.  There were a lot of people using TeX and others running compute
bound fortran programs that manipulated huge arrays (Math and Stat
department computer).  I wrote a long term scheduler to run as a detached
process.  It watches state transitions, percent CPU utilization and uses
the LOAD-AVERAGES driver to manipulate batch queues as things get busy.

It separates the users into two groups, those at base prio 4 and those
at base prio 5.  When it determines that you are busy with the CPU, it
will put you into the 4 group.  When you become idle again it puts you
back into the 5 group (login interactive base prio is 5).  The
granularity is set at 7 seconds which provides a very comfortable
transition.  With 3 people running CPU bound an interactive user can type
SPAWN and get a subprocess instantaneously.  If the user goes compute
bound for too long, base priority will be adjusted accordingly.

Facilities are available to adjust priorities unconditionally on a per
process bases.  I intended to put identifier controlled algorythms in,
but never got the chance.

> I expect this problem to get worse as DEC implements more advanced user
> interfaces under VMS.  DEC will probably be at least one step behind
> companies like Apollo in user interface design for the foreseeable
> future, and I think the process creation overhead is a major reason
> for this.  (I could also go on about DECNET network overhead, but that's
> a bit off the topic.)

Some major reasons for the short falls in performance are:

	1)	QUANTUM==20 is too long, try 15 or 10 and you will see a marked
		change in response times.

	2)  I/O boosts and most other related priority manipulations by VMS
		are too short sighted.  I.E. a priority boost of 1 is lost for
		each quantum that is completed without surrendering the CPU.
		To begin with, priority boosts are not necessary if compute
		bound process are degradated properly.


-- 
Gregg Wonderly                             DOMAIN: gregg@ihlpb.att.com
AT&T Bell Laboratories                     UUCP:   att!ihlpb!gregg