Gavin,

I found this interesting. It sounds like a good argument against running
performance measurement tools all the time. And I know Stan has crusaded on
the list for some time about the evils of the Management Interface and the
amount of overhead it uses/causes. But is there an alternative for
collecting performance stats? AFAIK HP has basically denied there's a
problem with the MI (or at least said, "We're not changing it."). So what
can we poor lil' sys admins do who need to be able to report on system
performance on a daily/weekly/monthly basis that doesn't itself add a whole
lot of overhead?

Anyone?

Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Patrick Santucci
HP e3000 Systems Administrator
Cornerstone Consolidated Services Group, Inc.

> -----Original Message-----
> From: Gavin Scott [SMTP:[log in to unmask]]
> Sent: Friday, January 12, 2001 4:39 pm
> To:   [log in to unmask]
> Subject:      [HP3000-L] More on Switching CM->NM and the evils of Glance
>
> As an aside to David's switching issue, it occurred to me to wonder just
> how
> much overhead the Measurement Interface (i.e. Glance, etc.) adds to CM
> programs as a result of having to count every switch to NM that occurs
> during the execution of the program.
>
> As I said before, switches from CM->NM are extremely fast as they simply
> require constructing an NM stack frame and translating the *addresses* of
> the CM parameters into NM, which is basically just an add instruction.
> But
> apparently the switch code also has to go look to see if the MI is turned
> on, and if so to go update process specific (and possibly global?) switch
> statistic counters.  These operations may involve locking and unlocking
> one
> or two semaphores as well.
>
> Since virtually every operation that a CM program does will result in at
> least one call into the OS or some other piece of NM code, this MI
> overhead
> on each of these calls could be significant.
>
> It turns out that a cpu intensive CM program can be slowed down by as much
> as 40%(!!) just because someone somewhere is running Glance or Scope or
> some
> other tool that has turned the MI on to collect performance data for it.
>
> So this is another good example of why you don't want to have the MI
> turned
> on all the time.
>
<snip>