Christian writes:
> 2) When the MI (Measurement Interface) runs, it only takes marginal system
> resources, like 5 % on a very small system (917, 918), and what I would
> rate as less than 2 % on a top-gun 8-proc machine. But remember, the MI
> itself runs continuously as it is fed by all running processes, whereas
> utilities have a sampling interval (Glance : 30 seconds by default, Scope :
> 5 minutes by default).

The MI is not a single entity being "fed by running processes".  Nor is
the CPU utilization of GLANCE or another MI using tool "MI CPU".  That
CPU which GLANCE uses is overhead in *addition* to whatever the MI is
causing, so you need to add the two together to determine the total
cost of runing GLANCE.

The only way to measure MI overhead is to compare the runtime and CPU
utilization of an operation both with the MI on and off.

All throughout MPE there is probably code that looks like:

  do_something...
  IF mi_is_on() THEN IncrementMICounters();

so what turning on the MI does is cause all the places throughout the
operating system that collect MI information to start doing more work
and thus using more CPU and taking more wall time.  There is no way
to separate out MI overhead, since it is hidden inside all of the
normal operations your program is performing.  There is no measurement
counter from an MI or non-MI performance tool that can tell you what
the MI overhead is.

I used to be among the group of people who thought that people like
Stan who always harp on MI overhead were exaggerating the situation,
however it has now been demonstrated to me that the MI does cause
what I would call "significant" overhead in real world situations.

I think a ballpark number for MI overhead is probably around 10%
overall, with some systems or applications being more (up to 15-20%)
and some being less.

It all depends on whether your application performs a lot of otherwise
very fast operations for which the MI overhead is very large when it
is ON.  Many MPE "intrinsic" operations are *very* streamlined these
days in terms of code path length, so any increase is more measurable
that one might think.

A multiprocessor machine could very well have significantly *more* MI
overhead than a single CPU machine, since there will now be semaphore
contention over the MI counters between CPUs, along with the associated
hardware overhead as the caches on the various CPUs fight over who owns
the counter data.

When it comes to the MI, the only way to quantify its overhead is to
actually benchmark the application and find out.  At that point, it will
depend on what *your* definition of "significant" is.  Some sites may
decide that the information they get from MI tools like GLANCE and SCOPE
are worth >5% of their performance, but in general I think the answer
is to avoid running MI tools when they are not actively benefiting you.

G.