derstad@cim-vax.honeywell.com ("DAVE ERSTAD") (10/16/90)
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. I've replicated this using "while ((1)) do enddo" statements for the unrelated CPU intensive programs. I have not yet tried to make it happen while monitoring programs other than the original application, so I don't know how unique a problem this is. Can anyone offer a rational explanation? Dave Ersatd DERSTAD@cim-vax.honeywell.com Honeywell SSEC
evan@apollo.HP.COM (Evan Morton) (10/20/90)
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.