"Compute Que"

[Jack Trachtman]

MONITOR SYSTEM displays the COMPUTE QUE value(# of processes waiting for a free cpu). I would like to track this value. Is there a way to obtain this number outside of running MONITOR directory (or running MONITOR indirectly through T4)?

TIA

[Jess Goodman]

My answer may be too simple for your needs, but what about

$ SHOW SYSTEM/STATE=COM

If you want just the count:
$PIPE SHOW SYSTEM/NOHEAD/STATE=COM | -
SEARCH SYS$PIPE: ""/NOOUT/LOG

[John Gillings · Accepted solution]

Jack,

>Is there a way to obtain this number
>outside of running MONITOR

Of course! SMOP - you can write some kernel mode code to dig down into the scheduler data structures and count them yourself ;-)

Ah, but you want an *EASY* way?

Is there a problem running T4?

If you have a recent enough version of OpenVMS, you can use the $GETRMI system service. Use item RMI$_COM. I've attached a simple MACRO32 program which will return 2*COM+1 as $STATUS (so that status is seen as successful). To use it:

$ RUN GETCOM
$ COM=$STATUS/2

Notes...

1) there is no $GETRMI_S macro :-(
2) you MUST $SYNCH the call
3) If you're going to use it in a larger context, make sure you allocate an event flag correctly.

[Hoff]

Um, what about a bog-standard wildcard $getjpi[w], looking for processes that are in the COM or COMO or CUR states? Inelegant, but probably sufficiently effective?

As for T4, you could ping Steve L. over at trendsthatmatter, and see if he has anything for whatever performance details you're after.

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

Jess & Hoff,

The trouble with anything that involves scanning processes for measuring the compute queue is that it can give wildly incorrect results because it requires significant processing to derive an answer. Further, the state of the system can change significantly during the time it takes to complete the scan. Results can be wrong in either direction (especially using $GETJPI as it may CAUSE the target process to go into COM state).

Heisenberg principles apply here - observing the system WILL change it. Consider a single CPU system with a single computable process. That process will be in CUR state and the CPU queue will be 0. Now introduce the monitoring process - while it's sampling, the monitor process must be CUR, and the other process will therefore be COM, so the compute queue will be 1. We might incorrectly conclude that the system needs another CPU because we will never see a COM queue of 0.

$GETRMI is collecting the actual length of the COM queue at the sample time, without having to count or gather any information from other processes. It may cause processes transitions CUR->COM or COM->CUR, but it's unlikely to cause dormant processes to become computable, or create new processes (like using PIPE).

In practice you should probably use MAX(0,CUR-1) as your sample value.

[Hoff]

I'm well aware the method is a less than fully desirable solution. It's also easy, portable, and works; it's usually "good enough".

I've used exe$getspi (which has been round for rather longer than sys$getrmi), and that (also) is less desirable. If you want to go after that route, look for the I_SPI.* tool on the Freeware; you'll need the source listings if you're going after much of anything other than the modes values the example retrieves.

At the typical frequency of a typical MONITOR recording pass, a process scan or three will be lost in the noise of typical system activity. And it'll be close enough for most uses.

[Wim Van den Wyngaert]

For monitoring purposes I would prefer the average during a sample interval. I would go for an average calculated by monitor and not for a photo made by a lexical.

E.g. do
monitor states /sum/nodispl/end=hh:mm
and parse the output.

Wim