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.