Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!evan
From: evan@apollo.HP.COM (Evan Morton)
Newsgroups: comp.sys.apollo
Subject: Re: DPAT problem
Message-ID: <4d7f58e6.20b6d@apollo.HP.COM>
Date: 19 Oct 90 21:04:00 GMT
References: <9010161441.AA07687@umix.cc.umich.edu>
Sender: root@apollo.HP.COM
Reply-To: evan@apollo.COM (Evan Morton)
Organization: Apollo Computer, Chelmsford, MA
Lines: 28

In article <9010161441.AA07687@umix.cc.umich.edu> derstad@cim-vax.honeywell.com ("DAVE ERSTAD") writes:

>We've found a strange happening with DPAT (Apollo's process monitoring
>utility).  The following sequence of events occurs on a Series 400.
>
>We are monitoring a fairly CPU intensive program using DPAT.  All is 
>well.  An unrelated CPU intensive program starts up.  All is still
>well (the various programs time-slice).  A second unrelated
>CPU intensive program starts up.  Now, the monitored program
>blocks somehow and gets no further CPU time.

The fewer processes are active when using DPAT, the better.  To quote from
our manual, "Analyzing Program Performance with Domain/PAK", order number
008906-A00, page 4-1:
    "DPAT can monitor your program more efficiently if you do not
     simultaneously run any other processes..."

Remember that DPAT puts its own priority very high, higher than user
programs normally go.  It also lets the target program run for only
a fixed small amount of ELAPSED time (not CPU time).  These two facts,
combined with intricacies of the OS scheduling algorithm, mean that if
there's much other serious resource usage on the machine, the target
program will get very little time.  I don't know the exact sequence
of scheduling events, but I know it happens.

A simple experiment showed that creating one extraneous CPU-hungry
process reduces the speed of the target process by about a factor
of 40, and a second process reduces it by a further factor of 40.