Dave,

On Wed, Mar 5, 2008 at 5:16 AM, Dave Shield <[EMAIL PROTECTED]> wrote:
>  So we're really just reporting the contents of /proc/stat

Ah, excellent, thank you.


>  >            How about Solaris?
>             cpu2->sys2_ticks = (unsigned 
> long)cpu2->kern_ticks+cpu2->wait_ticks;
>  Note that system here is kernel + wait.

Doh :).

>  This inconsistency is partly why I would like to define a new CPU MIB.
>  That and a desire to support per-CPU statistics, rather than just the
>  current overall figures.

Makes sense and a very good idea; especially with HT and multi-cores
having this information in a table now would make a lot of sense.  I
am sure that presenting the information in a consistent way across
platforms will be a challenge, are you also planning on removing the
platform-specific summing from the values reported (like the Solaris
example above) so that SNMP users don't have to get into the guts of
each OS to make CPU utilization checking programs behave properly for
each platform Net-SNMP is used on?

I say that knowing that you have no control over how / if any OS does
it's own math on the counters before presenting them to users ...

I know a Im revisiting a problem that has been around for a long time,
I appreciate the information.

>  The clearest code is probably that under 'mibgroup/hardware/cpu',
>  where there's a separate code file for each architecture.   See the
>  routine 'netsnmp_cpu_arch_load'.
>    The contents of these are basically the same as those from the
>  earlier 'mibgroup/ucd-snmp/vmstat*.c' files.

Thank you very much!

- Max

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to